Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-17 Thread Daniel Vetter
On Mon, Jul 17, 2017 at 04:20:23PM -0700, John Stultz wrote: > On Tue, Jul 11, 2017 at 9:27 AM, Daniel Vetter wrote: > > On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote: > >> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: > >>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz > >>> wrote

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-17 Thread John Stultz
On Tue, Jul 11, 2017 at 9:27 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote: >> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: >>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: >> > be even better if you could calculate whether the mode is valid,

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-11 Thread Daniel Vetter
On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote: > On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: >> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: > > be even better if you could calculate whether the mode is valid, but I > > didn't > > spend enough time to figure ou

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-11 Thread John Stultz
On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: > be even better if you could calculate whether the mode is valid, but I > didn't > spend enough time to figure out if this is possible. Theoretically that might b

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-11 Thread Daniel Vetter
On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: >>> > be even better if you could calculate whether the mode is valid, but I >>> > didn't >>> > spend enough time to figure out if this is possible. >>> >>> Theoretically that might be possible, checking if the requested freq >>> matches the cal

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-11 Thread John Stultz
On Tue, Jul 11, 2017 at 12:56 AM, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote: >> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: >> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: >> >> Currently the hikey dsi logic cannot generate accurate

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-11 Thread Daniel Vetter
On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote: > On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: > > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: > >> Currently the hikey dsi logic cannot generate accurate byte > >> clocks values for all pixel clock values. Thus if

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-10 Thread John Stultz
On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: >> Currently the hikey dsi logic cannot generate accurate byte >> clocks values for all pixel clock values. Thus if a mode clock >> is selected that cannot match the calculated byte clo

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-10 Thread Sean Paul
On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: > Currently the hikey dsi logic cannot generate accurate byte > clocks values for all pixel clock values. Thus if a mode clock > is selected that cannot match the calculated byte clock, the > device will boot with a blank screen. > > Thi

[RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

2017-07-10 Thread John Stultz
Currently the hikey dsi logic cannot generate accurate byte clocks values for all pixel clock values. Thus if a mode clock is selected that cannot match the calculated byte clock, the device will boot with a blank screen. This patch uses the new mode_valid callback (many thanks to Jose Abreu for u