Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Linus Walleij]

Greg KH wrote:

>> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
>> +Merge any device support needed from this driver into it
>> +Delete this driver
> 
> Huh?
> 
> Why not just add this driver to the kernel tree instead?  When the
> "promised" driver then eventually shows up (who is promising it?) then
> delete the thing.

Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
the other day, and OTOMH that was after discussions with Synaptics
where they said they were working on a "real" driver (a rather
complex RMI4 bus driver) and we believe they will fix that sooner
or later.

So, until sooner or later happens we thought we'd keep it in staging.

If you prefer both Alan and we can probably submit our patches for
inclusion in the proper place.

A side effect may be that the Synaptics RMI4 people may have trouble
to merge their driver into input/ since they may be requested to
refactor the existing drivers to use it rather than merging new stuff,
putting some burden on their shoulders.

Yours,
Linus Walleij

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Greg KH]

On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> Greg KH wrote:
> 
> >> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> >> +Merge any device support needed from this driver into it
> >> +Delete this driver
> > 
> > Huh?
> > 
> > Why not just add this driver to the kernel tree instead?  When the
> > "promised" driver then eventually shows up (who is promising it?) then
> > delete the thing.
> 
> Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> the other day, and OTOMH that was after discussions with Synaptics
> where they said they were working on a "real" driver (a rather
> complex RMI4 bus driver) and we believe they will fix that sooner
> or later.
> 
> So, until sooner or later happens we thought we'd keep it in staging.
> 
> If you prefer both Alan and we can probably submit our patches for
> inclusion in the proper place.

Yes, please do that.

> A side effect may be that the Synaptics RMI4 people may have trouble
> to merge their driver into input/ since they may be requested to
> refactor the existing drivers to use it rather than merging new stuff,
> putting some burden on their shoulders.

That's the burden of any developer, especially ones that are slower to
get their code released :)

thanks,

greg k-h

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Dmitry Torokhov]

On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> Greg KH wrote:
> 
> >> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> >> +Merge any device support needed from this driver into it
> >> +Delete this driver
> > 
> > Huh?
> > 
> > Why not just add this driver to the kernel tree instead?  When the
> > "promised" driver then eventually shows up (who is promising it?) then
> > delete the thing.

The same reason as there were several wireless drivers in staging?

> 
> Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> the other day, and OTOMH that was after discussions with Synaptics
> where they said they were working on a "real" driver (a rather
> complex RMI4 bus driver) and we believe they will fix that sooner
> or later.
> 
> So, until sooner or later happens we thought we'd keep it in staging.
> 
> If you prefer both Alan and we can probably submit our patches for
> inclusion in the proper place.
> 
> A side effect may be that the Synaptics RMI4 people may have trouble
> to merge their driver into input/ since they may be requested to
> refactor the existing drivers to use it rather than merging new stuff,
> putting some burden on their shoulders.
> 

No, they have not been requested to change any existing [in tree]
drivers. They however been asked to convert to the driver core
primitives instead of rolling their own infprastructure to implement
devices and drivers binding.

Thanks.

-- 
Dmitry

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Greg KH]

On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > Greg KH wrote:
> > 
> > >> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> > >> +Merge any device support needed from this driver into it
> > >> +Delete this driver
> > > 
> > > Huh?
> > > 
> > > Why not just add this driver to the kernel tree instead?  When the
> > > "promised" driver then eventually shows up (who is promising it?) then
> > > delete the thing.
> 
> The same reason as there were several wireless drivers in staging?

Ok, that's a good enough reason for me :)

> > Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> > patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> > the other day, and OTOMH that was after discussions with Synaptics
> > where they said they were working on a "real" driver (a rather
> > complex RMI4 bus driver) and we believe they will fix that sooner
> > or later.
> > 
> > So, until sooner or later happens we thought we'd keep it in staging.
> > 
> > If you prefer both Alan and we can probably submit our patches for
> > inclusion in the proper place.
> > 
> > A side effect may be that the Synaptics RMI4 people may have trouble
> > to merge their driver into input/ since they may be requested to
> > refactor the existing drivers to use it rather than merging new stuff,
> > putting some burden on their shoulders.
> > 
> 
> No, they have not been requested to change any existing [in tree]
> drivers. They however been asked to convert to the driver core
> primitives instead of rolling their own infprastructure to implement
> devices and drivers binding.

If you don't object to this driver going in, and there is a path forward
in the future for it to be able to be removed, then I will be glad to
add it.

Can I add your Acked-by: to the patch for this?

thanks,

greg k-h

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Dmitry Torokhov]

On Wed, Nov 03, 2010 at 11:10:58AM -0700, Greg KH wrote:
> On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> > On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > > Greg KH wrote:
> > > 
> > > >> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> > > >> +Merge any device support needed from this driver into it
> > > >> +Delete this driver
> > > > 
> > > > Huh?
> > > > 
> > > > Why not just add this driver to the kernel tree instead?  When the
> > > > "promised" driver then eventually shows up (who is promising it?) then
> > > > delete the thing.
> > 
> > The same reason as there were several wireless drivers in staging?
> 
> Ok, that's a good enough reason for me :)
> 
> > > Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> > > patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> > > the other day, and OTOMH that was after discussions with Synaptics
> > > where they said they were working on a "real" driver (a rather
> > > complex RMI4 bus driver) and we believe they will fix that sooner
> > > or later.
> > > 
> > > So, until sooner or later happens we thought we'd keep it in staging.
> > > 
> > > If you prefer both Alan and we can probably submit our patches for
> > > inclusion in the proper place.
> > > 
> > > A side effect may be that the Synaptics RMI4 people may have trouble
> > > to merge their driver into input/ since they may be requested to
> > > refactor the existing drivers to use it rather than merging new stuff,
> > > putting some burden on their shoulders.
> > > 
> > 
> > No, they have not been requested to change any existing [in tree]
> > drivers. They however been asked to convert to the driver core
> > primitives instead of rolling their own infprastructure to implement
> > devices and drivers binding.
> 
> If you don't object to this driver going in, and there is a path forward
> in the future for it to be able to be removed, then I will be glad to
> add it.
> 
> Can I add your Acked-by: to the patch for this?
> 

Umm... I haven't looked in detail, but I think it is sane enough for
staging... Much better than Alan's version that seemed to create a
separate input device for every finger. Needs to depend on INPUT and
probably regulators framework...  Probe function may call
input_free_device() after calling input_register_device() which is not
good.

Basically staging is yours, you can add whatever you want to it ;)

-- 
Dmitry

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Greg KH]

On Wed, Nov 03, 2010 at 12:07:52PM -0700, Dmitry Torokhov wrote:
> On Wed, Nov 03, 2010 at 11:10:58AM -0700, Greg KH wrote:
> > On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> > > On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > > > Greg KH wrote:
> > > > 
> > > > >> +Wait for the official upstream synaptics rmi4 clearpad drivers as promised over the past few months
> > > > >> +Merge any device support needed from this driver into it
> > > > >> +Delete this driver
> > > > > 
> > > > > Huh?
> > > > > 
> > > > > Why not just add this driver to the kernel tree instead?  When the
> > > > > "promised" driver then eventually shows up (who is promising it?) then
> > > > > delete the thing.
> > > 
> > > The same reason as there were several wireless drivers in staging?
> > 
> > Ok, that's a good enough reason for me :)
> > 
> > > > Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> > > > patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> > > > the other day, and OTOMH that was after discussions with Synaptics
> > > > where they said they were working on a "real" driver (a rather
> > > > complex RMI4 bus driver) and we believe they will fix that sooner
> > > > or later.
> > > > 
> > > > So, until sooner or later happens we thought we'd keep it in staging.
> > > > 
> > > > If you prefer both Alan and we can probably submit our patches for
> > > > inclusion in the proper place.
> > > > 
> > > > A side effect may be that the Synaptics RMI4 people may have trouble
> > > > to merge their driver into input/ since they may be requested to
> > > > refactor the existing drivers to use it rather than merging new stuff,
> > > > putting some burden on their shoulders.
> > > > 
> > > 
> > > No, they have not been requested to change any existing [in tree]
> > > drivers. They however been asked to convert to the driver core
> > > primitives instead of rolling their own infprastructure to implement
> > > devices and drivers binding.
> > 
> > If you don't object to this driver going in, and there is a path forward
> > in the future for it to be able to be removed, then I will be glad to
> > add it.
> > 
> > Can I add your Acked-by: to the patch for this?
> > 
> 
> Umm... I haven't looked in detail, but I think it is sane enough for
> staging... Much better than Alan's version that seemed to create a
> separate input device for every finger. Needs to depend on INPUT and
> probably regulators framework...  Probe function may call
> input_free_device() after calling input_register_device() which is not
> good.

Great, thanks for this.

> Basically staging is yours, you can add whatever you want to it ;)

Heh, well, I try to at least cooperate with the different subsystem
maintainers.  I don't need even more people pissed-off at me than I
normally get :)

