Driver support for TI's quadrature encoder module

Driver support for TI's quadrature encoder module

[AnilKumar, Chimata]

Hi All,

I am developing a driver for TI's enhanced Quadrature Encoder Pulse
(eQEP) module. Details of the module at
http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf

Little description about the module:-

This module is used for direct interface with a linear or rotary
incremental encoder.

Main features of the module:
a. Provides the direction of the motor (clock or anti-clock)
b. Provides position count values, which can be used to compute speed
   of a machine (motor/generator)
c. Generate a sync output from position compare sub-module
d. Can be used for High & Low speed measurements

This module has 4 inputs from external rotary/linear encoder.
a. Input A (Input from external rotary encoder, a pulse train)
b. Input B (Input from external rotary encoder, a pulse train)
c. Index Event (Input from external rotary encoder, a index event.
   This can be used as output, which can be generated after
   position compare)
d. Strobe Event (Input from external rotary encoder, a strobe event.
   This can be used as output, which can be generated after
   position compare)

The module provides pre-analyzed data based on the above four input
signals. We can use the data directly for knowing the position and
direction details.

I have few questions related to this:-

1. What subsystem this driver fit into? Input subsystem or UIO
subsystem?

Why I think it may fit into UIO subsystem?
a. Same driver is used for lot of applications like motor control,
volume control and menu navigation. This means we have to provide
lot of flexibility to the user in configuring the hardware to work
for different applications.

Why I think it may fit into Input subsystem?
a. The module is receiving the signals from external encoder. Based
on the signals it will generate some events, which we have to handle
at the user space.
b. I found some encoder drivers are already present under input
subsystem (example drivers/input/misc/rotary-encoder.c)

But, the current rotary encoder drivers are developed for much simpler 
hardware.

It looks like we need some additional interfaces to cater to the
hardware capabilities. I am thinking of sysfs interfaces which
allow user to directly configure the hardware for position control,
position compare, input source selection, capture timer period,
speed and direction of rotation.

Is this the right way to proceed? Is there anyone working on such
enhancements with whom I can collaborate?

Any inputs on the above questions greatly appreciated.

Regards,
Anilkumar

Re: Driver support for TI's quadrature encoder module

[Greg KH]

On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
> Hi All,
> 
> I am developing a driver for TI's enhanced Quadrature Encoder Pulse
> (eQEP) module. Details of the module at
> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
> 
> Little description about the module:-
> 
> This module is used for direct interface with a linear or rotary
> incremental encoder.
> 
> Main features of the module:
> a. Provides the direction of the motor (clock or anti-clock)
> b. Provides position count values, which can be used to compute speed
>    of a machine (motor/generator)
> c. Generate a sync output from position compare sub-module
> d. Can be used for High & Low speed measurements
> 
> This module has 4 inputs from external rotary/linear encoder.
> a. Input A (Input from external rotary encoder, a pulse train)
> b. Input B (Input from external rotary encoder, a pulse train)
> c. Index Event (Input from external rotary encoder, a index event.
>    This can be used as output, which can be generated after
>    position compare)
> d. Strobe Event (Input from external rotary encoder, a strobe event.
>    This can be used as output, which can be generated after
>    position compare)
> 
> The module provides pre-analyzed data based on the above four input
> signals. We can use the data directly for knowing the position and
> direction details.
> 
> I have few questions related to this:-
> 
> 1. What subsystem this driver fit into? Input subsystem or UIO
> subsystem?
> 
> Why I think it may fit into UIO subsystem?
> a. Same driver is used for lot of applications like motor control,
> volume control and menu navigation. This means we have to provide
> lot of flexibility to the user in configuring the hardware to work
> for different applications.

Does it use the UIO interface to userspace?  If not, then it's not a UIO
driver.

> Why I think it may fit into Input subsystem?
> a. The module is receiving the signals from external encoder. Based
> on the signals it will generate some events, which we have to handle
> at the user space.
> b. I found some encoder drivers are already present under input
> subsystem (example drivers/input/misc/rotary-encoder.c)
> 
> But, the current rotary encoder drivers are developed for much simpler 
> hardware.
> 
> It looks like we need some additional interfaces to cater to the
> hardware capabilities. I am thinking of sysfs interfaces which
> allow user to directly configure the hardware for position control,
> position compare, input source selection, capture timer period,
> speed and direction of rotation.

That sounds like you want the IIO interface in drivers/staging/iio/
right?  That api handles all sorts of stuff like this.

