On Friday, August 08, 2014 02:10:07 PM Christopher Heiny wrote: > 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. Chris, We have a couple months till the next merge window. Thanks. -- Dmitry -- 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
