From: Christopher Heiny <cheiny@synaptics.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Linux Input <linux-input@vger.kernel.org>,
Andrew Duggan <aduggan@synaptics.com>,
Vincent Huang <vincent.huang@tw.synaptics.com>,
Vivian Ly <vly@synaptics.com>,
Daniel Rosenberg <daniel.rosenberg@synaptics.com>,
Linus Walleij <linus.walleij@linaro.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
David Herrmann <dh.herrmann@gmail.com>,
Jiri Kosina <jkosina@suse.cz>
Subject: Re: [PATCH v2 05/06] input synaptics-rmi4: Add firmware update support
Date: Thu, 31 Jul 2014 14:43:47 -0700 [thread overview]
Message-ID: <53DAB893.2070308@synaptics.com> (raw)
In-Reply-To: <20140731211921.GA36491@core.coreip.homeip.net>
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.
Chris
next prev parent reply other threads:[~2014-07-31 21:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 1:53 [PATCH v2 01/06] input synaptics-rmi4: Split F01 definitions into header file Christopher Heiny
2014-03-13 1:53 ` [PATCH v2 02/06] input synaptics-rmi4: Add some more F01 properties Christopher Heiny
2014-03-13 1:53 ` [PATCH v2 03/06] input synaptics-rmi4: rmi_f01 - Fix a comment, add a diagnostic message Christopher Heiny
2014-03-13 1:53 ` [PATCH v2 04/06] input synaptics-rmi4: rmi_driver - Export some symbols and functions Christopher Heiny
2014-03-13 1:53 ` [PATCH v2 05/06] input synaptics-rmi4: Add firmware update support Christopher Heiny
2014-07-31 17:53 ` Dmitry Torokhov
2014-07-31 21:00 ` Christopher Heiny
2014-07-31 21:19 ` Dmitry Torokhov
2014-07-31 21:43 ` Christopher Heiny [this message]
2014-07-31 21:58 ` Dmitry Torokhov
2014-08-06 23:28 ` Christopher Heiny
2014-08-07 6:42 ` Dmitry Torokhov
2014-08-08 21:10 ` Christopher Heiny
2014-08-08 21:20 ` Dmitry Torokhov
2014-03-13 1:53 ` [PATCH v2 06/06] input synaptics-rmi4: Use request_firmware_nowait Christopher Heiny
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DAB893.2070308@synaptics.com \
--to=cheiny@synaptics.com \
--cc=aduggan@synaptics.com \
--cc=benjamin.tissoires@redhat.com \
--cc=daniel.rosenberg@synaptics.com \
--cc=dh.herrmann@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jkosina@suse.cz \
--cc=linus.walleij@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=vincent.huang@tw.synaptics.com \
--cc=vly@synaptics.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).