Re: [PATCH v3 02/11] drm/tilcdc: implement palette loading for rev1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 24/11/16 12:03, Jyri Sarha wrote:
> On 11/24/16 11:43, Tomi Valkeinen wrote:
>> What is the difference? If mode changes, you need to disable and enable
>> the crtc, right? What other cases there are to enable the display? After
>> blank? Then the display has been off, and I presume palette has to be
>> loaded.
> 
> At the moment the palette or register values do not appear to vanish
> ever. But that is probably due to PM not doing much to optimize the LCDC
> power consumption.

If runtime PM for the device goes to suspend, you have to presume the IP
has lost all context. That may not always happen, but that's what the
driver has to presume, unless there's a way for the driver to verify
whether the context has been lost or not.

> Anyway, if simple enable is enough to turn on the display - all video
> timings, frame buffer dma addresses etc. are already in the registers -
> then I think it is safe to assume that the palette is still in there too.

As long as the driver makes sure the device doesn't go to suspend (by
having called pm_runtime_get).

> Then it is a different issue, that I should probably put the same
> functionality into PM runtime_suspend() and runtime_resume() callbacks,
> that is currently in suspend() and resume() callbacks, to be ready if PM
> ever does anything more for LCDC that it does today. I could of course
> add a test if the registers are still intact before doing a restore.

You can do things in resume callback, but I think quite often it's
simplest to just do those things when enabling the display. The device
never goes to suspend if the display is enabled. And if you disable the
display, the device should go to suspend, so usually enable is called
after the device has been in suspend.

So, I haven't looked at the tilcdc code in detail in this regard, but my
guess is that runtime PM resume could be used to set hardcoded things to
registers, stuff that you always know how they are set. Everything else
can be just programmed at enable.

Looking at the registers to find out if they're intact is fine, but it's
just an optimization.

 Tomi

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux