diff for duplicates of <4E9FE793.3050208@cam.ac.uk> diff --git a/a/1.txt b/N1/1.txt index 51194ef..50ac5a4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,123 +1,91 @@ On 10/20/11 09:49, Thomas Petazzoni wrote: > Le Thu, 20 Oct 2011 09:33:29 +0100, -> Jonathan Cameron <jic23@cam.ac.uk> a =C3=A9crit : ->=20 ->>> * Should we have some low-level ADC driver in arch/arm/mach-at91/ = -that +> Jonathan Cameron <jic23@cam.ac.uk> a ?crit : +> +>>> * Should we have some low-level ADC driver in arch/arm/mach-at91/ that >>> allows to request/release/access the ADC channels, this driver ->>> providing an internal kernel API used by the IIO ADC driver and = -the +>>> providing an internal kernel API used by the IIO ADC driver and the >>> touchscreen driver ? ->> That's definitely not going to go down well against moves to move ev= -erything ->> that looks like a driver out of the arch directories. An equivalent = -somewhere +>> That's definitely not going to go down well against moves to move everything +>> that looks like a driver out of the arch directories. An equivalent somewhere >> else might work though. ->=20 +> > Yes, of course if this needs to be implemented, it should be in some > other location than arch/arm, but not sure where (which is basically > the discussion that was started some time ago). ->=20 ->> Agreed. This is currently up in the air. The current state of those= - IIO ->> hooks is that they do pull only. Push based capture is tricky as fo= -r IIO ->> we want to control the triggering of the push at a far finer scale t= -han ->> makes sense for input. I'm not yet clear how these two will play tog= -ether. ->=20 -> My IIO knowledge is still too limited to understand what's the proble= -m +> +>> Agreed. This is currently up in the air. The current state of those IIO +>> hooks is that they do pull only. Push based capture is tricky as for IIO +>> we want to control the triggering of the push at a far finer scale than +>> makes sense for input. I'm not yet clear how these two will play together. +> +> My IIO knowledge is still too limited to understand what's the problem > with exposing an API for push-based capture. I'll give a quick summary: -Push in IIO is done from a trigger (imagine an oscilloscope). Those tr= -iggers -may be supplied by a dataready signal or from somewhere entirely differ= -ent. -Also multiple devices can be triggered by the same signal. Thus the da= -taready +Push in IIO is done from a trigger (imagine an oscilloscope). Those triggers +may be supplied by a dataready signal or from somewhere entirely different. +Also multiple devices can be triggered by the same signal. Thus the dataready from one chip can trigger a whole load of others. -Right now filtering functions prevent some devices from using anything = -other than -their own trigger. Setting defaults is also possible. If anything is t= -hen registered -to receive the data the trigger cannot be changed anyway so that will w= -ork here. +Right now filtering functions prevent some devices from using anything other than +their own trigger. Setting defaults is also possible. If anything is then registered +to receive the data the trigger cannot be changed anyway so that will work here. The other bit that makes it complex is the data flow. -This is done in the form of scans of a set of channels. The description= - of these -are more or less available to the core. Note the scan you get may well= - have +This is done in the form of scans of a set of channels. The description of these +are more or less available to the core. Note the scan you get may well have more channels in it than you explicitly requested. -These scans are then pushed into one of a set of different buffers. No= -te -All of the scan is currently pushed. That makes sense if you only have= - one -user of the data. Right now the pushing is done by the individual driv= -ers +These scans are then pushed into one of a set of different buffers. Note +All of the scan is currently pushed. That makes sense if you only have one +user of the data. Right now the pushing is done by the individual drivers but this could pass through the core. So things that stand in the way of more general use: -1) Userspace controlled triggers (apply to whole ADC) - can lock these = -down if +1) Userspace controlled triggers (apply to whole ADC) - can lock these down if say a touchscreen driver is using the device. 2) Single output stream of data. -3) Note there is deliberately no metadata in the stream. It is all out = -of band. +3) Note there is deliberately no metadata in the stream. It is all out of band. -Push to one driver is easy. Anything else needs a demux that is aware = -of the -stream contents. This bit doesn't exist and looks non trivial. The re= -al +Push to one driver is easy. Anything else needs a demux that is aware of the +stream contents. This bit doesn't exist and looks non trivial. The real trick is going to be keeping it light and fast (or entirely out of the way when not needed.) At some point I'll have a play with rerouting the data so such a demux can sit in the current flow (can use it to kill off unwanted channels). ->=20 ->> If we sit something underneath the IIO and input drivers (or use the= - lower ->> portions of IIO to do this) then the intent would be to have a fully= - generic +> +>> If we sit something underneath the IIO and input drivers (or use the lower +>> portions of IIO to do this) then the intent would be to have a fully generic >> input touchscreen driver on top. I'm not sure that's possible. ->=20 -> I am not sure it's possible to make the touchscreen driver generic. O= -n +> +> I am not sure it's possible to make the touchscreen driver generic. On > the G45, the ADC IP has some generic ADC registers, but also some > touchscreen-specific registers. So the touchscreen driver probably -> cannot be completely generic and some cooperation between the AT91 AD= -C +> cannot be completely generic and some cooperation between the AT91 ADC > driver and the AT91 touchscreen driver might be needed. I'd have to > look into more details on how the AT91 touchscreen thing works to > provide some more details here. ->=20 ->> For example are the switches on the G45's adc (from datasheet) somet= -hing that +> +>> For example are the switches on the G45's adc (from datasheet) something that >> all/many similar touch screen controllers have? ->=20 +> > I have no idea. ->=20 -> However, I have also seen a platform (SuperH 2A) where ADC channels a= -re +> +> However, I have also seen a platform (SuperH 2A) where ADC channels are > used for keypad handling. 4 ADCs channels, each connected to 4 keys, -> each having a different resistor. Depending on the voltage measured a= -t +> each having a different resistor. Depending on the voltage measured at > the ADC, you're capable of knowing which key of the 4x4 keypad is -> pressed. This is a different situation where the ADC values need to b= -e +> pressed. This is a different situation where the ADC values need to be > used by another in-kernel driver. That one is much easier to handle and indeed not that uncommon a hack. It really is just using the ADCs to get a value. Hence with suitable descriptive map it's easy to write a generic driver for it. Even easier if it's simply polled ;) ->=20 +> > Regards, ->=20 +> > Thomas diff --git a/a/content_digest b/N1/content_digest index 2222911..3e62efd 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,141 +5,102 @@ "ref\020111020090532.7df7af70@skate\0" "ref\04E9FDCD9.7030202@cam.ac.uk\0" "ref\020111020104919.303e3133@skate\0" - "From\0Jonathan Cameron <jic23@cam.ac.uk>\0" - "Subject\0Re: [PATCH 2/3] ARM: AT91: IIO: Add AT91 ADC driver.\0" + "From\0jic23@cam.ac.uk (Jonathan Cameron)\0" + "Subject\0[PATCH 2/3] ARM: AT91: IIO: Add AT91 ADC driver.\0" "Date\0Thu, 20 Oct 2011 10:19:15 +0100\0" - "To\0Thomas Petazzoni <thomas.petazzoni@free-electrons.com>\0" - "Cc\0Maxime Ripard <maxime.ripard@free-electrons.com>" - linux-iio@vger.kernel.org - Patrice Vilchez <patrice.vilchez@atmel.com> - Nicolas Ferre <nicolas.ferre@atmel.com> - linux-arm-kernel@lists.infradead.org - Mark Brown <broonie@opensource.wolfsonmicro.com> - " Linus Walleij <linus.walleij@linaro.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On 10/20/11 09:49, Thomas Petazzoni wrote:\n" "> Le Thu, 20 Oct 2011 09:33:29 +0100,\n" - "> Jonathan Cameron <jic23@cam.ac.uk> a =C3=A9crit :\n" - ">=20\n" - ">>> * Should we have some low-level ADC driver in arch/arm/mach-at91/ =\n" - "that\n" + "> Jonathan Cameron <jic23@cam.ac.uk> a ?crit :\n" + "> \n" + ">>> * Should we have some low-level ADC driver in arch/arm/mach-at91/ that\n" ">>> allows to request/release/access the ADC channels, this driver\n" - ">>> providing an internal kernel API used by the IIO ADC driver and =\n" - "the\n" + ">>> providing an internal kernel API used by the IIO ADC driver and the\n" ">>> touchscreen driver ?\n" - ">> That's definitely not going to go down well against moves to move ev=\n" - "erything\n" - ">> that looks like a driver out of the arch directories. An equivalent =\n" - "somewhere\n" + ">> That's definitely not going to go down well against moves to move everything\n" + ">> that looks like a driver out of the arch directories. An equivalent somewhere\n" ">> else might work though.\n" - ">=20\n" + "> \n" "> Yes, of course if this needs to be implemented, it should be in some\n" "> other location than arch/arm, but not sure where (which is basically\n" "> the discussion that was started some time ago).\n" - ">=20\n" - ">> Agreed. This is currently up in the air. The current state of those=\n" - " IIO\n" - ">> hooks is that they do pull only. Push based capture is tricky as fo=\n" - "r IIO\n" - ">> we want to control the triggering of the push at a far finer scale t=\n" - "han\n" - ">> makes sense for input. I'm not yet clear how these two will play tog=\n" - "ether.\n" - ">=20\n" - "> My IIO knowledge is still too limited to understand what's the proble=\n" - "m\n" + "> \n" + ">> Agreed. This is currently up in the air. The current state of those IIO\n" + ">> hooks is that they do pull only. Push based capture is tricky as for IIO\n" + ">> we want to control the triggering of the push at a far finer scale than\n" + ">> makes sense for input. I'm not yet clear how these two will play together.\n" + "> \n" + "> My IIO knowledge is still too limited to understand what's the problem\n" "> with exposing an API for push-based capture.\n" "I'll give a quick summary:\n" "\n" - "Push in IIO is done from a trigger (imagine an oscilloscope). Those tr=\n" - "iggers\n" - "may be supplied by a dataready signal or from somewhere entirely differ=\n" - "ent.\n" - "Also multiple devices can be triggered by the same signal. Thus the da=\n" - "taready\n" + "Push in IIO is done from a trigger (imagine an oscilloscope). Those triggers\n" + "may be supplied by a dataready signal or from somewhere entirely different.\n" + "Also multiple devices can be triggered by the same signal. Thus the dataready\n" "from one chip can trigger a whole load of others.\n" "\n" - "Right now filtering functions prevent some devices from using anything =\n" - "other than\n" - "their own trigger. Setting defaults is also possible. If anything is t=\n" - "hen registered\n" - "to receive the data the trigger cannot be changed anyway so that will w=\n" - "ork here.\n" + "Right now filtering functions prevent some devices from using anything other than\n" + "their own trigger. Setting defaults is also possible. If anything is then registered\n" + "to receive the data the trigger cannot be changed anyway so that will work here.\n" "\n" "The other bit that makes it complex is the data flow.\n" - "This is done in the form of scans of a set of channels. The description=\n" - " of these\n" - "are more or less available to the core. Note the scan you get may well=\n" - " have\n" + "This is done in the form of scans of a set of channels. The description of these\n" + "are more or less available to the core. Note the scan you get may well have\n" "more channels in it than you explicitly requested.\n" "\n" - "These scans are then pushed into one of a set of different buffers. No=\n" - "te\n" - "All of the scan is currently pushed. That makes sense if you only have=\n" - " one\n" - "user of the data. Right now the pushing is done by the individual driv=\n" - "ers\n" + "These scans are then pushed into one of a set of different buffers. Note\n" + "All of the scan is currently pushed. That makes sense if you only have one\n" + "user of the data. Right now the pushing is done by the individual drivers\n" "but this could pass through the core.\n" "\n" "So things that stand in the way of more general use:\n" "\n" - "1) Userspace controlled triggers (apply to whole ADC) - can lock these =\n" - "down if\n" + "1) Userspace controlled triggers (apply to whole ADC) - can lock these down if\n" "say a touchscreen driver is using the device.\n" "2) Single output stream of data.\n" - "3) Note there is deliberately no metadata in the stream. It is all out =\n" - "of band.\n" + "3) Note there is deliberately no metadata in the stream. It is all out of band.\n" "\n" - "Push to one driver is easy. Anything else needs a demux that is aware =\n" - "of the\n" - "stream contents. This bit doesn't exist and looks non trivial. The re=\n" - "al\n" + "Push to one driver is easy. Anything else needs a demux that is aware of the\n" + "stream contents. This bit doesn't exist and looks non trivial. The real\n" "trick is going to be keeping it light and fast (or entirely out of the\n" "way when not needed.)\n" "\n" "At some point I'll have a play with rerouting the data so such a demux\n" "can sit in the current flow (can use it to kill off unwanted channels).\n" "\n" - ">=20\n" - ">> If we sit something underneath the IIO and input drivers (or use the=\n" - " lower\n" - ">> portions of IIO to do this) then the intent would be to have a fully=\n" - " generic\n" + "> \n" + ">> If we sit something underneath the IIO and input drivers (or use the lower\n" + ">> portions of IIO to do this) then the intent would be to have a fully generic\n" ">> input touchscreen driver on top. I'm not sure that's possible.\n" - ">=20\n" - "> I am not sure it's possible to make the touchscreen driver generic. O=\n" - "n\n" + "> \n" + "> I am not sure it's possible to make the touchscreen driver generic. On\n" "> the G45, the ADC IP has some generic ADC registers, but also some\n" "> touchscreen-specific registers. So the touchscreen driver probably\n" - "> cannot be completely generic and some cooperation between the AT91 AD=\n" - "C\n" + "> cannot be completely generic and some cooperation between the AT91 ADC\n" "> driver and the AT91 touchscreen driver might be needed. I'd have to\n" "> look into more details on how the AT91 touchscreen thing works to\n" "> provide some more details here.\n" - ">=20\n" - ">> For example are the switches on the G45's adc (from datasheet) somet=\n" - "hing that\n" + "> \n" + ">> For example are the switches on the G45's adc (from datasheet) something that\n" ">> all/many similar touch screen controllers have?\n" - ">=20\n" + "> \n" "> I have no idea.\n" - ">=20\n" - "> However, I have also seen a platform (SuperH 2A) where ADC channels a=\n" - "re\n" + "> \n" + "> However, I have also seen a platform (SuperH 2A) where ADC channels are\n" "> used for keypad handling. 4 ADCs channels, each connected to 4 keys,\n" - "> each having a different resistor. Depending on the voltage measured a=\n" - "t\n" + "> each having a different resistor. Depending on the voltage measured at\n" "> the ADC, you're capable of knowing which key of the 4x4 keypad is\n" - "> pressed. This is a different situation where the ADC values need to b=\n" - "e\n" + "> pressed. This is a different situation where the ADC values need to be\n" "> used by another in-kernel driver.\n" "That one is much easier to handle and indeed not that uncommon a hack.\n" "It really is just using the ADCs to get a value. Hence with suitable\n" "descriptive map it's easy to write a generic driver for it.\n" "Even easier if it's simply polled ;)\n" - ">=20\n" + "> \n" "> Regards,\n" - ">=20\n" + "> \n" > Thomas -448292928f1a2dcaf6985d26863ab938bb6a0c23dae65c60e9a23399bddd89bc +0e454ce380fa0d7e7de4b248a647ebd79e0ddc86fed0a0945be16e5992c3e4fa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.