On Wed, Feb 20, 2013 at 5:50 AM, Peter Meerwald <pmeerw@xxxxxxxxxx> wrote: > Hello, > >> > 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 :) > >> > 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 > >> > 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. >> > 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) -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