greg k-h

Re: Driver support for TI's quadrature encoder module

[Jonathan Cameron]

On 09/08/11 15:54, Greg KH wrote:
> On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
>> Hi All,
>>
>> I am developing a driver for TI's enhanced Quadrature Encoder Pulse
>> (eQEP) module. Details of the module at
>> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
>>
>> Little description about the module:-
>>
>> This module is used for direct interface with a linear or rotary
>> incremental encoder.
>>
>> Main features of the module:
>> a. Provides the direction of the motor (clock or anti-clock)
>> b. Provides position count values, which can be used to compute speed
>>    of a machine (motor/generator)
>> c. Generate a sync output from position compare sub-module
>> d. Can be used for High & Low speed measurements
>>
>> This module has 4 inputs from external rotary/linear encoder.
>> a. Input A (Input from external rotary encoder, a pulse train)
>> b. Input B (Input from external rotary encoder, a pulse train)
>> c. Index Event (Input from external rotary encoder, a index event.
>>    This can be used as output, which can be generated after
>>    position compare)
>> d. Strobe Event (Input from external rotary encoder, a strobe event.
>>    This can be used as output, which can be generated after
>>    position compare)
>>
>> The module provides pre-analyzed data based on the above four input
>> signals. We can use the data directly for knowing the position and
>> direction details.
>>
>> I have few questions related to this:-
>>
>> 1. What subsystem this driver fit into? Input subsystem or UIO
>> subsystem?
>>
>> Why I think it may fit into UIO subsystem?
>> a. Same driver is used for lot of applications like motor control,
>> volume control and menu navigation. This means we have to provide
>> lot of flexibility to the user in configuring the hardware to work
>> for different applications.
> 
> Does it use the UIO interface to userspace?  If not, then it's not a UIO
> driver.
> 
>> Why I think it may fit into Input subsystem?
>> a. The module is receiving the signals from external encoder. Based
>> on the signals it will generate some events, which we have to handle
>> at the user space.
>> b. I found some encoder drivers are already present under input
>> subsystem (example drivers/input/misc/rotary-encoder.c)
>>
>> But, the current rotary encoder drivers are developed for much simpler 
>> hardware.
>>
>> It looks like we need some additional interfaces to cater to the
>> hardware capabilities. I am thinking of sysfs interfaces which
>> allow user to directly configure the hardware for position control,
>> position compare, input source selection, capture timer period,
>> speed and direction of rotation.
> 
> That sounds like you want the IIO interface in drivers/staging/iio/
> right?  That api handles all sorts of stuff like this.
Certainly possible - always happy to support new device types.

We have some resolvers in there already, and based on a hundred mile view
this is similar...  From what I recall those interfaces are pretty messy
right now, but looking at it another way, that gives us more flexibility
to mess around with them to ensure they cover your part as well.

Based on really quick scan of datasheet, looks like we have 
* some basic readouts,
* a couple of latches on them (handy for precisely timed data grabs),
* periodic trigger,
* watchdog on motor stalls - could be couched as a rate of change threshold?

Some shadow registers that may be a little fiddly, but other than it measuring
something a bit different looks like a fairly standard IIO part.

Jonathan

Re: Driver support for TI's quadrature encoder module

[Jonathan Cameron]

