On 03/06/13 11:57, NeilBrown wrote:
> On Mon, 3 Jun 2013 10:24:18 +0300 Tomi Valkeinen <tomi.valkeinen@xxxxxx>
>> I'll try blanking on my omap3 board with 3.10-rc (I think I haven't
>> tried it). Did you check if the DSS hardware lost context (visible from
>> the PM counters)?
>
> I turned on some debugging statements and the mentioned lost-context counters
> in a way that suggested they were being handled correctly (save and restore
> reported appropriately matching numbers).
I was mostly interested in whether the DSS goes into OFF mode when you
blank the panel or not. If it does, and it doesn't work after unblank,
it could suggest that somehow the DSS registers are not restored correctly.
I did some testing on my Overo board (3430), and it works fine if I
blank the display, or suspend the device. However, I think I'm missing
something here, as the DSS domain just stays in ON-state, even if disabled.
>>> A suspend/resume cycle at this point might bring it back, but it is often
>>> shimmery (low vsync?) and once it had inverse colours.
>>>
>>> I had noticed that the panel which normally gets a 22153 kHz pixel clock was
>>> only getting a 21600 kHz clock. This turned out to be due to the fact
>>> that dpi_calc_dispc_cb rejects odd divisors, and it used to use a divisor of
>>> '3'.
>>
>> Normally panels should not be that picky. In my experience the pixel
>> clock has to be very far from the nominal, until the panel start to fail.
>
> As I said, it works fine at first boot. So the panel obviously copes. But
> something weird happens at blank/unblack which is affect by the pixel clock
> setting in a non-obvious way.
Right. You don't have the option to measure the pixel clock with an
oscilloscope?
>> However, the code in dpi_calc_dispc_cb only rejects odd divisors, if the
>> pixel clock is greater than 100MHz. So I don't understand how you're
>> seeing it affect here. Are you sure the pclk is ~22MHz?
>
> If think you got some maths wrong.
> dpi_calc_dispc_cb() contains:
> if (ctx->pck_min >= 1000000) {
>
> which isn't 100MHz, unless the units are 0.1KHz, which seems unlikely.
> It looks to me like the units for pck_min is Hz, so the cut off is 1MHz.
> So that should be:
> if (ctx->pck_min >= 100000000) {
> ??
Indeed, it's plain wrong. The original patch introducing that limit is
b7f1fe541b01f6edaff0a5dd48027de6ac711ab6 , from which I copied the limit
to the new clock calculation. Both are from me, both are wrong. Sigh.
Thanks for pointing this out, I'll send a fix.
But, as I said earlier, I doubt that it affects your case. Especially if
the panel works after boot.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