I'll queue this up for .38.

thanks,

greg k-h

RE: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Arce, Abraham]

Hi Naveen,

> From: linux-input-owner@vger.kernel.org [mailto:linux-input-
> owner@vger.kernel.org] On Behalf Of Greg KH
> Sent: Wednesday, November 03, 2010 1:20 PM
> To: Dmitry Torokhov
> Cc: Linus Walleij; Naveen Kumar GADDIPATI; linux-kernel@vger.kernel.org;
> STEricsson_nomadik_linux; linux-input@vger.kernel.org
> Subject: Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support
> 
> On Wed, Nov 03, 2010 at 12:07:52PM -0700, Dmitry Torokhov wrote:
> > On Wed, Nov 03, 2010 at 11:10:58AM -0700, Greg KH wrote:
> > > On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> > > > On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > > > > Greg KH wrote:
> > > > >
> > > > > >> +Wait for the official upstream synaptics rmi4 clearpad drivers as
> promised over the past few months
> > > > > >> +Merge any device support needed from this driver into it
> > > > > >> +Delete this driver
> > > > > >
> > > > > > Huh?
> > > > > >
> > > > > > Why not just add this driver to the kernel tree instead?  When the
> > > > > > "promised" driver then eventually shows up (who is promising it?)
> then
> > > > > > delete the thing.
> > > >
> > > > The same reason as there were several wireless drivers in staging?
> > >
> > > Ok, that's a good enough reason for me :)
> > >
> > > > > Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> > > > > patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> > > > > the other day, and OTOMH that was after discussions with Synaptics
> > > > > where they said they were working on a "real" driver (a rather
> > > > > complex RMI4 bus driver) and we believe they will fix that sooner
> > > > > or later.
> > > > >
> > > > > So, until sooner or later happens we thought we'd keep it in staging.
> > > > >
> > > > > If you prefer both Alan and we can probably submit our patches for
> > > > > inclusion in the proper place.
> > > > >
> > > > > A side effect may be that the Synaptics RMI4 people may have trouble
> > > > > to merge their driver into input/ since they may be requested to
> > > > > refactor the existing drivers to use it rather than merging new stuff,
> > > > > putting some burden on their shoulders.
> > > > >
> > > >
> > > > No, they have not been requested to change any existing [in tree]
> > > > drivers. They however been asked to convert to the driver core
> > > > primitives instead of rolling their own infprastructure to implement
> > > > devices and drivers binding.
> > >
> > > If you don't object to this driver going in, and there is a path forward
> > > in the future for it to be able to be removed, then I will be glad to
> > > add it.
> > >
> > > Can I add your Acked-by: to the patch for this?
> > >
> >
> > Umm... I haven't looked in detail, but I think it is sane enough for
> > staging... Much better than Alan's version that seemed to create a
> > separate input device for every finger. Needs to depend on INPUT and
> > probably regulators framework...  Probe function may call
> > input_free_device() after calling input_register_device() which is not
> > good.
> 
> Great, thanks for this.
> 
> > Basically staging is yours, you can add whatever you want to it ;)
> 
> Heh, well, I try to at least cooperate with the different subsystem
> maintainers.  I don't need even more people pissed-off at me than I
> normally get :)
> 
> I'll queue this up for .38.
> 

I have done some initial testing with this patch, it includes some modifications to the board file, I have a gpio acting as irq plus driver code itself

I won't be able to get events (board will hang) unless adding the following code, is this due to the usage of a gpio as interrupt? If you could please clarify...

@@ -481,6 +483,9 @@ static int synaptics_rmi4_sensor_report(struct synaptics_rmi4_data *pdata)
                                                                        rfi);
                }
        }
+
+       enable_irq(gpio_to_irq(pdata->irq_number));
+
        /* return the number of touch points */
        return touch;
 }