On 09/08/11 17:50, Jonathan Cameron wrote:
> On 09/08/11 15:54, Greg KH wrote:
>> On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
>>> Hi All,
>>>
>>> I am developing a driver for TI's enhanced Quadrature Encoder Pulse
>>> (eQEP) module. Details of the module at
>>> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
>>>
>>> Little description about the module:-
>>>
>>> This module is used for direct interface with a linear or rotary
>>> incremental encoder.
>>>
>>> Main features of the module:
>>> a. Provides the direction of the motor (clock or anti-clock)
>>> b. Provides position count values, which can be used to compute speed
>>>    of a machine (motor/generator)
>>> c. Generate a sync output from position compare sub-module
>>> d. Can be used for High & Low speed measurements
>>>
>>> This module has 4 inputs from external rotary/linear encoder.
>>> a. Input A (Input from external rotary encoder, a pulse train)
>>> b. Input B (Input from external rotary encoder, a pulse train)
>>> c. Index Event (Input from external rotary encoder, a index event.
>>>    This can be used as output, which can be generated after
>>>    position compare)
>>> d. Strobe Event (Input from external rotary encoder, a strobe event.
>>>    This can be used as output, which can be generated after
>>>    position compare)
>>>
>>> The module provides pre-analyzed data based on the above four input
>>> signals. We can use the data directly for knowing the position and
>>> direction details.
>>>
>>> I have few questions related to this:-
>>>
>>> 1. What subsystem this driver fit into? Input subsystem or UIO
>>> subsystem?
>>>
>>> Why I think it may fit into UIO subsystem?
>>> a. Same driver is used for lot of applications like motor control,
>>> volume control and menu navigation. This means we have to provide
>>> lot of flexibility to the user in configuring the hardware to work
>>> for different applications.
>>
>> Does it use the UIO interface to userspace?  If not, then it's not a UIO
>> driver.
>>
>>> Why I think it may fit into Input subsystem?
>>> a. The module is receiving the signals from external encoder. Based
>>> on the signals it will generate some events, which we have to handle
>>> at the user space.
>>> b. I found some encoder drivers are already present under input
>>> subsystem (example drivers/input/misc/rotary-encoder.c)
>>>
>>> But, the current rotary encoder drivers are developed for much simpler 
>>> hardware.
>>>
>>> It looks like we need some additional interfaces to cater to the
>>> hardware capabilities. I am thinking of sysfs interfaces which
>>> allow user to directly configure the hardware for position control,
>>> position compare, input source selection, capture timer period,
>>> speed and direction of rotation.
>>
>> That sounds like you want the IIO interface in drivers/staging/iio/
>> right?  That api handles all sorts of stuff like this.
> Certainly possible - always happy to support new device types.
> 
> We have some resolvers in there already, and based on a hundred mile view
> this is similar...  From what I recall those interfaces are pretty messy
> right now, but looking at it another way, that gives us more flexibility
> to mess around with them to ensure they cover your part as well.
I'll rephrase this having taken a look. The current resolver drivers conform
to our standard interface in now way whatsoever.  So whatever you do,
don't copy them!  Along with meters drivers, those are the areas we haven't
cleaned up at all yet (also a smattering of other drivers in terrible state
for one reason or another elsewhere)
> 
> Based on really quick scan of datasheet, looks like we have 
> * some basic readouts,
> * a couple of latches on them (handy for precisely timed data grabs),
> * periodic trigger,
> * watchdog on motor stalls - could be couched as a rate of change threshold?
> 
> Some shadow registers that may be a little fiddly, but other than it measuring
> something a bit different looks like a fairly standard IIO part.
> 
> Jonathan

RE: Driver support for TI's quadrature encoder module

[AnilKumar, Chimata]

Hi All,

Thanks for quick reply.

