On 07/31/2014 10:53 AM, Dmitry Torokhov wrote:
Hi Christopher,
On Wed, Mar 12, 2014 at 06:53:56PM -0700, Christopher Heiny wrote:
Add support for updating firmware on RMI4 devices with V5 bootloader.
I am wondering why F34 is not following the staindard RMI function
implementation. By that I mean that it does not declare itself as struct
rmi_function_handler and does not rely on RMI core to bind itself to the device
if device supports it.
Hi Dmitry,
We originally had an F34 implementation that followed the RMI4 function
standard and exposed most of the basic F34 operations via sysfs.
However, we got feedback (both on LKML and offline) (a) recommending to
use request_firmware, and (b) improve reflash times while (c) reducing
impact on boot time, and (d) "get rid of all that sysfs crap"
(paraphrased, but close to it).
So after looking at how some other drivers use request_firmware, we came
up with the current approach. Switching to request_firmware definitely
sped up the reflash times! Including a check to see if firmware update
is required before setting up the RMI4 sensor/function structures also
significantly reduced boot times.
By the way, isn't rmi_extract_u32() is the same as le32_to_cpup()?
Hmmm. Looks like that one escaped the sweep of roll-your-own endian
fixes. I'll update it.
Chris
--
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