@@ -498,6 +503,8 @@ static irqreturn_t synaptics_rmi4_irq(int irq, void *data)
        struct synaptics_rmi4_data *pdata = data;
        int touch_count;
        do {
+               disable_irq_nosync(gpio_to_irq(pdata->irq_number));
+
                touch_count = synaptics_rmi4_sensor_report(pdata);
                if (touch_count)
                        wait_event_timeout(pdata->wait, pdata->touch_stopped,

Best Regards
Abraham

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Dmitry Torokhov]

On Wed, Nov 03, 2010 at 04:37:14PM -0500, Arce, Abraham wrote:
> Hi Naveen,
> 
> > From: linux-input-owner@vger.kernel.org [mailto:linux-input-
> > owner@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Wednesday, November 03, 2010 1:20 PM
> > To: Dmitry Torokhov
> > Cc: Linus Walleij; Naveen Kumar GADDIPATI; linux-kernel@vger.kernel.org;
> > STEricsson_nomadik_linux; linux-input@vger.kernel.org
> > Subject: Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support
> > 
> > On Wed, Nov 03, 2010 at 12:07:52PM -0700, Dmitry Torokhov wrote:
> > > On Wed, Nov 03, 2010 at 11:10:58AM -0700, Greg KH wrote:
> > > > On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> > > > > On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > > > > > Greg KH wrote:
> > > > > >
> > > > > > >> +Wait for the official upstream synaptics rmi4 clearpad drivers as
> > promised over the past few months
> > > > > > >> +Merge any device support needed from this driver into it
> > > > > > >> +Delete this driver
> > > > > > >
> > > > > > > Huh?
> > > > > > >
> > > > > > > Why not just add this driver to the kernel tree instead?  When the
> > > > > > > "promised" driver then eventually shows up (who is promising it?)
> > then
> > > > > > > delete the thing.
> > > > >
> > > > > The same reason as there were several wireless drivers in staging?
> > > >
> > > > Ok, that's a good enough reason for me :)
> > > >
> > > > > > Well, Alan (on behalf of Ramesh Agarwal) sent out a very similar
> > > > > > patch (Titled "Synaptics TM1217 Touchscreen Controller driver")
> > > > > > the other day, and OTOMH that was after discussions with Synaptics
> > > > > > where they said they were working on a "real" driver (a rather
> > > > > > complex RMI4 bus driver) and we believe they will fix that sooner
> > > > > > or later.
> > > > > >
> > > > > > So, until sooner or later happens we thought we'd keep it in staging.
> > > > > >
> > > > > > If you prefer both Alan and we can probably submit our patches for
> > > > > > inclusion in the proper place.
> > > > > >
> > > > > > A side effect may be that the Synaptics RMI4 people may have trouble
> > > > > > to merge their driver into input/ since they may be requested to
> > > > > > refactor the existing drivers to use it rather than merging new stuff,
> > > > > > putting some burden on their shoulders.
> > > > > >
> > > > >
> > > > > No, they have not been requested to change any existing [in tree]
> > > > > drivers. They however been asked to convert to the driver core
> > > > > primitives instead of rolling their own infprastructure to implement
> > > > > devices and drivers binding.
> > > >
> > > > If you don't object to this driver going in, and there is a path forward
> > > > in the future for it to be able to be removed, then I will be glad to
> > > > add it.
> > > >
> > > > Can I add your Acked-by: to the patch for this?
> > > >
> > >
> > > Umm... I haven't looked in detail, but I think it is sane enough for
> > > staging... Much better than Alan's version that seemed to create a
> > > separate input device for every finger. Needs to depend on INPUT and
> > > probably regulators framework...  Probe function may call
> > > input_free_device() after calling input_register_device() which is not
> > > good.
> > 
> > Great, thanks for this.
> > 
> > > Basically staging is yours, you can add whatever you want to it ;)
> > 
> > Heh, well, I try to at least cooperate with the different subsystem
> > maintainers.  I don't need even more people pissed-off at me than I
> > normally get :)
> > 
> > I'll queue this up for .38.
> > 
> 
> I have done some initial testing with this patch, it includes some modifications to the board file, I have a gpio acting as irq plus driver code itself
> 
> I won't be able to get events (board will hang) unless adding the following code, is this due to the usage of a gpio as interrupt? If you could please clarify...
> 
> @@ -481,6 +483,9 @@ static int synaptics_rmi4_sensor_report(struct synaptics_rmi4_data *pdata)
>                                                                         rfi);
>                 }
>         }
> +
> +       enable_irq(gpio_to_irq(pdata->irq_number));
> +
>         /* return the number of touch points */
>         return touch;
>  }
> @@ -498,6 +503,8 @@ static irqreturn_t synaptics_rmi4_irq(int irq, void *data)
>         struct synaptics_rmi4_data *pdata = data;
>         int touch_count;
>         do {
> +               disable_irq_nosync(gpio_to_irq(pdata->irq_number));
> +
>                 touch_count = synaptics_rmi4_sensor_report(pdata);
>                 if (touch_count)
>                         wait_event_timeout(pdata->wait, pdata->touch_stopped,
> 

It probably wants a threaded IRQ...

-- 
Dmitry

RE: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Naveen Kumar GADDIPATI]

Hi Arce,

I'm also the GPIO pin for interrupt with request threaded irq .
I'm passing the irq_type from the platform data. 
Which irq_type are you using for your platform?

Thanks & Regards,
Naveen


> -----Original Message-----
> From: Arce, Abraham [mailto:x0066660@ti.com]
> Sent: Thursday, November 04, 2010 3:07 AM
> To: Greg KH; Dmitry Torokhov
> Cc: Linus WALLEIJ; Naveen Kumar GADDIPATI; linux-
> kernel@vger.kernel.org; STEricsson_nomadik_linux; linux-
> input@vger.kernel.org
> Subject: RE: [PATCHv1] staging: Synaptics RMI4 touchpad driver support
> 
> Hi Naveen,
> 
> > From: linux-input-owner@vger.kernel.org [mailto:linux-input-
> > owner@vger.kernel.org] On Behalf Of Greg KH
> > Sent: Wednesday, November 03, 2010 1:20 PM
> > To: Dmitry Torokhov
> > Cc: Linus Walleij; Naveen Kumar GADDIPATI; linux-
> kernel@vger.kernel.org;
> > STEricsson_nomadik_linux; linux-input@vger.kernel.org
> > Subject: Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver
> support
> >
> > On Wed, Nov 03, 2010 at 12:07:52PM -0700, Dmitry Torokhov wrote:
> > > On Wed, Nov 03, 2010 at 11:10:58AM -0700, Greg KH wrote:
> > > > On Tue, Nov 02, 2010 at 08:40:30AM -0700, Dmitry Torokhov wrote:
> > > > > On Tue, Nov 02, 2010 at 03:14:48PM +0100, Linus Walleij wrote:
> > > > > > Greg KH wrote:
> > > > > >
> > > > > > >> +Wait for the official upstream synaptics rmi4 clearpad
> drivers as
> > promised over the past few months
> > > > > > >> +Merge any device support needed from this driver into it
> > > > > > >> +Delete this driver
> > > > > > >
> > > > > > > Huh?
> > > > > > >
> > > > > > > Why not just add this driver to the kernel tree instead?
> When the
> > > > > > > "promised" driver then eventually shows up (who is
> promising it?)
> > then
> > > > > > > delete the thing.
> > > > >
> > > > > The same reason as there were several wireless drivers in
> staging?
> > > >
> > > > Ok, that's a good enough reason for me :)
> > > >
> > > > > > Well, Alan (on behalf of Ramesh Agarwal) sent out a very
> similar
> > > > > > patch (Titled "Synaptics TM1217 Touchscreen Controller
> driver")
> > > > > > the other day, and OTOMH that was after discussions with
> Synaptics
> > > > > > where they said they were working on a "real" driver (a
> rather
> > > > > > complex RMI4 bus driver) and we believe they will fix that
> sooner
> > > > > > or later.
> > > > > >
> > > > > > So, until sooner or later happens we thought we'd keep it in
> staging.
> > > > > >
> > > > > > If you prefer both Alan and we can probably submit our
> patches for
> > > > > > inclusion in the proper place.
> > > > > >
> > > > > > A side effect may be that the Synaptics RMI4 people may have
> trouble
> > > > > > to merge their driver into input/ since they may be requested
> to
> > > > > > refactor the existing drivers to use it rather than merging
> new stuff,
> > > > > > putting some burden on their shoulders.
> > > > > >
> > > > >
> > > > > No, they have not been requested to change any existing [in
> tree]
> > > > > drivers. They however been asked to convert to the driver core
> > > > > primitives instead of rolling their own infprastructure to
> implement
> > > > > devices and drivers binding.
> > > >
> > > > If you don't object to this driver going in, and there is a path
> forward
> > > > in the future for it to be able to be removed, then I will be
> glad to
> > > > add it.
> > > >
> > > > Can I add your Acked-by: to the patch for this?
> > > >
> > >
> > > Umm... I haven't looked in detail, but I think it is sane enough
> for
> > > staging... Much better than Alan's version that seemed to create a
> > > separate input device for every finger. Needs to depend on INPUT
> and
> > > probably regulators framework...  Probe function may call
> > > input_free_device() after calling input_register_device() which is
> not
> > > good.
> >
> > Great, thanks for this.
> >
> > > Basically staging is yours, you can add whatever you want to it ;)
> >
> > Heh, well, I try to at least cooperate with the different subsystem
> > maintainers.  I don't need even more people pissed-off at me than I
> > normally get :)
> >
> > I'll queue this up for .38.
> >
> 
> I have done some initial testing with this patch, it includes some
> modifications to the board file, I have a gpio acting as irq plus
> driver code itself
> 
> I won't be able to get events (board will hang) unless adding the
> following code, is this due to the usage of a gpio as interrupt? If you
> could please clarify...
> 
> @@ -481,6 +483,9 @@ static int synaptics_rmi4_sensor_report(struct
> synaptics_rmi4_data *pdata)
> 
> rfi);
>                 }
>         }
> +
> +       enable_irq(gpio_to_irq(pdata->irq_number));
> +
>         /* return the number of touch points */
>         return touch;
>  }
> @@ -498,6 +503,8 @@ static irqreturn_t synaptics_rmi4_irq(int irq, void
> *data)
>         struct synaptics_rmi4_data *pdata = data;
>         int touch_count;
>         do {
> +               disable_irq_nosync(gpio_to_irq(pdata->irq_number));
> +
>                 touch_count = synaptics_rmi4_sensor_report(pdata);
>                 if (touch_count)
>                         wait_event_timeout(pdata->wait, pdata-
> >touch_stopped,
> 
> Best Regards
> Abraham

RE: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Arce, Abraham]

Hi Naveen, Dmitry,

> From: Naveen Kumar GADDIPATI [mailto:naveen.gaddipati@stericsson.com]
> 
> Hi Arce,
> 
> I'm also the GPIO pin for interrupt with request threaded irq .
> I'm passing the irq_type from the platform data.
> Which irq_type are you using for your platform?
> 

I am using the following flags

  IRQF_DISABLED | IRQF_TRIGGER_LOW | IRQF_TRIGGER_FALLING

Should I get rid of the first one, IRQF_DISABLED?

  IRQF_DISABLED - keep irqs disabled when calling the action handler

Best Regards
Abraham

RE: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Naveen Kumar GADDIPATI]