On Fri, Sep 09, 2011 at 17:09:09, Jonathan Cameron wrote:
> On 09/08/11 17:50, Jonathan Cameron wrote:
> > On 09/08/11 15:54, Greg KH wrote:
> >> On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
> >>> Hi All,
> >>>
> >>> I am developing a driver for TI's enhanced Quadrature Encoder Pulse
> >>> (eQEP) module. Details of the module at 
> >>> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
> >>>
> >>> Little description about the module:-
> >>>
> >>> This module is used for direct interface with a linear or rotary 
> >>> incremental encoder.
> >>>
> >>> Main features of the module:
> >>> a. Provides the direction of the motor (clock or anti-clock) b. 
> >>> Provides position count values, which can be used to compute speed
> >>>    of a machine (motor/generator)
> >>> c. Generate a sync output from position compare sub-module d. Can be 
> >>> used for High & Low speed measurements
> >>>
> >>> This module has 4 inputs from external rotary/linear encoder.
> >>> a. Input A (Input from external rotary encoder, a pulse train) b. 
> >>> Input B (Input from external rotary encoder, a pulse train) c. Index 
> >>> Event (Input from external rotary encoder, a index event.
> >>>    This can be used as output, which can be generated after
> >>>    position compare)
> >>> d. Strobe Event (Input from external rotary encoder, a strobe event.
> >>>    This can be used as output, which can be generated after
> >>>    position compare)
> >>>
> >>> The module provides pre-analyzed data based on the above four input 
> >>> signals. We can use the data directly for knowing the position and 
> >>> direction details.
> >>>
> >>> I have few questions related to this:-
> >>>
> >>> 1. What subsystem this driver fit into? Input subsystem or UIO 
> >>> subsystem?
> >>>
> >>> Why I think it may fit into UIO subsystem?
> >>> a. Same driver is used for lot of applications like motor control, 
> >>> volume control and menu navigation. This means we have to provide 
> >>> lot of flexibility to the user in configuring the hardware to work 
> >>> for different applications.
> >>
> >> Does it use the UIO interface to userspace?  If not, then it's not a 
> >> UIO driver.
> >>
> >>> Why I think it may fit into Input subsystem?
> >>> a. The module is receiving the signals from external encoder. Based 
> >>> on the signals it will generate some events, which we have to handle 
> >>> at the user space.
> >>> b. I found some encoder drivers are already present under input 
> >>> subsystem (example drivers/input/misc/rotary-encoder.c)
> >>>
> >>> But, the current rotary encoder drivers are developed for much 
> >>> simpler hardware.
> >>>
> >>> It looks like we need some additional interfaces to cater to the 
> >>> hardware capabilities. I am thinking of sysfs interfaces which allow 
> >>> user to directly configure the hardware for position control, 
> >>> position compare, input source selection, capture timer period, 
> >>> speed and direction of rotation.
> >>
> >> That sounds like you want the IIO interface in drivers/staging/iio/ 
> >> right?  That api handles all sorts of stuff like this.
> > Certainly possible - always happy to support new device types.
> > 
> > We have some resolvers in there already, and based on a hundred mile 
> > view this is similar...  From what I recall those interfaces are 
> > pretty messy right now, but looking at it another way, that gives us 
> > more flexibility to mess around with them to ensure they cover your part as well.
> I'll rephrase this having taken a look. The current resolver drivers conform to our standard interface in now way whatsoever.  So whatever you do, don't copy them!  Along with meters drivers, those are the areas we haven't cleaned up at all yet (also a smattering of other drivers in terrible state for one reason or another elsewhere)

Jonathan, Thanks for the pointers

I did not know about IIO interface so far.
Will study it and come up with some patches
for my device based on this interface.

Anilkumar

Re: Driver support for TI's quadrature encoder module

[Jonathan Cameron]

On 09/09/11 13:05, AnilKumar, Chimata wrote:
> Hi All,
> 
> Thanks for quick reply.
> 
> On Fri, Sep 09, 2011 at 17:09:09, Jonathan Cameron wrote:
>> On 09/08/11 17:50, Jonathan Cameron wrote:
>>> On 09/08/11 15:54, Greg KH wrote:
>>>> On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
>>>>> Hi All,
>>>>>
>>>>> I am developing a driver for TI's enhanced Quadrature Encoder Pulse
>>>>> (eQEP) module. Details of the module at 
>>>>> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
>>>>>
>>>>> Little description about the module:-
>>>>>
>>>>> This module is used for direct interface with a linear or rotary 
>>>>> incremental encoder.
>>>>>
>>>>> Main features of the module:
>>>>> a. Provides the direction of the motor (clock or anti-clock) b. 
>>>>> Provides position count values, which can be used to compute speed
>>>>>    of a machine (motor/generator)
>>>>> c. Generate a sync output from position compare sub-module d. Can be 
>>>>> used for High & Low speed measurements
>>>>>
>>>>> This module has 4 inputs from external rotary/linear encoder.
>>>>> a. Input A (Input from external rotary encoder, a pulse train) b. 
>>>>> Input B (Input from external rotary encoder, a pulse train) c. Index 
>>>>> Event (Input from external rotary encoder, a index event.
>>>>>    This can be used as output, which can be generated after
>>>>>    position compare)
>>>>> d. Strobe Event (Input from external rotary encoder, a strobe event.
>>>>>    This can be used as output, which can be generated after
>>>>>    position compare)
>>>>>
>>>>> The module provides pre-analyzed data based on the above four input 
>>>>> signals. We can use the data directly for knowing the position and 
>>>>> direction details.
>>>>>
>>>>> I have few questions related to this:-
>>>>>
>>>>> 1. What subsystem this driver fit into? Input subsystem or UIO 
>>>>> subsystem?
>>>>>
>>>>> Why I think it may fit into UIO subsystem?
>>>>> a. Same driver is used for lot of applications like motor control, 
>>>>> volume control and menu navigation. This means we have to provide 
>>>>> lot of flexibility to the user in configuring the hardware to work 
>>>>> for different applications.
>>>>
>>>> Does it use the UIO interface to userspace?  If not, then it's not a 
>>>> UIO driver.
>>>>
>>>>> Why I think it may fit into Input subsystem?
>>>>> a. The module is receiving the signals from external encoder. Based 
>>>>> on the signals it will generate some events, which we have to handle 
>>>>> at the user space.
>>>>> b. I found some encoder drivers are already present under input 
>>>>> subsystem (example drivers/input/misc/rotary-encoder.c)
>>>>>
>>>>> But, the current rotary encoder drivers are developed for much 
>>>>> simpler hardware.
>>>>>
>>>>> It looks like we need some additional interfaces to cater to the 
>>>>> hardware capabilities. I am thinking of sysfs interfaces which allow 
>>>>> user to directly configure the hardware for position control, 
>>>>> position compare, input source selection, capture timer period, 
>>>>> speed and direction of rotation.
>>>>
>>>> That sounds like you want the IIO interface in drivers/staging/iio/ 
>>>> right?  That api handles all sorts of stuff like this.
>>> Certainly possible - always happy to support new device types.
>>>
>>> We have some resolvers in there already, and based on a hundred mile 
>>> view this is similar...  From what I recall those interfaces are 
>>> pretty messy right now, but looking at it another way, that gives us 
>>> more flexibility to mess around with them to ensure they cover your part as well.
>> I'll rephrase this having taken a look. The current resolver drivers conform to our standard interface in now way whatsoever.  So whatever you do, don't copy them!  Along with meters drivers, those are the areas we haven't cleaned up at all yet (also a smattering of other drivers in terrible state for one reason or another elsewhere)
> 
> Jonathan, Thanks for the pointers
> 
> I did not know about IIO interface so far.
> Will study it and come up with some patches
> for my device based on this interface.
Excellent.  Please do read the abi docs carefully in particular.
They don't cover this type of device, but will give you pointers
on what abi makes sense.  Posting that abi even before your driver
is ready to linux-iio will get that conversation underway (can often
take much longer to pin down interface naming etc
than reviewing/fixing the actual code!)

