[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200102162134.GA13454@ravnborg.org>
Date: Thu, 2 Jan 2020 17:21:34 +0100
From: Sam Ravnborg <sam@...nborg.org>
To: Lee Jones <lee.jones@...aro.org>
Cc: Claudiu Beznea <claudiu.beznea@...rochip.com>,
boris.brezillon@...tlin.com, airlied@...ux.ie,
nicolas.ferre@...rochip.com, alexandre.belloni@...tlin.com,
peda@...ntia.se, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/6] fixes for atmel-hlcdc
Hi Lee.
> > > ("drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested")
> > >
> > > Claudiu Beznea (5):
> > > drm: atmel-hlcdc: use double rate for pixel clock only if supported
> > > drm: atmel-hlcdc: enable clock before configuring timing engine
> >
> > > mfd: atmel-hlcdc: add struct device member to struct
> > > atmel_hlcdc_regmap
> > > mfd: atmel-hlcdc: return in case of error
> >
> > Would it be OK to apply the to drm-misc-next, or shal they go in via
> > your mfd tree?
>
> How are they related to the other patches? Do they have build-time
> dependencies on any of the other patches, or vice versa?
No build time dependencies.
But from the description of "atmel-hlcdc: return in case of error":
"
For HLCDC timing engine configurations bit ATMEL_HLCDC_SIP of
ATMEL_HLCDC_SR needs to be polled before applying new config.
"
I get that changing timing for the HLCDC may fail if these
patches are not applied.
So it is only to have updated hlcdc support in drm-misc-next
for further testing.
Sam
Powered by blists - more mailing lists