Re: [PATCH 10/10] OMAP: DSS2: DSI Video mode support

[Archit Taneja <archit@ti.com>]

On Monday 05 September 2011 12:22 PM, Valkeinen, Tomi wrote:
> On Mon, 2011-09-05 at 11:22 +0530, Archit Taneja wrote:
>> On Friday 02 September 2011 01:25 PM, Valkeinen, Tomi wrote:
>>> On Fri, 2011-09-02 at 11:43 +0530, Archit Taneja wrote:
>>>>> Sending a null packet to start the DDR clk is rather OMAP specific
>>>>> internal thing, so I don't want to require the panel driver to need
>>>> to
>>>>> know that it must send a null packet to start the clock. So if the
>>>> ddr
>>>>> clk is not started automatically, I think we should have a function
>>>> to
>>>>> do that (dsi_start_ddr_clk or whatever), which will then send the
>>>> null
>>>>> packet (and perhaps return an error if DDR_CLK_ALWAYS_ON is not set,
>>>>> dunno...).
>>>>
>>>> Okay, If we can confirm that a panel asks for DDR_CLK_ALWAYS_ON
>>>> mainly
>>>> because it doesn't have its own fclk, then the dsi driver surely
>>>> needs
>>>> to start the DDR clock by sending a NULL packet.
>>>>
>>>> If this is to be done, one thing that has to be thought of is:
>>>>
>>>> - We need one of the requested VC's to be in HS mode for this. Do we
>>>> enable HS for a VC in the dsi driver itself? Currently, its the job
>>>> of
>>>> the panel driver to enable HSmode for a VC. Is this a clean approach?
>>>
>>> I have to say I don't have any idea what would be the best approach...
>>>
>>> What comes to my mind is that the DSI driver could automatically send
>>> the null packet, when:
>>>
>>> a) ddr_clk_always_on is set
>>> b) a channel is changed to HS and enabled (I guess it needs to be
>>> enabled also, does it?)
>>
>> This approach sounds fine. The only drawback is that we send a NULL
>> packet each time we enable a high speed channel. So if a panel is using
>> 2 VCs, and it wants high speed for both channels(for some reason), we
>> will be sending a NULL packet unnecessarily.
>
> True. I don't see that doing any harm, though, so I guess it's ok.
>
>> One observation was that the DDR clock has to be enabled only after the
>> bridge chip is reset. Enabling HS, and sending a NULL packet before
>> doing a hw reset of the bridge chip doesn't bring up the panel(that is a
>> bit peculiar). So we can't do this within omapdss_dsi_display_enable().
>
> Well that does sound strange. What happens there? Any errors? Commands
> still going through?

The commands go through from OMAP side, but we don't get BTA Acks. I get 
the following errors:

[    4.527069] omapdss DSI error: DSI error, irqstatus 100180
[    4.532836] DSI IRQ: 0x100180: PLL_LOCK PLL_UNLOCK TA_TIMEOUT

I am not sure why "PLL_UNLOCK" occurs, but TA_TIMEOUT would make sense 
if the bridge chip isn't working properly.

Archit

>
> Hmm, although... Well, I'm guessing, but if the HW reset for the chip
> causes the chip to pull down the DSI lanes, or something similar, it
> could cause errors in the OMAP side. But is that happening or something
> else?
>
>   Tomi
>
>