* Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
[not found] ` <4CB523B7.8010209@gmail.com>
@ 2010-10-13 22:17 ` Grazvydas Ignotas
2010-10-14 2:14 ` Jason Wang
0 siblings, 1 reply; 6+ messages in thread
From: Grazvydas Ignotas @ 2010-10-13 22:17 UTC (permalink / raw)
To: Jason Wang; +Cc: Dmitry Torokhov, vapier, linux-input, linux-omap
On Wed, Oct 13, 2010 at 6:12 AM, Jason Wang <jason77.wang@gmail.com> wrote:
> Hi Dmitry,
>
> I have validated the new patch based off the 2.6.36-rc7 on
> the ti_omap3530evm, it works fine.
Working here on pandora too, applied on top of linux-next (did not
test suspend though).
Not caused by this patch, but the old problem where lower measurement
bits get lost is back - when I draw diagonal line it looks like
stairs. I think it's caused by OMAP SPI driver, CCing linux-omap.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
2010-10-13 22:17 ` [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions Grazvydas Ignotas
@ 2010-10-14 2:14 ` Jason Wang
2010-10-14 21:40 ` Grazvydas Ignotas
0 siblings, 1 reply; 6+ messages in thread
From: Jason Wang @ 2010-10-14 2:14 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Jason Wang, Dmitry Torokhov, vapier, linux-input, linux-omap,
grant.likely, roman.tereshonkov
Grazvydas Ignotas wrote:
> On Wed, Oct 13, 2010 at 6:12 AM, Jason Wang <jason77.wang@gmail.com> wrote:
>
>> Hi Dmitry,
>>
>> I have validated the new patch based off the 2.6.36-rc7 on
>> the ti_omap3530evm, it works fine.
>>
>
> Working here on pandora too, applied on top of linux-next (did not
> test suspend though).
>
> Not caused by this patch, but the old problem where lower measurement
> bits get lost is back - when I draw diagonal line it looks like
> stairs. I think it's caused by OMAP SPI driver, CCing linux-omap.
>
>
Yes, it is OMAP spi driver issues, I have met the same problem before,
please refer to:
http://www.spinics.net/lists/arm-kernel/msg91538.html
you can apply this patch and test again.
From 393f445ab899abaf5d60a55a54f242c430507047 Mon Sep 17 00:00:00 2001
From: Jason Wang <jason77.wang@gmail.com>
Date: Thu, 14 Oct 2010 10:08:07 +0800
Subject: [PATCH] spi/omap2_mcspi: disable channel after TX_ONLY transfer
in PIO mode
In TX_ONLY transfer, the SPI controller can also receive data
simultaneously and saves them in rx register. After the TX_ONLY
transfer, the rx register will hold random data received during
last tx transaction.
If the next transfer is RX_ONLY, this random data has
the possibility to affect this transfer like this:
If the spi controller is changed from TX_ONLY to RX_ONLY mode,
The random data makes the rx register full imediately and
triggers a dummy write (in SPI RX_ONLY transfer, we need a dummy
write to trigger the first transaction).
So the first data received in RX_ONLY transfer will be that
random data instead of something meaningfug.
We can avoid this by a Disable/reenable toggle of the spi channel
after the TX_ONLY transfer, since it purges the rx register.
Signed-off-by: Jason Wang <jason77.wang@gmail.com>
---
drivers/spi/omap2_mcspi.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index b3a94ca..43fab41 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -644,6 +644,12 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
spi_transfer *xfer)
} else if (mcspi_wait_for_reg_bit(chstat_reg,
OMAP2_MCSPI_CHSTAT_EOT) < 0)
dev_err(&spi->dev, "EOT timed out\n");
+
+ /* disable chan to purge rx datas received in TX_ONLY
transfer,
+ * otherwise these rx datas will affect the direct following
+ * RX_ONLY transfer.
+ */
+ omap2_mcspi_set_enable(spi, 0);
}
out:
omap2_mcspi_set_enable(spi, 1);
--
1.5.6.5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
2010-10-14 2:14 ` Jason Wang
@ 2010-10-14 21:40 ` Grazvydas Ignotas
2010-10-15 2:29 ` Jason Wang
0 siblings, 1 reply; 6+ messages in thread
From: Grazvydas Ignotas @ 2010-10-14 21:40 UTC (permalink / raw)
To: Jason Wang
Cc: Dmitry Torokhov, vapier, linux-input, linux-omap, grant.likely,
roman.tereshonkov
On Thu, Oct 14, 2010 at 5:14 AM, Jason Wang <jason77.wang@gmail.com> wrote:
> Grazvydas Ignotas wrote:
>> Working here on pandora too, applied on top of linux-next (did not
>> test suspend though).
>>
>> Not caused by this patch, but the old problem where lower measurement
>> bits get lost is back - when I draw diagonal line it looks like
>> stairs. I think it's caused by OMAP SPI driver, CCing linux-omap.
>>
>>
>
> Yes, it is OMAP spi driver issues, I have met the same problem before,
> please refer to:
> http://www.spinics.net/lists/arm-kernel/msg91538.html
>
> you can apply this patch and test again.
It solves my issue, thanks
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
BTW I have done similar patch almost 2 years ago for exactly the same problem:
http://marc.info/?l=linux-omap&m=122565580616920&w=2
but then problem went away after random kernel update (from what I
remember), and my patch was no longer needed.
> From 393f445ab899abaf5d60a55a54f242c430507047 Mon Sep 17 00:00:00 2001
> From: Jason Wang <jason77.wang@gmail.com>
> Date: Thu, 14 Oct 2010 10:08:07 +0800
> Subject: [PATCH] spi/omap2_mcspi: disable channel after TX_ONLY transfer in
> PIO mode
>
> In TX_ONLY transfer, the SPI controller can also receive data
> simultaneously and saves them in rx register. After the TX_ONLY
> transfer, the rx register will hold random data received during
> last tx transaction.
>
> If the next transfer is RX_ONLY, this random data has
> the possibility to affect this transfer like this:
>
> If the spi controller is changed from TX_ONLY to RX_ONLY mode,
> The random data makes the rx register full imediately and
> triggers a dummy write (in SPI RX_ONLY transfer, we need a dummy
> write to trigger the first transaction).
>
> So the first data received in RX_ONLY transfer will be that
> random data instead of something meaningfug.
>
> We can avoid this by a Disable/reenable toggle of the spi channel
> after the TX_ONLY transfer, since it purges the rx register.
>
> Signed-off-by: Jason Wang <jason77.wang@gmail.com>
> ---
> drivers/spi/omap2_mcspi.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index b3a94ca..43fab41 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -644,6 +644,12 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
> spi_transfer *xfer)
> } else if (mcspi_wait_for_reg_bit(chstat_reg,
> OMAP2_MCSPI_CHSTAT_EOT) < 0)
> dev_err(&spi->dev, "EOT timed out\n");
> +
> + /* disable chan to purge rx datas received in TX_ONLY
> transfer,
> + * otherwise these rx datas will affect the direct following
> + * RX_ONLY transfer.
> + */
> + omap2_mcspi_set_enable(spi, 0);
> }
> out:
> omap2_mcspi_set_enable(spi, 1);
> --
> 1.5.6.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
2010-10-14 21:40 ` Grazvydas Ignotas
@ 2010-10-15 2:29 ` Jason Wang
2010-10-18 23:19 ` Tony Lindgren
0 siblings, 1 reply; 6+ messages in thread
From: Jason Wang @ 2010-10-15 2:29 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Jason Wang, Dmitry Torokhov, vapier, linux-input, linux-omap,
grant.likely, roman.tereshonkov
Grazvydas Ignotas wrote:
> On Thu, Oct 14, 2010 at 5:14 AM, Jason Wang <jason77.wang@gmail.com> wrote:
>
>> Grazvydas Ignotas wrote:
>>
>>> Working here on pandora too, applied on top of linux-next (did not
>>> test suspend though).
>>>
>>> Not caused by this patch, but the old problem where lower measurement
>>> bits get lost is back - when I draw diagonal line it looks like
>>> stairs. I think it's caused by OMAP SPI driver, CCing linux-omap.
>>>
>>>
>>>
>> Yes, it is OMAP spi driver issues, I have met the same problem before,
>> please refer to:
>> http://www.spinics.net/lists/arm-kernel/msg91538.html
>>
>> you can apply this patch and test again.
>>
>
> It solves my issue, thanks
> Tested-by: Grazvydas Ignotas <notasas@gmail.com>
>
> BTW I have done similar patch almost 2 years ago for exactly the same problem:
> http://marc.info/?l=linux-omap&m=122565580616920&w=2
> but then problem went away after random kernel update (from what I
> remember), and my patch was no longer needed.
>
>
Really similar problem and similar solution, :-)
>
>> From 393f445ab899abaf5d60a55a54f242c430507047 Mon Sep 17 00:00:00 2001
>> From: Jason Wang <jason77.wang@gmail.com>
>> Date: Thu, 14 Oct 2010 10:08:07 +0800
>> Subject: [PATCH] spi/omap2_mcspi: disable channel after TX_ONLY transfer in
>> PIO mode
>>
>> In TX_ONLY transfer, the SPI controller can also receive data
>> simultaneously and saves them in rx register. After the TX_ONLY
>> transfer, the rx register will hold random data received during
>> last tx transaction.
>>
>> If the next transfer is RX_ONLY, this random data has
>> the possibility to affect this transfer like this:
>>
>> If the spi controller is changed from TX_ONLY to RX_ONLY mode,
>> The random data makes the rx register full imediately and
>> triggers a dummy write (in SPI RX_ONLY transfer, we need a dummy
>> write to trigger the first transaction).
>>
>> So the first data received in RX_ONLY transfer will be that
>> random data instead of something meaningfug.
>>
>> We can avoid this by a Disable/reenable toggle of the spi channel
>> after the TX_ONLY transfer, since it purges the rx register.
>>
>> Signed-off-by: Jason Wang <jason77.wang@gmail.com>
>> ---
>> drivers/spi/omap2_mcspi.c | 6 ++++++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
>> index b3a94ca..43fab41 100644
>> --- a/drivers/spi/omap2_mcspi.c
>> +++ b/drivers/spi/omap2_mcspi.c
>> @@ -644,6 +644,12 @@ omap2_mcspi_txrx_pio(struct spi_device *spi, struct
>> spi_transfer *xfer)
>> } else if (mcspi_wait_for_reg_bit(chstat_reg,
>> OMAP2_MCSPI_CHSTAT_EOT) < 0)
>> dev_err(&spi->dev, "EOT timed out\n");
>> +
>> + /* disable chan to purge rx datas received in TX_ONLY
>> transfer,
>> + * otherwise these rx datas will affect the direct following
>> + * RX_ONLY transfer.
>> + */
>> + omap2_mcspi_set_enable(spi, 0);
>> }
>> out:
>> omap2_mcspi_set_enable(spi, 1);
>> --
>> 1.5.6.5
>>
>>
>>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
2010-10-15 2:29 ` Jason Wang
@ 2010-10-18 23:19 ` Tony Lindgren
2010-10-19 1:25 ` Jason Wang
0 siblings, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2010-10-18 23:19 UTC (permalink / raw)
To: Jason Wang
Cc: Grazvydas Ignotas, Dmitry Torokhov, vapier, linux-input,
linux-omap, grant.likely, roman.tereshonkov
* Jason Wang <jason77.wang@gmail.com> [101014 19:17]:
> Grazvydas Ignotas wrote:
> >On Thu, Oct 14, 2010 at 5:14 AM, Jason Wang <jason77.wang@gmail.com> wrote:
> >>Grazvydas Ignotas wrote:
> >>>Working here on pandora too, applied on top of linux-next (did not
> >>>test suspend though).
> >>>
> >>>Not caused by this patch, but the old problem where lower measurement
> >>>bits get lost is back - when I draw diagonal line it looks like
> >>>stairs. I think it's caused by OMAP SPI driver, CCing linux-omap.
> >>>
> >>>
> >>Yes, it is OMAP spi driver issues, I have met the same problem before,
> >>please refer to:
> >>http://www.spinics.net/lists/arm-kernel/msg91538.html
> >>
> >>you can apply this patch and test again.
> >
> >It solves my issue, thanks
> >Tested-by: Grazvydas Ignotas <notasas@gmail.com>
> >
> >BTW I have done similar patch almost 2 years ago for exactly the same problem:
> >http://marc.info/?l=linux-omap&m=122565580616920&w=2
> >but then problem went away after random kernel update (from what I
> >remember), and my patch was no longer needed.
> >
> Really similar problem and similar solution, :-)
Let's get this fix into the mainline tree then. Jason, care to
refresh (it's wrapped at least) and then repost with the acks so
Grant can queue it up for the upcoming merge window?
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions
2010-10-18 23:19 ` Tony Lindgren
@ 2010-10-19 1:25 ` Jason Wang
0 siblings, 0 replies; 6+ messages in thread
From: Jason Wang @ 2010-10-19 1:25 UTC (permalink / raw)
To: Tony Lindgren
Cc: Jason Wang, Grazvydas Ignotas, Dmitry Torokhov, vapier,
linux-input, linux-omap, grant.likely, roman.tereshonkov
Tony Lindgren wrote:
> * Jason Wang <jason77.wang@gmail.com> [101014 19:17]:
>
>> Grazvydas Ignotas wrote:
>>
>>> On Thu, Oct 14, 2010 at 5:14 AM, Jason Wang <jason77.wang@gmail.com> wrote:
>>>
>>>> Grazvydas Ignotas wrote:
>>>>
>>>>> Working here on pandora too, applied on top of linux-next (did not
>>>>> test suspend though).
>>>>>
>>>>> Not caused by this patch, but the old problem where lower measurement
>>>>> bits get lost is back - when I draw diagonal line it looks like
>>>>> stairs. I think it's caused by OMAP SPI driver, CCing linux-omap.
>>>>>
>>>>>
>>>>>
>>>> Yes, it is OMAP spi driver issues, I have met the same problem before,
>>>> please refer to:
>>>> http://www.spinics.net/lists/arm-kernel/msg91538.html
>>>>
>>>> you can apply this patch and test again.
>>>>
>>> It solves my issue, thanks
>>> Tested-by: Grazvydas Ignotas <notasas@gmail.com>
>>>
>>> BTW I have done similar patch almost 2 years ago for exactly the same problem:
>>> http://marc.info/?l=linux-omap&m=122565580616920&w=2
>>> but then problem went away after random kernel update (from what I
>>> remember), and my patch was no longer needed.
>>>
>>>
>> Really similar problem and similar solution, :-)
>>
>
> Let's get this fix into the mainline tree then. Jason, care to
> refresh (it's wrapped at least) and then repost with the acks so
> Grant can queue it up for the upcoming merge window?
>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
>
OK, i will refresh it and re-post it to linux-spi and Grant.
Thanks,
Jason.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-10-19 1:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1284634286-8871-1-git-send-email-jason77.wang@gmail.com>
[not found] ` <1284634286-8871-4-git-send-email-jason77.wang@gmail.com>
[not found] ` <1284634286-8871-5-git-send-email-jason77.wang@gmail.com>
[not found] ` <201009162339.06395.dmitry.torokhov@gmail.com>
[not found] ` <4C9332CE.6040905@gmail.com>
[not found] ` <20100917160709.GC14186@core.coreip.homeip.net>
[not found] ` <4C9718E9.5040104@gmail.com>
[not found] ` <4CB4314C.7050308@gmail.com>
[not found] ` <20101012160055.GA6355@core.coreip.homeip.net>
[not found] ` <4CB523B7.8010209@gmail.com>
2010-10-13 22:17 ` [PATCH 4/4] Input: ads7846 - modificatons of _stop()/_disable() conditions Grazvydas Ignotas
2010-10-14 2:14 ` Jason Wang
2010-10-14 21:40 ` Grazvydas Ignotas
2010-10-15 2:29 ` Jason Wang
2010-10-18 23:19 ` Tony Lindgren
2010-10-19 1:25 ` Jason Wang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).