Re: [RESEND][PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

On Fri, Aug 18, 2017 at 8:28 AM, Sean Paul wrote: > On Thu, Aug 17, 2017 at 12:00:04PM -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: [RESEND][PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

On Thu, Aug 17, 2017 at 12:00:04PM -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

[RESEND][PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

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

[PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

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

[RFC][PATCH v4] drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate

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