omap3evm LCD red-tint workaround

omap3evm LCD red-tint workaround

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

Hi,

While trying various kernels on the EVM to see what's causing the red  
tint (or rather, lack of blue) on the lcd I found a workaround to get  
correct colours with 2.6.27-omap1:

* boot 2.6.22.18 (from the BSP)
* do a warm reset (e.g pressing WARM_RST)
* boot 2.6.27-omap1

This makes me suspect that 2.6.27-omap1 isn't initializing something,  
does anyone have a clue what that bit might be?

regards,

Koen

PS: TS is still unusable with the 16x16 pixel resolution

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: omap3evm LCD red-tint workaround

[Grazvydas Ignotas]

> PS: TS is still unusable with the 16x16 pixel resolution
This is also the case for Pandora. The patch below fixes the problem,
but as I have no other boards to test this on, I haven't sent it.
See if it helps you.


>From 91f3af26bbf751b846e6265d86387e81be7c1364 Mon Sep 17 00:00:00 2001
From: Grazvydas Ignotas <notasas@gmail.com>
Date: Tue, 28 Oct 2008 22:01:42 +0200
Subject: [PATCH] OMAP3: fix McSPI transfers

Currently on OMAP3 if both write and read is set up for a transfer,
the first byte returned on read is corrupted. Work around this by
disabling channel between reads and writes, instead of transfers.
---
 drivers/spi/omap2_mcspi.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 454a271..4890b6c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -710,7 +710,6 @@ static void omap2_mcspi_work(struct work_struct *work)
 		spi = m->spi;
 		cs = spi->controller_state;
 
