Re: Support for early wakeup in DRM

[jsanka@codeaurora.org]

On 2020-02-21 09:20, Daniel Vetter wrote:
> On Thu, Feb 20, 2020 at 01:24:00PM -0800, jsanka@codeaurora.org wrote:
>> On 2020-02-20 12:14, Daniel Vetter wrote:
>> > On Thu, Feb 20, 2020 at 10:45:57AM -0800, jsanka@codeaurora.org wrote:
>> > > Hello All,
>> > >
>> > > I am seeking recommendations for DRM compatible methods of updating
>> > > the
>> > HW
>> > > other than frame commit path. When exiting idle/runtime_suspend, the
>> > driver
>> > > votes for a bunch of resources including power/clk/bandwidth as a
> part
>> > of
>> > > first commit handling. This usually adds a few millisecond delay
>> > > before
>> > > processing the frame. The requirement is to find possible ways to
>> > > reduce
>> > > this delay by providing an early intimation to the framework to
>> > "prepare"
>> > > the HW by voting for the resources and keep the HW ready to process
> an
>> > > imminent frame commit. Especially in performance oriented Automotive
>> > world,
>> > > these delays are very time critical and we are working on ways to
>> > mitigate
>> > > them.
>> > >
>> > >
>> > >
>> > > DRM framework converges all the parameters affecting the HW in terms
>> > > of
>> > DRM
>> > > properties in a single COMMIT call. To address the above issue, we
>> > > need
>> > a
>> > > parallel channel which should allow the framework to make necessary
>> > changes
>> > > to the HW without violating the master access privileges.
>> > >
>> > >
>> > >
>> > > Before resorting to custom downstream ways, I want to check with the
>> > > community for folks who might have encountered and resolved such
>> > > issues.
>> >
>> > Just enable the display, which will grab all the clocks and
> everything?
>> > Once the display is on a commit should be possible on the next frame,
> at
>> > least for well-working drivers.
>> > -Daniel
>> >
>> I believe even to turn on the display, DRM will need an explicit 
>> commit
>> (probably without any planes/pixel buffers). For cases like smart
> panels,
>> where we can keep the panel on(panel internal RAM refresh) and power
>> collapse the display HW, resuming back with an explicit commit will 
>> push
> a
>> black (or default color programmed in the HW) frame causing a glitch.
> 
> Uh, you might want to look into the self-refresh helpers, which do this
> without black frames and stuff.
> 

I believe you are referring to Sean's PSR changes: 
https://patchwork.freedesktop.org/series/57366/
Will take a look.

Thanks and Regards,
Jeykumar S.

> But yeah if there's really a gap here (and not just you folks 
> creatively
> abusing atomic kms in ways that it was not meant to be used) then we 
> can
> add a property that forbids power optimization and guarantee that you 
> can
> do the next screen update immediately. And then we can merge that with 
> all
> the usual requirements (driver implementation that works, open source
> userspace, igt testcase, the full deal).
> 
> But it still feels like you're trying to do something automatically 
> that's
> not meant to work like this.
> 
> Cheers, Daniel
> 
>> 
>> Thanks and Regards,
>> Jeykumar S.
>> > >
>> > >
>> > >
>> > > Thanks and Regards,
>> > >
>> > > Jeykumar S
>> > >
>> > > Qualcomm Inc.
>> > >
>> > >
>> > >
>> >
>> > > _______________________________________________
>> > > dri-devel mailing list
>> > > dri-devel@lists.freedesktop.org
>> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel