Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
On Mon, 8 Jan 2018 15:12:52 +0100 Ludovic Desroches wrote: > Hi Jonathan, Eugen, > > On Sat, Jan 06, 2018 at 03:05:37PM +, Jonathan Cameron wrote: > > On Thu, 4 Jan 2018 17:17:54 +0200 > > Eugen Hristev wrote: > > > > > On 29.12.2017 19:02, Jonathan Cameron wrote: > > > > On Fri, 22 Dec 2017 17:07:19 +0200 > > > > Eugen Hristev wrote: > > > > > > > >> The ADC IP supports position and pressure measurements for a touchpad > > > >> connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure > > > >> measurement support. > > > >> Using the inkern API, a driver can request a trigger and read the > > > >> channel values from the ADC. > > > >> The implementation provides a trigger named "touch" which can be > > > >> connected to a consumer driver. > > > >> Once a driver connects and attaches a pollfunc to this trigger, the > > > >> configure trigger callback is called, and then the ADC driver will > > > >> initialize pad measurement. > > > >> First step is to enable touchscreen 4wire support and enable > > > >> pen detect IRQ. > > > >> Once a pen is detected, a periodic trigger is setup to trigger every > > > >> 2 ms (e.g.) and sample the resistive touchscreen values. The trigger > > > >> poll > > > >> is called, and the consumer driver is then woke up, and it can read the > > > >> respective channels for the values : X, and Y for position and pressure > > > >> channel. > > > >> Because only one trigger can be active in hardware in the same time, > > > >> while touching the pad, the ADC will block any attempt to use the > > > >> triggered buffer. Same, conversions using the software trigger are also > > > >> impossible (since the periodic trigger is setup). > > > >> If some driver wants to attach while the trigger is in use, it will > > > >> also fail. > > > >> Once the pen is not detected anymore, the trigger is free for use > > > >> (hardware > > > >> or software trigger, with or without DMA). > > > >> Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled. > > > >> > > > >> Some parts of this patch are based on initial original work by > > > >> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy > > > >> > > > > OK, so comments inline. > > > > > > > > What I'm missing currently though is an explanation of why the slightly > > > > more standard arrangement of using a callback buffer doesn't work here. > > > > The only addition I think you need to do that is to allow a consumer to > > > > request a particular trigger. I also think some of the other provisions > > > > could be handled using standard features and slightly reducing the > > > > flexibility. > > > > I don't know for example if it's useful to allow other channels to be > > > > read when touch is not in progress or not. > > > > > > > > So restrictions: > > > > > > > > 1. Touch screen channels can only be read when touch is enabled. > > > > - use the available_scan_masks to control this. Or the callback that > > > > lets > > > > you do the same dynamically. > > > > 2. You need to push these channels to your consumer driver. > > > > - register a callback buffer rather than jumping through the hoops to > > > > insert your own pollfunc. That will call a function in your > > > > consumer, providing the data from the 3 channels directly. > > > > 3. You need to make sure it is using the right driver. For that you > > > > will I think need a new interface. > > > > > > > > Various other comments inline. I may well be missing something as this > > > > is > > > > a fair bit of complex code to read - if so then next version should have > > > > a clear cover letter describing why this more standard approach can't be > > > > used. > > > > > > Hello Jonathan and thanks for the review of my patch series, > > > > > > before starting and working over the required modifications and > > > suggestions that you sent me, I want to be a little more explicit about > > > the design of my implementation. > > > Hope this will clarify some things, and maybe I can as well understand > > > better what you have in mind to support this feature set. > > > > > > Why have I picked a pollfunction: We discussed a while back on the > > > mailing list that you do not have an inkern mechanism to expose the > > > triggers to other drivers, and that it may be a good idea to have it for > > > such kind of actually multi function device, instead of having a MFD > > > driver, an ADC driver, and an Input driver, all sharing the same > > > register map, the same IRQ , etc, with some kind of synchronization to > > > avoid stepping on each other for the hardware resource. > > > > No disagreement with that principle. > > > > > So I considered to expose the trigger by attaching and detaching > > > pollfunctions to it. Which is the main thing what we use a trigger for. > > > > Hmm. It's definitely one approach. But we do already have other drivers > > where the trigger is controlled by a consum
Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
Hi Jonathan, Eugen, On Sat, Jan 06, 2018 at 03:05:37PM +, Jonathan Cameron wrote: > On Thu, 4 Jan 2018 17:17:54 +0200 > Eugen Hristev wrote: > > > On 29.12.2017 19:02, Jonathan Cameron wrote: > > > On Fri, 22 Dec 2017 17:07:19 +0200 > > > Eugen Hristev wrote: > > > > > >> The ADC IP supports position and pressure measurements for a touchpad > > >> connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure > > >> measurement support. > > >> Using the inkern API, a driver can request a trigger and read the > > >> channel values from the ADC. > > >> The implementation provides a trigger named "touch" which can be > > >> connected to a consumer driver. > > >> Once a driver connects and attaches a pollfunc to this trigger, the > > >> configure trigger callback is called, and then the ADC driver will > > >> initialize pad measurement. > > >> First step is to enable touchscreen 4wire support and enable > > >> pen detect IRQ. > > >> Once a pen is detected, a periodic trigger is setup to trigger every > > >> 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll > > >> is called, and the consumer driver is then woke up, and it can read the > > >> respective channels for the values : X, and Y for position and pressure > > >> channel. > > >> Because only one trigger can be active in hardware in the same time, > > >> while touching the pad, the ADC will block any attempt to use the > > >> triggered buffer. Same, conversions using the software trigger are also > > >> impossible (since the periodic trigger is setup). > > >> If some driver wants to attach while the trigger is in use, it will > > >> also fail. > > >> Once the pen is not detected anymore, the trigger is free for use > > >> (hardware > > >> or software trigger, with or without DMA). > > >> Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled. > > >> > > >> Some parts of this patch are based on initial original work by > > >> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy > > >> > > > OK, so comments inline. > > > > > > What I'm missing currently though is an explanation of why the slightly > > > more standard arrangement of using a callback buffer doesn't work here. > > > The only addition I think you need to do that is to allow a consumer to > > > request a particular trigger. I also think some of the other provisions > > > could be handled using standard features and slightly reducing the > > > flexibility. > > > I don't know for example if it's useful to allow other channels to be > > > read when touch is not in progress or not. > > > > > > So restrictions: > > > > > > 1. Touch screen channels can only be read when touch is enabled. > > > - use the available_scan_masks to control this. Or the callback that > > > lets > > > you do the same dynamically. > > > 2. You need to push these channels to your consumer driver. > > > - register a callback buffer rather than jumping through the hoops to > > > insert your own pollfunc. That will call a function in your > > > consumer, providing the data from the 3 channels directly. > > > 3. You need to make sure it is using the right driver. For that you > > > will I think need a new interface. > > > > > > Various other comments inline. I may well be missing something as this is > > > a fair bit of complex code to read - if so then next version should have > > > a clear cover letter describing why this more standard approach can't be > > > used. > > > > Hello Jonathan and thanks for the review of my patch series, > > > > before starting and working over the required modifications and > > suggestions that you sent me, I want to be a little more explicit about > > the design of my implementation. > > Hope this will clarify some things, and maybe I can as well understand > > better what you have in mind to support this feature set. > > > > Why have I picked a pollfunction: We discussed a while back on the > > mailing list that you do not have an inkern mechanism to expose the > > triggers to other drivers, and that it may be a good idea to have it for > > such kind of actually multi function device, instead of having a MFD > > driver, an ADC driver, and an Input driver, all sharing the same > > register map, the same IRQ , etc, with some kind of synchronization to > > avoid stepping on each other for the hardware resource. > > No disagreement with that principle. > > > So I considered to expose the trigger by attaching and detaching > > pollfunctions to it. Which is the main thing what we use a trigger for. > > Hmm. It's definitely one approach. But we do already have other drivers > where the trigger is controlled by a consumer and to my mind that > is a cleaner approach as it doesn't short cut the equivalent of > doing it from userspace. > > drivers/iio/potentiostat/lmp91000.c does something similar though > for a rather different use. You need your consumer interface > to get the handle to the trigg
Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
On Thu, 4 Jan 2018 17:17:54 +0200 Eugen Hristev wrote: > On 29.12.2017 19:02, Jonathan Cameron wrote: > > On Fri, 22 Dec 2017 17:07:19 +0200 > > Eugen Hristev wrote: > > > >> The ADC IP supports position and pressure measurements for a touchpad > >> connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure > >> measurement support. > >> Using the inkern API, a driver can request a trigger and read the > >> channel values from the ADC. > >> The implementation provides a trigger named "touch" which can be > >> connected to a consumer driver. > >> Once a driver connects and attaches a pollfunc to this trigger, the > >> configure trigger callback is called, and then the ADC driver will > >> initialize pad measurement. > >> First step is to enable touchscreen 4wire support and enable > >> pen detect IRQ. > >> Once a pen is detected, a periodic trigger is setup to trigger every > >> 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll > >> is called, and the consumer driver is then woke up, and it can read the > >> respective channels for the values : X, and Y for position and pressure > >> channel. > >> Because only one trigger can be active in hardware in the same time, > >> while touching the pad, the ADC will block any attempt to use the > >> triggered buffer. Same, conversions using the software trigger are also > >> impossible (since the periodic trigger is setup). > >> If some driver wants to attach while the trigger is in use, it will > >> also fail. > >> Once the pen is not detected anymore, the trigger is free for use (hardware > >> or software trigger, with or without DMA). > >> Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled. > >> > >> Some parts of this patch are based on initial original work by > >> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy > >> > > OK, so comments inline. > > > > What I'm missing currently though is an explanation of why the slightly > > more standard arrangement of using a callback buffer doesn't work here. > > The only addition I think you need to do that is to allow a consumer to > > request a particular trigger. I also think some of the other provisions > > could be handled using standard features and slightly reducing the > > flexibility. > > I don't know for example if it's useful to allow other channels to be > > read when touch is not in progress or not. > > > > So restrictions: > > > > 1. Touch screen channels can only be read when touch is enabled. > > - use the available_scan_masks to control this. Or the callback that lets > > you do the same dynamically. > > 2. You need to push these channels to your consumer driver. > > - register a callback buffer rather than jumping through the hoops to > > insert your own pollfunc. That will call a function in your > > consumer, providing the data from the 3 channels directly. > > 3. You need to make sure it is using the right driver. For that you > > will I think need a new interface. > > > > Various other comments inline. I may well be missing something as this is > > a fair bit of complex code to read - if so then next version should have > > a clear cover letter describing why this more standard approach can't be > > used. > > Hello Jonathan and thanks for the review of my patch series, > > before starting and working over the required modifications and > suggestions that you sent me, I want to be a little more explicit about > the design of my implementation. > Hope this will clarify some things, and maybe I can as well understand > better what you have in mind to support this feature set. > > Why have I picked a pollfunction: We discussed a while back on the > mailing list that you do not have an inkern mechanism to expose the > triggers to other drivers, and that it may be a good idea to have it for > such kind of actually multi function device, instead of having a MFD > driver, an ADC driver, and an Input driver, all sharing the same > register map, the same IRQ , etc, with some kind of synchronization to > avoid stepping on each other for the hardware resource. No disagreement with that principle. > So I considered to expose the trigger by attaching and detaching > pollfunctions to it. Which is the main thing what we use a trigger for. Hmm. It's definitely one approach. But we do already have other drivers where the trigger is controlled by a consumer and to my mind that is a cleaner approach as it doesn't short cut the equivalent of doing it from userspace. drivers/iio/potentiostat/lmp91000.c does something similar though for a rather different use. You need your consumer interface to get the handle to the trigger in this case (the lmp91000 is actually providing the trigger rather than consuming it). > > So, what I had in mind, was to create a consumer driver that will > request triggers from the IIO device just like other drivers request > channels (part which is already done in IIO). > In
Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
On 29.12.2017 19:02, Jonathan Cameron wrote: On Fri, 22 Dec 2017 17:07:19 +0200 Eugen Hristev wrote: The ADC IP supports position and pressure measurements for a touchpad connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure measurement support. Using the inkern API, a driver can request a trigger and read the channel values from the ADC. The implementation provides a trigger named "touch" which can be connected to a consumer driver. Once a driver connects and attaches a pollfunc to this trigger, the configure trigger callback is called, and then the ADC driver will initialize pad measurement. First step is to enable touchscreen 4wire support and enable pen detect IRQ. Once a pen is detected, a periodic trigger is setup to trigger every 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll is called, and the consumer driver is then woke up, and it can read the respective channels for the values : X, and Y for position and pressure channel. Because only one trigger can be active in hardware in the same time, while touching the pad, the ADC will block any attempt to use the triggered buffer. Same, conversions using the software trigger are also impossible (since the periodic trigger is setup). If some driver wants to attach while the trigger is in use, it will also fail. Once the pen is not detected anymore, the trigger is free for use (hardware or software trigger, with or without DMA). Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled. Some parts of this patch are based on initial original work by Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy OK, so comments inline. What I'm missing currently though is an explanation of why the slightly more standard arrangement of using a callback buffer doesn't work here. The only addition I think you need to do that is to allow a consumer to request a particular trigger. I also think some of the other provisions could be handled using standard features and slightly reducing the flexibility. I don't know for example if it's useful to allow other channels to be read when touch is not in progress or not. So restrictions: 1. Touch screen channels can only be read when touch is enabled. - use the available_scan_masks to control this. Or the callback that lets you do the same dynamically. 2. You need to push these channels to your consumer driver. - register a callback buffer rather than jumping through the hoops to insert your own pollfunc. That will call a function in your consumer, providing the data from the 3 channels directly. 3. You need to make sure it is using the right driver. For that you will I think need a new interface. Various other comments inline. I may well be missing something as this is a fair bit of complex code to read - if so then next version should have a clear cover letter describing why this more standard approach can't be used. Hello Jonathan and thanks for the review of my patch series, before starting and working over the required modifications and suggestions that you sent me, I want to be a little more explicit about the design of my implementation. Hope this will clarify some things, and maybe I can as well understand better what you have in mind to support this feature set. Why have I picked a pollfunction: We discussed a while back on the mailing list that you do not have an inkern mechanism to expose the triggers to other drivers, and that it may be a good idea to have it for such kind of actually multi function device, instead of having a MFD driver, an ADC driver, and an Input driver, all sharing the same register map, the same IRQ , etc, with some kind of synchronization to avoid stepping on each other for the hardware resource. So I considered to expose the trigger by attaching and detaching pollfunctions to it. Which is the main thing what we use a trigger for. So, what I had in mind, was to create a consumer driver that will request triggers from the IIO device just like other drivers request channels (part which is already done in IIO). In order to do this I had to somehow wake up the consumer driver when new data was available from the touchscreen. So, having the IRQ only in the ADC device, and then on Pen detect and No pen detect just start or stop the periodic trigger, which needs to be polled. The magic part is that the consumer driver has a poll function already attached to this trigger, so the poll function is just called every time we have new data. The poll function is attached as an irq handler, and then we can reuse all the read_raw data by using a scheduled work from the consumer driver, to read the channels. To do this, the ADC registers a special trigger named "touch trigger" which is never enabled by the ADC driver. Instead, when a pollfunc is attached to it, the attach function will also configure it with enabled state. In the ADC, this means to start the touchscreen functionality. If
Re: [PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
On Fri, 22 Dec 2017 17:07:19 +0200 Eugen Hristev wrote: > The ADC IP supports position and pressure measurements for a touchpad > connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure > measurement support. > Using the inkern API, a driver can request a trigger and read the > channel values from the ADC. > The implementation provides a trigger named "touch" which can be > connected to a consumer driver. > Once a driver connects and attaches a pollfunc to this trigger, the > configure trigger callback is called, and then the ADC driver will > initialize pad measurement. > First step is to enable touchscreen 4wire support and enable > pen detect IRQ. > Once a pen is detected, a periodic trigger is setup to trigger every > 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll > is called, and the consumer driver is then woke up, and it can read the > respective channels for the values : X, and Y for position and pressure > channel. > Because only one trigger can be active in hardware in the same time, > while touching the pad, the ADC will block any attempt to use the > triggered buffer. Same, conversions using the software trigger are also > impossible (since the periodic trigger is setup). > If some driver wants to attach while the trigger is in use, it will > also fail. > Once the pen is not detected anymore, the trigger is free for use (hardware > or software trigger, with or without DMA). > Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled. > > Some parts of this patch are based on initial original work by > Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy > OK, so comments inline. What I'm missing currently though is an explanation of why the slightly more standard arrangement of using a callback buffer doesn't work here. The only addition I think you need to do that is to allow a consumer to request a particular trigger. I also think some of the other provisions could be handled using standard features and slightly reducing the flexibility. I don't know for example if it's useful to allow other channels to be read when touch is not in progress or not. So restrictions: 1. Touch screen channels can only be read when touch is enabled. - use the available_scan_masks to control this. Or the callback that lets you do the same dynamically. 2. You need to push these channels to your consumer driver. - register a callback buffer rather than jumping through the hoops to insert your own pollfunc. That will call a function in your consumer, providing the data from the 3 channels directly. 3. You need to make sure it is using the right driver. For that you will I think need a new interface. Various other comments inline. I may well be missing something as this is a fair bit of complex code to read - if so then next version should have a clear cover letter describing why this more standard approach can't be used. > Signed-off-by: Eugen Hristev > --- > drivers/iio/adc/at91-sama5d2_adc.c | 455 > - > 1 file changed, 446 insertions(+), 9 deletions(-) > > diff --git a/drivers/iio/adc/at91-sama5d2_adc.c > b/drivers/iio/adc/at91-sama5d2_adc.c > index 9610393..79eb197 100644 > --- a/drivers/iio/adc/at91-sama5d2_adc.c > +++ b/drivers/iio/adc/at91-sama5d2_adc.c > @@ -102,14 +102,26 @@ > #define AT91_SAMA5D2_LCDR0x20 > /* Interrupt Enable Register */ > #define AT91_SAMA5D2_IER 0x24 > +/* Interrupt Enable Register - TS X measurement ready */ > +#define AT91_SAMA5D2_IER_XRDY BIT(20) > +/* Interrupt Enable Register - TS Y measurement ready */ > +#define AT91_SAMA5D2_IER_YRDY BIT(21) > +/* Interrupt Enable Register - TS pressure measurement ready */ > +#define AT91_SAMA5D2_IER_PRDY BIT(22) > /* Interrupt Enable Register - general overrun error */ > #define AT91_SAMA5D2_IER_GOVRE BIT(25) > +/* Interrupt Enable Register - Pen detect */ > +#define AT91_SAMA5D2_IER_PENBIT(29) > +/* Interrupt Enable Register - No pen detect */ > +#define AT91_SAMA5D2_IER_NOPEN BIT(30) > /* Interrupt Disable Register */ > #define AT91_SAMA5D2_IDR 0x28 > /* Interrupt Mask Register */ > #define AT91_SAMA5D2_IMR 0x2c > /* Interrupt Status Register */ > #define AT91_SAMA5D2_ISR 0x30 > +/* Interrupt Status Register - Pen touching sense status */ > +#define AT91_SAMA5D2_ISR_PENS BIT(31) > /* Last Channel Trigger Mode Register */ > #define AT91_SAMA5D2_LCTMR 0x34 > /* Last Channel Compare Window Register */ > @@ -131,8 +143,37 @@ > #define AT91_SAMA5D2_CDR00x50 > /* Analog Control Register */ > #define AT91_SAMA5D2_ACR 0x94 > +/* Analog Control Register - Pen detect sensitivity mask */ > +#define AT91_SAMA5D2_ACR_PENDETSENS_MASKGENMASK(0, 1) > /* Touchscreen Mode Register */ > #define AT91_SAMA5D2_TSMR0xb0 > +/* Touchscreen Mode Register - No touch mode */ > +#define AT91_SAMA5D2_TSMR_TSMODE_NONE 0 > +/* Touchscreen Mode Register - 4 wire screen,
[PATCH 12/14] iio: adc: at91-sama5d2_adc: support for position and pressure channels
The ADC IP supports position and pressure measurements for a touchpad connected on channels 0,1,2,3 for a 4-wire touchscreen with pressure measurement support. Using the inkern API, a driver can request a trigger and read the channel values from the ADC. The implementation provides a trigger named "touch" which can be connected to a consumer driver. Once a driver connects and attaches a pollfunc to this trigger, the configure trigger callback is called, and then the ADC driver will initialize pad measurement. First step is to enable touchscreen 4wire support and enable pen detect IRQ. Once a pen is detected, a periodic trigger is setup to trigger every 2 ms (e.g.) and sample the resistive touchscreen values. The trigger poll is called, and the consumer driver is then woke up, and it can read the respective channels for the values : X, and Y for position and pressure channel. Because only one trigger can be active in hardware in the same time, while touching the pad, the ADC will block any attempt to use the triggered buffer. Same, conversions using the software trigger are also impossible (since the periodic trigger is setup). If some driver wants to attach while the trigger is in use, it will also fail. Once the pen is not detected anymore, the trigger is free for use (hardware or software trigger, with or without DMA). Channels 0,1,2 and 3 are unavailable if a touchscreen is enabled. Some parts of this patch are based on initial original work by Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy Signed-off-by: Eugen Hristev --- drivers/iio/adc/at91-sama5d2_adc.c | 455 - 1 file changed, 446 insertions(+), 9 deletions(-) diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c index 9610393..79eb197 100644 --- a/drivers/iio/adc/at91-sama5d2_adc.c +++ b/drivers/iio/adc/at91-sama5d2_adc.c @@ -102,14 +102,26 @@ #define AT91_SAMA5D2_LCDR 0x20 /* Interrupt Enable Register */ #define AT91_SAMA5D2_IER 0x24 +/* Interrupt Enable Register - TS X measurement ready */ +#define AT91_SAMA5D2_IER_XRDY BIT(20) +/* Interrupt Enable Register - TS Y measurement ready */ +#define AT91_SAMA5D2_IER_YRDY BIT(21) +/* Interrupt Enable Register - TS pressure measurement ready */ +#define AT91_SAMA5D2_IER_PRDY BIT(22) /* Interrupt Enable Register - general overrun error */ #define AT91_SAMA5D2_IER_GOVRE BIT(25) +/* Interrupt Enable Register - Pen detect */ +#define AT91_SAMA5D2_IER_PENBIT(29) +/* Interrupt Enable Register - No pen detect */ +#define AT91_SAMA5D2_IER_NOPEN BIT(30) /* Interrupt Disable Register */ #define AT91_SAMA5D2_IDR 0x28 /* Interrupt Mask Register */ #define AT91_SAMA5D2_IMR 0x2c /* Interrupt Status Register */ #define AT91_SAMA5D2_ISR 0x30 +/* Interrupt Status Register - Pen touching sense status */ +#define AT91_SAMA5D2_ISR_PENS BIT(31) /* Last Channel Trigger Mode Register */ #define AT91_SAMA5D2_LCTMR 0x34 /* Last Channel Compare Window Register */ @@ -131,8 +143,37 @@ #define AT91_SAMA5D2_CDR0 0x50 /* Analog Control Register */ #define AT91_SAMA5D2_ACR 0x94 +/* Analog Control Register - Pen detect sensitivity mask */ +#define AT91_SAMA5D2_ACR_PENDETSENS_MASKGENMASK(0, 1) /* Touchscreen Mode Register */ #define AT91_SAMA5D2_TSMR 0xb0 +/* Touchscreen Mode Register - No touch mode */ +#define AT91_SAMA5D2_TSMR_TSMODE_NONE 0 +/* Touchscreen Mode Register - 4 wire screen, no pressure measurement */ +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_NO_PRESS 1 +/* Touchscreen Mode Register - 4 wire screen, pressure measurement */ +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_PRESS2 +/* Touchscreen Mode Register - 5 wire screen */ +#define AT91_SAMA5D2_TSMR_TSMODE_5WIRE 3 +/* Touchscreen Mode Register - Average samples mask */ +#define AT91_SAMA5D2_TSMR_TSAV_MASK(3 << 4) +/* Touchscreen Mode Register - Average samples */ +#define AT91_SAMA5D2_TSMR_TSAV(x) ((x) << 4) +/* Touchscreen Mode Register - Touch/trigger frequency ratio mask */ +#define AT91_SAMA5D2_TSMR_TSFREQ_MASK (0xf << 8) +/* Touchscreen Mode Register - Touch/trigger freqency ratio */ +#define AT91_SAMA5D2_TSMR_TSFREQ(x)((x) << 8) +/* Touchscreen Mode Register - Pen Debounce Time mask */ +#define AT91_SAMA5D2_TSMR_PENDBC_MASK (0xf << 28) +/* Touchscreen Mode Register - Pen Debounce Time */ +#define AT91_SAMA5D2_TSMR_PENDBC(x)((x) << 28) +/* Touchscreen Mode Register - No DMA for touch measurements */ +#define AT91_SAMA5D2_TSMR_NOTSDMA BIT(22) +/* Touchscreen Mode Register - Disable pen detection */ +#define AT91_SAMA5D2_TSMR_PENDET_DIS(0 << 24) +/* Touchscreen Mode Register - Enable pen detection */ +#define AT91_SAMA5D2_TSMR_PENDET_ENABIT(24) + /* Touchscreen X Position Register */ #define AT91_SAMA5D2_XPOSR 0xb4 /* Touchscreen Y Position Register */ @@ -151,7 +192,