Thanks,

Jonathan

RE: Driver support for TI's quadrature encoder module

[AnilKumar, Chimata]

On Fri, Sep 09, 2011 at 17:57:14, Jonathan Cameron wrote:
> On 09/09/11 13:05, AnilKumar, Chimata wrote:
> > Hi All,
> > 
> > Thanks for quick reply.
> > 
> > On Fri, Sep 09, 2011 at 17:09:09, Jonathan Cameron wrote:
> >> On 09/08/11 17:50, Jonathan Cameron wrote:
> >>> On 09/08/11 15:54, Greg KH wrote:
> >>>> On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> I am developing a driver for TI's enhanced Quadrature Encoder 
> >>>>> Pulse
> >>>>> (eQEP) module. Details of the module at 
> >>>>> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
> >>>>>
> >>>>> Little description about the module:-
> >>>>>
> >>>>> This module is used for direct interface with a linear or rotary 
> >>>>> incremental encoder.
> >>>>>
> >>>>> Main features of the module:
> >>>>> a. Provides the direction of the motor (clock or anti-clock) b. 
> >>>>> Provides position count values, which can be used to compute speed
> >>>>>    of a machine (motor/generator)
> >>>>> c. Generate a sync output from position compare sub-module d. Can 
> >>>>> be used for High & Low speed measurements
> >>>>>
> >>>>> This module has 4 inputs from external rotary/linear encoder.
> >>>>> a. Input A (Input from external rotary encoder, a pulse train) b. 
> >>>>> Input B (Input from external rotary encoder, a pulse train) c. 
> >>>>> Index Event (Input from external rotary encoder, a index event.
> >>>>>    This can be used as output, which can be generated after
> >>>>>    position compare)
> >>>>> d. Strobe Event (Input from external rotary encoder, a strobe event.
> >>>>>    This can be used as output, which can be generated after
> >>>>>    position compare)
> >>>>>
> >>>>> The module provides pre-analyzed data based on the above four 
> >>>>> input signals. We can use the data directly for knowing the 
> >>>>> position and direction details.
> >>>>>
> >>>>> I have few questions related to this:-
> >>>>>
> >>>>> 1. What subsystem this driver fit into? Input subsystem or UIO 
> >>>>> subsystem?
> >>>>>
> >>>>> Why I think it may fit into UIO subsystem?
> >>>>> a. Same driver is used for lot of applications like motor control, 
> >>>>> volume control and menu navigation. This means we have to provide 
> >>>>> lot of flexibility to the user in configuring the hardware to work 
> >>>>> for different applications.
> >>>>
> >>>> Does it use the UIO interface to userspace?  If not, then it's not 
> >>>> a UIO driver.
> >>>>
> >>>>> Why I think it may fit into Input subsystem?
> >>>>> a. The module is receiving the signals from external encoder. 
> >>>>> Based on the signals it will generate some events, which we have 
> >>>>> to handle at the user space.
> >>>>> b. I found some encoder drivers are already present under input 
> >>>>> subsystem (example drivers/input/misc/rotary-encoder.c)
> >>>>>
> >>>>> But, the current rotary encoder drivers are developed for much 
> >>>>> simpler hardware.
> >>>>>
> >>>>> It looks like we need some additional interfaces to cater to the 
> >>>>> hardware capabilities. I am thinking of sysfs interfaces which 
> >>>>> allow user to directly configure the hardware for position 
> >>>>> control, position compare, input source selection, capture timer 
> >>>>> period, speed and direction of rotation.
> >>>>
> >>>> That sounds like you want the IIO interface in drivers/staging/iio/ 
> >>>> right?  That api handles all sorts of stuff like this.
> >>> Certainly possible - always happy to support new device types.
> >>>
> >>> We have some resolvers in there already, and based on a hundred mile 
> >>> view this is similar...  From what I recall those interfaces are 
> >>> pretty messy right now, but looking at it another way, that gives us 
> >>> more flexibility to mess around with them to ensure they cover your part as well.
> >> I'll rephrase this having taken a look. The current resolver drivers 
> >> conform to our standard interface in now way whatsoever.  So whatever 
> >> you do, don't copy them!  Along with meters drivers, those are the 
> >> areas we haven't cleaned up at all yet (also a smattering of other 
> >> drivers in terrible state for one reason or another elsewhere)
> > 
> > Jonathan, Thanks for the pointers
> > 
> > I did not know about IIO interface so far.
> > Will study it and come up with some patches for my device based on 
> > this interface.
> Excellent.  Please do read the abi docs carefully in particular.
> They don't cover this type of device, but will give you pointers on what abi makes sense.  Posting that abi even before your driver is ready to linux-iio will get that conversation underway (can often take much longer to pin down interface naming etc than reviewing/fixing the actual code!)

