Hi Henrik and all,
As I know, currently there is no synaptics RMI4 touchscreen driver in the
main tree. In order to support our customers effectively, is it able to merge
staging ste_rmi4 driver into the main kernel.org tree? If it is accepted, should
I send a patch for this change?
Any advice is greatly appreciated!
Alexandra Chin
Hi Alexandra,
On Wed, Nov 14, 2012 at 05:40:12PM +0000, Alexandra Chin wrote:
> Hi Henrik and all,
>
> As I know, currently there is no synaptics RMI4 touchscreen driver in the
> main tree. In order to support our customers effectively, is it able to merge
> staging ste_rmi4 driver into the main kernel.org tree? If it is accepted, should
> I send a patch for this change?
I believe that we should keep ste_rmi4 in staging, not as reflection of
its code quality, but rather because it is a temporary solution until
full-fledged RMI4 driver is merged.
Please have Greg commit the patch that Henrik reviewed to staging and
then work with Christopher Heiny group on getting the full featured
driver into mainline.
Thanks.
--
Dmitry
Hi Dmitry,
> > As I know, currently there is no synaptics RMI4 touchscreen driver in the
> > main tree. In order to support our customers effectively, is it able to merge
> > staging ste_rmi4 driver into the main kernel.org tree? If it is accepted, should
> > I send a patch for this change?
>
> I believe that we should keep ste_rmi4 in staging, not as reflection of
> its code quality, but rather because it is a temporary solution until
> full-fledged RMI4 driver is merged.
>
> Please have Greg commit the patch that Henrik reviewed to staging and
> then work with Christopher Heiny group on getting the full featured
> driver into mainline.
Thank you for the prompt reply. The ste_rmi4 driver is actually not intended to be
a temporary solution for the full-fledged driver. We have requests from a number
of our customers and partners (Qualcomm, Samsung, Intel etc.) urging us to have
a driver available in the kernel mainline that is specific to touchscreen with simple
architecture and supporting our S3200 family of Touch Controllers and above. We
are committing resources to continue to maintain this driver and provide updates
to support future touch controller revisions from Synaptics.
It would be greatly appreciated if this driver can be considered for inclusion in the
kernel mainline.
Thank you.
Alexandra Chin
On Thu, Nov 15, 2012 at 02:56:45AM +0000, Alexandra Chin wrote:
> Hi Dmitry,
>
> > > As I know, currently there is no synaptics RMI4 touchscreen driver in the
> > > main tree. In order to support our customers effectively, is it able to merge
> > > staging ste_rmi4 driver into the main kernel.org tree? If it is accepted, should
> > > I send a patch for this change?
> >
> > I believe that we should keep ste_rmi4 in staging, not as reflection of
> > its code quality, but rather because it is a temporary solution until
> > full-fledged RMI4 driver is merged.
> >
> > Please have Greg commit the patch that Henrik reviewed to staging and
> > then work with Christopher Heiny group on getting the full featured
> > driver into mainline.
>
> Thank you for the prompt reply. The ste_rmi4 driver is actually not intended to be
> a temporary solution for the full-fledged driver. We have requests from a number
> of our customers and partners (Qualcomm, Samsung, Intel etc.) urging us to have
> a driver available in the kernel mainline that is specific to touchscreen with simple
> architecture and supporting our S3200 family of Touch Controllers and above. We
> are committing resources to continue to maintain this driver and provide updates
> to support future touch controller revisions from Synaptics.
> It would be greatly appreciated if this driver can be considered for inclusion in the
> kernel mainline.
In this case you need to enumerate the benefits of this driver over
unified driver and show why the unified driver can't be fixed.
Currently the driver is in mainline (even though the directory is
staging) and nobody will remove it until another driver is fully
functional and ready for prime time. But once this happens I do not see
the benefits of maintaining 2 drivers for the same hardware.
Thank you.
--
Dmitry
On Thu, Nov 15, 2012 at 7:43 AM, Dmitry Torokhov
<[email protected]> wrote:
> In this case you need to enumerate the benefits of this driver over
> unified driver and show why the unified driver can't be fixed.
The benefit is that the ugliness in
drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
can be avoided, as today we're unable to pass the compulsory
platform data in any sane way. I'm being told that this weak symbol
override actually does not really work... especially if there are more
than 1 I2C device on the bus :-P
Another way of fixing the staging driver usable is to add device tree
support, of course, that would decopule it completely from the
platform using it.
Yours,
Linus Walleij
Hi Linus,
On Thu, Nov 15, 2012 at 06:41:26PM +0100, Linus Walleij wrote:
> On Thu, Nov 15, 2012 at 7:43 AM, Dmitry Torokhov
> <[email protected]> wrote:
>
> > In this case you need to enumerate the benefits of this driver over
> > unified driver and show why the unified driver can't be fixed.
>
> The benefit is that the ugliness in
> drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
> can be avoided, as today we're unable to pass the compulsory
> platform data in any sane way. I'm being told that this weak symbol
> override actually does not really work... especially if there are more
> than 1 I2C device on the bus :-P
I am confused as to why this would be a benefit of ste_rmi4 over full
RMI4 implementation from Christopher's group?
I think what we really need is to accelerate work on the full driver so
it is in mainline in 3.9ish.
Thanks.
--
Dmitry
On Thu, Nov 15, 2012 at 7:55 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Thu, Nov 15, 2012 at 06:41:26PM +0100, Linus Walleij wrote:
>>
>> The benefit is that the ugliness in
>> drivers/staging/ste_rmi4/board-mop500-u8500uib-rmi4.c
>> can be avoided, as today we're unable to pass the compulsory
>> platform data in any sane way. I'm being told that this weak symbol
>> override actually does not really work... especially if there are more
>> than 1 I2C device on the bus :-P
>
> I am confused as to why this would be a benefit of ste_rmi4 over full
> RMI4 implementation from Christopher's group?
So we don't need to keep our real platform data and board files
out-of-tree like we've done for the last 2 years or so.
But I only said it's a benefit, not that I think it's a good idea.
> I think what we really need is to accelerate work on the full driver so
> it is in mainline in 3.9ish.
Yep, agreed.
Yours,
Linus Walleij
Hi Dmitry,
> > > Please have Greg commit the patch that Henrik reviewed to staging and
> > > then work with Christopher Heiny group on getting the full featured
> > > driver into mainline.
Thanks for your reminding, final patch has been re-sent to staging
maintainer.
> In this case you need to enumerate the benefits of this driver over
> unified driver and show why the unified driver can't be fixed.
>
> Currently the driver is in mainline (even though the directory is
> staging) and nobody will remove it until another driver is fully
> functional and ready for prime time. But once this happens I do not see
> the benefits of maintaining 2 drivers for the same hardware.
I see. Given that the driver will remain in mainline before generic driver
is ready, currently I will continue to maintain the driver in staging.
Appreciate your response.
Alexandra
On Friday, November 16, 2012 09:02:30 AM Alexandra Chin wrote:
> Hi Dmitry,
>
> > > > Please have Greg commit the patch that Henrik reviewed to staging and
> > > > then work with Christopher Heiny group on getting the full featured
> > > > driver into mainline.
>
> Thanks for your reminding, final patch has been re-sent to staging
> maintainer.
>
> > In this case you need to enumerate the benefits of this driver over
> > unified driver and show why the unified driver can't be fixed.
> >
> > Currently the driver is in mainline (even though the directory is
> > staging) and nobody will remove it until another driver is fully
> > functional and ready for prime time. But once this happens I do not see
> > the benefits of maintaining 2 drivers for the same hardware.
>
> I see. Given that the driver will remain in mainline before generic driver
> is ready, currently I will continue to maintain the driver in staging.
Sounds like a plan.
Thanks!
--
Dmitry