| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
By reading the touchscreen configuration from the settings that the
maXTouch chip is actually using, we can remove some platform data.
The matrix size is not used for anything, and results in some rather
confusing code to re-read it because it may change when configuration
is downloaded, so don't print it out.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
* The mapping of the GPIO numbers into the T19 status byte varies between
different maXTouch chips. Some have up to 7 GPIOs. Allowing a keycode array
of up to 8 items is simpler and more generic. So replace #define with
configurable number of keys which also allows the removal of is_tp.
* Rename platform data parameters to include "t19" to prevent confusion with
T15 key array.
* Probe aborts early on when pdata is NULL, so no need to check.
* Move "int i" to beginning of function (mixed declarations and code)
* Use API calls rather than __set_bit()
* Remove unused dev variable.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Yufeng Shen <miletus@chromium.org>
Reviewed-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
It is not necessary to download these values to the maXTouch chip on every
probe, since they are stored in NVRAM. It makes life difficult when tuning
the device to keep them in sync with the config array/file, and requires a
new kernel build for minor tweaks.
These parameters only represent a tiny subset of the available
configuration options, tracking all of these options in platform data would
be a endless task. In addition, different versions of maXTouch chips may
have these values in different places or may not even have them at all.
Having these values also makes life more complex for device tree and other
platforms where having to define a static configuration isn't helpful.
Signed-off-by: Nick Dyer <nick.dyer@itdev.co.uk>
Acked-by: Benson Leung <bleung@chromium.org>
Acked-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
We have registered platform driver and device when module
init, and need unregister them when module exit.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Not used outside of the file, so declaration should be static. Picked up by
sparse:
drivers/platform/chrome/chromeos_laptop.c:44:12: warning: symbol
'i2c_adapter_names' was not declared. Should it be static?
Signed-off-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Benson Leung <bleung@chromium.org>
|
|
__initdata tag should be placed between the variable name and equal
sign for the variable to be placed in the intended .init.data section.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Further refactor chromeos_laptop, adding a probe function.
Init will call dmi_check_system, but will only use the match to select
a chromeos_laptop structure of the current board.
Probe will add the devices, and on errors return -EPROBE_DEFER.
If i2c adapters are loaded after chromeos_laptop inits, the deferred
probe will instantiate the peripherals when the bus appears.
Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
The previous code had a single DMI matching entry
for each device on a board. Instead provide a single
DMI entry for each board which references a structure
about each board that lists the associated peripherals.
This allows for a lower number of DMI matching sequences
as well making it easier to add new boards.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
Add the ramoops pstore device so that we get logs of panics across reboots.
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
It makes sense to split out the Chromebook/Chromebox hardware platform
drivers to a separate subdirectory, since some of it will be shared
between ARM and x86.
This moves over the existing chromeos_laptop driver without making
any other changes, and adds appropriate Kconfig entries for the new
directory. It also adds a MAINTAINERS entry for the new subdir.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