-		omap2_mcspi_set_enable(spi, 1);
 		list_for_each_entry(t, &m->transfers, transfer_list) {
 			if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
 				status = -EINVAL;
@@ -741,6 +740,8 @@ static void omap2_mcspi_work(struct work_struct *work)
 			if (t->len) {
 				unsigned	count;
 
+				omap2_mcspi_set_enable(spi, 1);
+
 				/* RX_ONLY mode needs dummy data in TX reg */
 				if (t->tx_buf == NULL)
 					__raw_writel(0, cs->base
@@ -752,6 +753,8 @@ static void omap2_mcspi_work(struct work_struct *work)
 					count = omap2_mcspi_txrx_pio(spi, t);
 				m->actual_length += count;
 
+				omap2_mcspi_set_enable(spi, 0);
+
 				if (count != t->len) {
 					status = -EIO;
 					break;
@@ -777,8 +780,6 @@ static void omap2_mcspi_work(struct work_struct *work)
 		if (cs_active)
 			omap2_mcspi_force_cs(spi, 0);
 
-		omap2_mcspi_set_enable(spi, 0);
-
 		m->status = status;
 		m->complete(m->context);
 
-- 
1.5.4.3

Re: omap3evm LCD red-tint workaround

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]


Op 2 nov 2008, om 20:56 heeft Grazvydas Ignotas het volgende geschreven:

>> PS: TS is still unusable with the 16x16 pixel resolution
> This is also the case for Pandora. The patch below fixes the problem,
> but as I have no other boards to test this on, I haven't sent it.
> See if it helps you.

This fixes the problem on the EVM as well, thanks!

regards,

Koen


>
>
>
> From 91f3af26bbf751b846e6265d86387e81be7c1364 Mon Sep 17 00:00:00 2001
> From: Grazvydas Ignotas <notasas@gmail.com>
> Date: Tue, 28 Oct 2008 22:01:42 +0200
> Subject: [PATCH] OMAP3: fix McSPI transfers
>
> Currently on OMAP3 if both write and read is set up for a transfer,
> the first byte returned on read is corrupted. Work around this by
> disabling channel between reads and writes, instead of transfers.
> ---
> drivers/spi/omap2_mcspi.c |    7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
> index 454a271..4890b6c 100644
> --- a/drivers/spi/omap2_mcspi.c
> +++ b/drivers/spi/omap2_mcspi.c
> @@ -710,7 +710,6 @@ static void omap2_mcspi_work(struct work_struct  
> *work)
> 		spi = m->spi;
> 		cs = spi->controller_state;
>
> -		omap2_mcspi_set_enable(spi, 1);
> 		list_for_each_entry(t, &m->transfers, transfer_list) {
> 			if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
> 				status = -EINVAL;
> @@ -741,6 +740,8 @@ static void omap2_mcspi_work(struct work_struct  
> *work)
> 			if (t->len) {
> 				unsigned	count;
>
> +				omap2_mcspi_set_enable(spi, 1);
> +
> 				/* RX_ONLY mode needs dummy data in TX reg */
> 				if (t->tx_buf == NULL)
> 					__raw_writel(0, cs->base
> @@ -752,6 +753,8 @@ static void omap2_mcspi_work(struct work_struct  
> *work)
> 					count = omap2_mcspi_txrx_pio(spi, t);
> 				m->actual_length += count;
>
> +				omap2_mcspi_set_enable(spi, 0);
> +
> 				if (count != t->len) {
> 					status = -EIO;
> 					break;
> @@ -777,8 +780,6 @@ static void omap2_mcspi_work(struct work_struct  
> *work)
> 		if (cs_active)
> 			omap2_mcspi_force_cs(spi, 0);
>
> -		omap2_mcspi_set_enable(spi, 0);
> -
> 		m->status = status;
> 		m->complete(m->context);
>
> -- 
> 1.5.4.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: omap3evm LCD red-tint workaround

[Tony Lindgren]

* Koen Kooi <k.kooi@student.utwente.nl> [081102 14:00]:
>
> Op 2 nov 2008, om 20:56 heeft Grazvydas Ignotas het volgende geschreven:
>
>>> PS: TS is still unusable with the 16x16 pixel resolution
>> This is also the case for Pandora. The patch below fixes the problem,
>> but as I have no other boards to test this on, I haven't sent it.
>> See if it helps you.
>
> This fixes the problem on the EVM as well, thanks!

Guys, please take this discussion to fbdev mailing list and cc
linux-omap list. I'm not going to push any more omap fbdev patches,
so please send the patches against mainline kernel to fbdev list.

Regards,

Tony


>
> regards,
>
> Koen
>
>
>>
>>
>>
>> From 91f3af26bbf751b846e6265d86387e81be7c1364 Mon Sep 17 00:00:00 2001
>> From: Grazvydas Ignotas <notasas@gmail.com>
>> Date: Tue, 28 Oct 2008 22:01:42 +0200
>> Subject: [PATCH] OMAP3: fix McSPI transfers
>>
>> Currently on OMAP3 if both write and read is set up for a transfer,
>> the first byte returned on read is corrupted. Work around this by
>> disabling channel between reads and writes, instead of transfers.
>> ---
>> drivers/spi/omap2_mcspi.c |    7 ++++---
>> 1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
>> index 454a271..4890b6c 100644
>> --- a/drivers/spi/omap2_mcspi.c
>> +++ b/drivers/spi/omap2_mcspi.c
>> @@ -710,7 +710,6 @@ static void omap2_mcspi_work(struct work_struct  
>> *work)
>> 		spi = m->spi;
>> 		cs = spi->controller_state;
>>
>> -		omap2_mcspi_set_enable(spi, 1);
>> 		list_for_each_entry(t, &m->transfers, transfer_list) {
>> 			if (t->tx_buf == NULL && t->rx_buf == NULL && t->len) {
>> 				status = -EINVAL;
>> @@ -741,6 +740,8 @@ static void omap2_mcspi_work(struct work_struct  
>> *work)
>> 			if (t->len) {
>> 				unsigned	count;
>>
>> +				omap2_mcspi_set_enable(spi, 1);
>> +
>> 				/* RX_ONLY mode needs dummy data in TX reg */
>> 				if (t->tx_buf == NULL)
>> 					__raw_writel(0, cs->base
>> @@ -752,6 +753,8 @@ static void omap2_mcspi_work(struct work_struct  
>> *work)
>> 					count = omap2_mcspi_txrx_pio(spi, t);
>> 				m->actual_length += count;
>>
>> +				omap2_mcspi_set_enable(spi, 0);
>> +
>> 				if (count != t->len) {
>> 					status = -EIO;
>> 					break;
>> @@ -777,8 +780,6 @@ static void omap2_mcspi_work(struct work_struct  
>> *work)
>> 		if (cs_active)
>> 			omap2_mcspi_force_cs(spi, 0);
>>
>> -		omap2_mcspi_set_enable(spi, 0);
>> -
>> 		m->status = status;
>> 		m->complete(m->context);
>>
>> -- 
>> 1.5.4.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>