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? 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 > > 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) -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