Sure, I will keep post my changes while doing the coding. So that I can make
a better code by end of it. And final reviewing would be less.

> 
> Thanks,
> 
> Jonathan
> 
> 

Re: Driver support for TI's quadrature encoder module

[Hans J. Koch]

On Thu, Sep 08, 2011 at 06:57:04PM +0530, AnilKumar, Chimata wrote:
> Hi All,
> 
> I am developing a driver for TI's enhanced Quadrature Encoder Pulse
> (eQEP) module. Details of the module at
> http://www.ti.com/lit/ug/sprufu8/sprufu8.pdf
> 
> Little description about the module:-
> 
> This module is used for direct interface with a linear or rotary
> incremental encoder.
> 
> Main features of the module:
> a. Provides the direction of the motor (clock or anti-clock)
> b. Provides position count values, which can be used to compute speed
>    of a machine (motor/generator)
> c. Generate a sync output from position compare sub-module
> d. Can be used for High & Low speed measurements
> 
> This module has 4 inputs from external rotary/linear encoder.
> a. Input A (Input from external rotary encoder, a pulse train)
> b. Input B (Input from external rotary encoder, a pulse train)
> c. Index Event (Input from external rotary encoder, a index event.
>    This can be used as output, which can be generated after
>    position compare)
> d. Strobe Event (Input from external rotary encoder, a strobe event.
>    This can be used as output, which can be generated after
>    position compare)
> 
> The module provides pre-analyzed data based on the above four input
> signals. We can use the data directly for knowing the position and
> direction details.
> 
> I have few questions related to this:-
> 
> 1. What subsystem this driver fit into? Input subsystem or UIO
> subsystem?

That depends on which bus your module appears. If it looks like
memory that can be mapped to userspace, then UIO could be the
right subsystem. If it has an i2c, spi, usb or similar interface,
then UIO is not the right choice.

You should also look for similar drivers already in the kernel.
Have a look at the IIO subsystem that is under development in
staging. It was designed for things like that. If there already is
a subsystem that handles similar devices, then it should be
preferred over UIO.

Thanks,
Hans