Hi Arce,

I'm using irq type as IRQF_TRIGGER_FALLING | IRQF_SHARED.

Thanks & Regards,
Naveen

> -----Original Message-----
> From: Arce, Abraham [mailto:x0066660@ti.com]
> Sent: Thursday, November 04, 2010 11:16 AM
> To: Naveen Kumar GADDIPATI; Dmitry Torokhov
> Cc: Linus WALLEIJ; linux-kernel@vger.kernel.org;
> STEricsson_nomadik_linux; linux-input@vger.kernel.org; Greg KH
> Subject: RE: [PATCHv1] staging: Synaptics RMI4 touchpad driver support
> 
> Hi Naveen, Dmitry,
> 
> > From: Naveen Kumar GADDIPATI [mailto:naveen.gaddipati@stericsson.com]
> >
> > Hi Arce,
> >
> > I'm also the GPIO pin for interrupt with request threaded irq .
> > I'm passing the irq_type from the platform data.
> > Which irq_type are you using for your platform?
> >
> 
> I am using the following flags
> 
>   IRQF_DISABLED | IRQF_TRIGGER_LOW | IRQF_TRIGGER_FALLING
> 
> Should I get rid of the first one, IRQF_DISABLED?
> 
>   IRQF_DISABLED - keep irqs disabled when calling the action handler
> 
> Best Regards
> Abraham

Re: [PATCHv1] staging: Synaptics RMI4 touchpad driver support

[Dmitry Torokhov]

Hi Arce,

On Thu, Nov 04, 2010 at 12:45:45AM -0500, Arce, Abraham wrote:
> Hi Naveen, Dmitry,
> 
> > From: Naveen Kumar GADDIPATI [mailto:naveen.gaddipati@stericsson.com]
> > 
> > Hi Arce,
> > 
> > I'm also the GPIO pin for interrupt with request threaded irq .
> > I'm passing the irq_type from the platform data.
> > Which irq_type are you using for your platform?
> > 
> 
> I am using the following flags
> 
>   IRQF_DISABLED | IRQF_TRIGGER_LOW | IRQF_TRIGGER_FALLING
> 
> Should I get rid of the first one, IRQF_DISABLED?
> 
>   IRQF_DISABLED - keep irqs disabled when calling the action handler
> 

You probably want IRQF_TRIGGER_LOW | IRQF_ONESHOT if your interrupt is
level tiggered.

IRQF_TRIGGER_LOW | IRQF_TRIGGER_FALLING mixes edge and level options and
thus I don't think is proper.

-- 
Dmitry