On 08/06/2014 11:42 PM, Dmitry Torokhov wrote:
On Wed, Aug 06, 2014 at 04:28:26PM -0700, Christopher Heiny wrote:
[I sent this last Thursday, but it never showed up on the input
list. I'm assuming nobody else saw it.]
On 07/31/2014 02:58 PM, Dmitry Torokhov wrote:
On Thu, Jul 31, 2014 at 02:43:47PM -0700, Christopher Heiny wrote:
On 07/31/2014 02:19 PM, Dmitry Torokhov wrote:
On Thu, Jul 31, 2014 at 02:00:14PM -0700, Christopher Heiny wrote:
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.
I am not suggesting you stop using request-firmware or introduce
bazillion of new sysfs attributes. I just wondered why you have manual
"binding" of F34 functionality instead of standrad RMI4 function
binding, liek you do for F01, F11 and so forth.
Sorry! My answer wasn't very clear on that part, was it?
The manual binding gets the reflash (if required) done very early in
the boot/probe process. This eliminates the need to set up the
whole sensor + functions structure, tear it down in order to
reflash, and then build it all back up again. It is felt that the
time savings is significant, especially on highly featured products.
I am sorry but I have hard time accepting this argument. How often do
you reflash devices during normal operation and how long does it take to
initialize the device compared to getting entire userspace up and
running to be able to actually supply or serve flash data (even without
using usermode helper to flash you need filesystem with the firmware to
be mounted)?
That was my argument exactly, but that was the direction we were
pushed. I'd much rather implement it as we discussed offline
earlier this week. If you were to say: "I'm sorry, but this simply
can't be merged as it stands." you wouldn't get any argument from me
on technical grounds. There might be people who will argue about the
additional calendar time it would take to restructure it, though.
OK, then I will just say this: "I'm sorry, but this simply can't be merged as
it stands."
Now, I am talking about mainline here, I am fairly certain we can resolve
scheduling issues between what you currently have and what is needed in the
end.
OK. The question on our end becomes - can we accept the current
implementation as a baseline while we rework the implementation to use a
conformant F34 implementation? Our rough estimation is that this will
be ready around the end of this month or early next month.
Thanks,
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
