diff for duplicates of <4E9FDCD9.7030202@cam.ac.uk> diff --git a/a/1.txt b/N1/1.txt index 71d8289..1c481ac 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,60 +1,44 @@ -Bringing in Mark and Linus as others who have been active in talking ab= -out +Bringing in Mark and Linus as others who have been active in talking about similar issues. > Hello, ->=20 +> > Le Wed, 19 Oct 2011 20:23:50 +0200, -> Maxime Ripard <maxime.ripard@free-electrons.com> a =C3=A9crit : ->=20 +> Maxime Ripard <maxime.ripard@free-electrons.com> a ?crit : +> >> On 19/10/2011 18:42, Jonathan Cameron wrote: ->>> Afraid I'm out of time for today, but just thought I'd ask one quic= -k question... +>>> Afraid I'm out of time for today, but just thought I'd ask one quick question... >>> >>> Why isn't this touchscreen ADC in input? >> ->> Because what I say in the Kconfig is mostly wrong... Sorry about tha= -t. +>> Because what I say in the Kconfig is mostly wrong... Sorry about that. >> ->> Actually, like I was saying, this ADC is present in a lot of AT91 So= -C, ->> and while it is always an ADC, sometimes (like on the G45), it can b= -e ->> used as a touchscreen controller, or even as both, with channels for= - the ->> touchscreen and channels as ADC. On the G20 however, it is just an A= -DC. +>> Actually, like I was saying, this ADC is present in a lot of AT91 SoC, +>> and while it is always an ADC, sometimes (like on the G45), it can be +>> used as a touchscreen controller, or even as both, with channels for the +>> touchscreen and channels as ADC. On the G20 however, it is just an ADC. >> ->> For now, the plan is only to support the ADC mode, so I put it in ad= -c. ->=20 +>> For now, the plan is only to support the ADC mode, so I put it in adc. +> > Just to expand a bit on this: there is already in the kernel an input -> driver for the AT91 touchscreen which uses some ADC channels (that ha= -ve +> driver for the AT91 touchscreen which uses some ADC channels (that have > additional touchscreen-related features: on the G45, you have 8 ADCs > channels, 4 can optionally be used for touchscreen, the 4 other are > just raw ADCs). ->=20 -> The ultimate goal is of course to make it possible to use both the II= -O +> +> The ultimate goal is of course to make it possible to use both the IIO > AT91 ADC driver and the AT91 touchscreen driver work simultaneously -> (with of course non-conflicting ADC channels usage). However, as show= -n -> by recent discussions on this list, it is not yet entirely clearly ho= -w +> (with of course non-conflicting ADC channels usage). However, as shown +> by recent discussions on this list, it is not yet entirely clearly how > this should be done: ->=20 -> * Should we have some low-level ADC driver in arch/arm/mach-at91/ th= -at +> +> * 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 th= -e +> 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 every= -thing -that looks like a driver out of the arch directories. An equivalent som= -ewhere +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 +> > sysfs access /dev/input/... > to ADC channels access to touchscreen > || || @@ -71,39 +55,32 @@ else might work though. > | release and access | > | ADC channels | > +---------------------+ ->=20 +> > * Should IIO provide some internal kernel API (as you suggested some > time ago) so that kernel drivers can use ADC channels ? ->=20 ->=20 +> +> > +-------------------+ -> | AT91 touchscreen | -> /dev/input/... access to touchsc= -reen +> | AT91 touchscreen | -> /dev/input/... access to touchscreen > +-------------------+ > || > \/ > +-------------------+ > | AT91 IIO | -> sysfs access to ADC channels > +-------------------+ ->=20 +> > Regards, ->=20 +> > Thomas -Agreed. This is currently up in the air. The current state of those II= -O -hooks is that they do pull only. Push based capture is tricky as for I= -IO +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 togeth= -er. +makes sense for input. I'm not yet clear how these two will play together. -If we sit something underneath the IIO and input drivers (or use the lo= -wer -portions of IIO to do this) then the intent would be to have a fully ge= -neric +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. For -example are the switches on the G45's adc (from datasheet) something th= -at +example are the switches on the G45's adc (from datasheet) something that all/many similar touch screen controllers have? I suppose we could support these in the chan_spec but only if it helps us to write a generic touch screen driver on top. I have no real diff --git a/a/content_digest b/N1/content_digest index 9a7a53c..3f6e551 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,76 +3,53 @@ "ref\04E9EFE0B.2030205@cam.ac.uk\0" "ref\04E9F15B6.90506@free-electrons.com\0" "ref\020111020090532.7df7af70@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 09:33:29 +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" - "Bringing in Mark and Linus as others who have been active in talking ab=\n" - "out\n" + "Bringing in Mark and Linus as others who have been active in talking about\n" "similar issues.\n" "> Hello,\n" - ">=20\n" + "> \n" "> Le Wed, 19 Oct 2011 20:23:50 +0200,\n" - "> Maxime Ripard <maxime.ripard@free-electrons.com> a =C3=A9crit :\n" - ">=20\n" + "> Maxime Ripard <maxime.ripard@free-electrons.com> a ?crit :\n" + "> \n" ">> On 19/10/2011 18:42, Jonathan Cameron wrote:\n" - ">>> Afraid I'm out of time for today, but just thought I'd ask one quic=\n" - "k question...\n" + ">>> Afraid I'm out of time for today, but just thought I'd ask one quick question...\n" ">>>\n" ">>> Why isn't this touchscreen ADC in input?\n" ">>\n" - ">> Because what I say in the Kconfig is mostly wrong... Sorry about tha=\n" - "t.\n" + ">> Because what I say in the Kconfig is mostly wrong... Sorry about that.\n" ">>\n" - ">> Actually, like I was saying, this ADC is present in a lot of AT91 So=\n" - "C,\n" - ">> and while it is always an ADC, sometimes (like on the G45), it can b=\n" - "e\n" - ">> used as a touchscreen controller, or even as both, with channels for=\n" - " the\n" - ">> touchscreen and channels as ADC. On the G20 however, it is just an A=\n" - "DC.\n" + ">> Actually, like I was saying, this ADC is present in a lot of AT91 SoC,\n" + ">> and while it is always an ADC, sometimes (like on the G45), it can be\n" + ">> used as a touchscreen controller, or even as both, with channels for the\n" + ">> touchscreen and channels as ADC. On the G20 however, it is just an ADC.\n" ">>\n" - ">> For now, the plan is only to support the ADC mode, so I put it in ad=\n" - "c.\n" - ">=20\n" + ">> For now, the plan is only to support the ADC mode, so I put it in adc.\n" + "> \n" "> Just to expand a bit on this: there is already in the kernel an input\n" - "> driver for the AT91 touchscreen which uses some ADC channels (that ha=\n" - "ve\n" + "> driver for the AT91 touchscreen which uses some ADC channels (that have\n" "> additional touchscreen-related features: on the G45, you have 8 ADCs\n" "> channels, 4 can optionally be used for touchscreen, the 4 other are\n" "> just raw ADCs).\n" - ">=20\n" - "> The ultimate goal is of course to make it possible to use both the II=\n" - "O\n" + "> \n" + "> The ultimate goal is of course to make it possible to use both the IIO\n" "> AT91 ADC driver and the AT91 touchscreen driver work simultaneously\n" - "> (with of course non-conflicting ADC channels usage). However, as show=\n" - "n\n" - "> by recent discussions on this list, it is not yet entirely clearly ho=\n" - "w\n" + "> (with of course non-conflicting ADC channels usage). However, as shown\n" + "> by recent discussions on this list, it is not yet entirely clearly how\n" "> this should be done:\n" - ">=20\n" - "> * Should we have some low-level ADC driver in arch/arm/mach-at91/ th=\n" - "at\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 th=\n" - "e\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 every=\n" - "thing\n" - "that looks like a driver out of the arch directories. An equivalent som=\n" - "ewhere\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" "> sysfs access /dev/input/...\n" "> to ADC channels access to touchscreen\n" "> || ||\n" @@ -89,39 +66,32 @@ "> | release and access |\n" "> | ADC channels |\n" "> +---------------------+\n" - ">=20\n" + "> \n" "> * Should IIO provide some internal kernel API (as you suggested some\n" "> time ago) so that kernel drivers can use ADC channels ?\n" - ">=20\n" - ">=20\n" + "> \n" + "> \n" "> +-------------------+\n" - "> | AT91 touchscreen | -> /dev/input/... access to touchsc=\n" - "reen\n" + "> | AT91 touchscreen | -> /dev/input/... access to touchscreen\n" "> +-------------------+\n" "> ||\n" "> \\/\n" "> +-------------------+\n" "> | AT91 IIO | -> sysfs access to ADC channels\n" "> +-------------------+\n" - ">=20\n" + "> \n" "> Regards,\n" - ">=20\n" + "> \n" "> Thomas\n" - "Agreed. This is currently up in the air. The current state of those II=\n" - "O\n" - "hooks is that they do pull only. Push based capture is tricky as for I=\n" - "IO\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 togeth=\n" - "er.\n" + "makes sense for input. I'm not yet clear how these two will play together.\n" "\n" - "If we sit something underneath the IIO and input drivers (or use the lo=\n" - "wer\n" - "portions of IIO to do this) then the intent would be to have a fully ge=\n" - "neric\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. For\n" - "example are the switches on the G45's adc (from datasheet) something th=\n" - "at\n" + "example are the switches on the G45's adc (from datasheet) something that\n" "all/many similar touch screen controllers have?\n" "I suppose we could support these in the chan_spec but only if it helps\n" "us to write a generic touch screen driver on top. I have no real\n" @@ -130,4 +100,4 @@ "\n" Jonathan -939c5f3df3e90e2cd7abe4ba9fa4e7206f771a0a3408c3f9a4eed18efd6c4be3 +385b2fcd253f685d55bbfbcdb9b235e274a99afccc752dc2966a40276d0bef14
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.