re-sent due to delivery failure on HTML tags.
On Tue, Feb 19, 2013 at 3:41 PM, Yufeng Shen [off-list ref] wrote:
quoted hunk
Hi Peter,
The Chromium team has been recently working on the atmel_mxt_ts driver extensively
(see patches history here
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=history;f=drivers/input/touchscreen/atmel_mxt_ts.c;h=5e40f6d75e7f7e24370e3a7d266c6ebcc06b46a6;hb=refs/heads/chromeos-3.4)
As you pointed out, the chip configuration process and mxt_handle_pdata() is very fragile regarding
different chip sets with different object layouts. So we have taken the approach to move to file based
configuration (see patch
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commit;h=95a1d96b785af4e16138e6cc7b4d01fed5b9dccb)
So the platform data are moved to a config file with predefined format. Userspace can interact with the driver
through sysfs to initiate loading a particular config file for the device. When configuration happens, config file chip ID & chip info
block CRC are compared against the device chip ID & device chip info block to make sure the consistence between
the config and the chip set. Then the configuration is written to the device dynamically which does not require the device reboot.
Other works include exposing various FW/config attributes through sysfs, e.g. FW version and config CRC, which can be used
for FW/config version controlling.
We have been using and testing this approach for a long time and now in the process of upstreaming our patch set, so to avoid duplicate effort, it would be great if you can give some thoughts (or try out the patch set if you are interested and we would give you all the help as
we can) on our patch set and let us iterate on it.
Let me know what you think.
Thanks,
On Thu, Feb 7, 2013 at 9:17 AM, Peter Meerwald [off-list ref] wrote:
quoted
Hello,
I had some issues in using the atmel_mxt_ts driver with different mxt224 parts
(different firmware version, mxt224 vs. mxt224); configuration of the chip
via mxt_platform_data.config is super-fragile when device objects change
mxt_handle_pdata() assumes that certain object table entries are present and
fails on the mxt224e
the patch series aims to support the mxt224e better and adds a message to detect
inconsistencies between config data and the device object table
if there is interest I can propose a more robust mechanism to set the config data;
similar patches are floating around for Android in various trees
thanks, regards, p.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
quoted
The Chromium team has been recently working on the atmel_mxt_ts driver extensively
(see patches history here
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=history;f=drivers/input/touchscreen/atmel_mxt_ts.c;h=5e40f6d75e7f7e24370e3a7d266c6ebcc06b46a6;hb=refs/heads/chromeos-3.4)
thank you for the pointer; I was aware of Chromiumos working on this but
not the official place to look :)
quoted
As you pointed out, the chip configuration process and mxt_handle_pdata() is very fragile regarding
different chip sets with different object layouts. So we have taken the approach to move to file based
configuration (see patch
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commit;h=95a1d96b785af4e16138e6cc7b4d01fed5b9dccb)
I think that's a good idea to support robust configuration loading
quoted
So the platform data are moved to a config file with predefined format. Userspace can interact with the driver
through sysfs to initiate loading a particular config file for the device. When configuration happens, config file chip ID & chip info
block CRC are compared against the device chip ID & device chip info block to make sure the consistence between
the config and the chip set. Then the configuration is written to the device dynamically which does not require the device reboot.
but what to do with the initial configuration at _probe() time?
mxt_handle_pdata() is still there
I'm pretty sure setting of the threshold, burst length, orientation do not
work as intended; voltage setting is still broken for mxt224e
is the plan to remove pdata support altogether? this then requires
userspace interaction to get the device working
quoted
We have been using and testing this approach for a long time and now
in the process of upstreaming our patch set, so to avoid duplicate
effort, it would be great if you can give some thoughts (or try out the
patch set if you are interested and we would give you all the help as
we can) on our patch set and let us iterate on it.
I have no need for flexible post-probe device configuration
my patches 1,3,4,5,7 are mostly complementary to your patch series
can the proposed file format replace the pdata config data?
mxt_apply_pdata_config() would need to be adapted then...
regards, p.
--
Peter Meerwald
+43-664-2444418 (mobile)
On Wed, Feb 20, 2013 at 5:50 AM, Peter Meerwald [off-list ref] wrote:
Hello,
quoted
quoted
The Chromium team has been recently working on the atmel_mxt_ts driver extensively
(see patches history here
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=history;f=drivers/input/touchscreen/atmel_mxt_ts.c;h=5e40f6d75e7f7e24370e3a7d266c6ebcc06b46a6;hb=refs/heads/chromeos-3.4)
thank you for the pointer; I was aware of Chromiumos working on this but
not the official place to look :)
quoted
quoted
As you pointed out, the chip configuration process and mxt_handle_pdata() is very fragile regarding
different chip sets with different object layouts. So we have taken the approach to move to file based
configuration (see patch
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commit;h=95a1d96b785af4e16138e6cc7b4d01fed5b9dccb)
I think that's a good idea to support robust configuration loading
quoted
quoted
So the platform data are moved to a config file with predefined format. Userspace can interact with the driver
through sysfs to initiate loading a particular config file for the device. When configuration happens, config file chip ID & chip info
block CRC are compared against the device chip ID & device chip info block to make sure the consistence between
the config and the chip set. Then the configuration is written to the device dynamically which does not require the device reboot.
but what to do with the initial configuration at _probe() time?
In order to not break the existing code path, we keep the
mxt_handle_pdata() there
but add the support that if pdata is NULL, then we skip applying the
configuration from
pdata, see
http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commit;h=5650201eb029de18517c40610d8b4122aff7369f
As noted in the commit message, most of the time the device only need
to be configured once and later on it
can just use backed up config from NVRAM. When using pdata to config
device, the config is written to device
memory every time the device boots (or probed), which adds latency to
boot time. While in our dev process, we
pre-flash the device with a workable config, set pdata to NULL, and
most of the time the device just comes up
with the right config without need of re-configuration. And if a
different config is needed later, we do the reconfig
by loading the new config from file and back it up in NVRAM.
mxt_handle_pdata() is still there
I'm pretty sure setting of the threshold, burst length, orientation do not
work as intended; voltage setting is still broken for mxt224e
Right. If you have to take the path of mxt_handle_pdata(), you will
have to branch on different device models.
Your patch 3 does the quick hack, but as more device models need to be
supported, adapting mxt_handle_pdata()
does not scale well, while loading a corresponding config file for a
specific chipset is more preferable.
is the plan to remove pdata support altogether? this then requires
userspace interaction to get the device working
see notes above.
quoted
quoted
We have been using and testing this approach for a long time and now
in the process of upstreaming our patch set, so to avoid duplicate
effort, it would be great if you can give some thoughts (or try out the
patch set if you are interested and we would give you all the help as
we can) on our patch set and let us iterate on it.
I have no need for flexible post-probe device configuration
my patches 1,3,4,5,7 are mostly complementary to your patch series
can the proposed file format replace the pdata config data?
mxt_apply_pdata_config() would need to be adapted then...
see the above comments.
regards, p.
--
Peter Meerwald
+43-664-2444418 (mobile)