Hi,
On Thursday 05 April 2012 01:54 PM, Russell King - ARM Linux wrote:
On Fri, Feb 10, 2012 at 11:56:39AM +0530, Archit Taneja wrote:
On Friday 10 February 2012 04:04 AM, Russell King - ARM Linux wrote:
On Thu, Feb 09, 2012 at 12:22:42PM +0530, Archit Taneja wrote:
Hi,
On Sunday 05 February 2012 08:08 PM, Russell King - ARM Linux wrote:
Okay, so this requires backlight support, and TAAL selected, so that sorts
that error, but causes others:
taal display0: taal panel revision e3.83.7d
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
omapdss DSI error: DSI CIO error, cio irqstatus 200000
DSI CIO IRQ 0x200000: ERRCONTENTIONLP1_1
This happens when the flex cable connected to the display is faulty or
loose.
Well, I don't know - it works with ES1 and an old kernel just fine.
Okay, I'll look into this more.
Any news on this? I see no progress on this in mainline kernels:
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=112
Yet I can still boot the kernel with the originally provided kernel
and CPU and it all works fine.
Has anyone else tried to get the LCD panels working on the 4430SDP?
We figured out the culprit patch, reverting this prevents the issue:
commit 46f8c3c7e95c0d30d95911e7975ddc4f93b3e237
Author: Archit Taneja <archit@xxxxxx>
Date: Fri Oct 7 03:08:44 2011 -0600
ARM: OMAP: ctrl: Fix CONTROL_DSIPHY register fields
Fix the shift and mask macros for DSIx_PPID fields in
CONTROL_DSIPHY. The
OMAP4430 Public TRM vV has these fields mentioned correctly.
Signed-off-by: Archit Taneja <archit@xxxxxx>
Acked-by: Benoit Cousson <b-cousson@xxxxxx>
Acked-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx>
Signed-off-by: Paul Walmsley <paul@xxxxxxxxx>
This was added to be in sync with the register definitions in newer
OMAP4 TRMs. But it turns out that the newer TRMs might be actually
messing up the register fields in question.
The DSIx_PPID register fields are responsible for the pull up/down of
the DSI lanes. Some SDP versions may already have enough pull up to make
the panels work, and others might not. We get the contention errors on
these SDP boards as we don't configure the lanes as pull up.
We were trying to verify from the TRM maintainers if this was a TRM
mistake, if so, reverting the patch would be the right way to go. We
haven't got a response, so I'll probe the voltage of DSI lanes on a
board which gives these errors so that we have enough proof.
Archit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html