drm/msm/dsi: hs_zero timing

2:10 AM To: Archit Taneja Cc: dri-devel at lists.freedesktop.org Subject: Re: drm/msm/dsi: hs_zero timing On Aug 27, 2015 10:56 PM, "Archit Taneja" mailto:architt at codeaurora.org> > wrote: > > There are certain modes (generally for HDMI/DVI) where the refresh rate >

drm/msm/dsi: hs_zero timing

On Sep 1, 2015 08:59, "Hai Li" wrote: > > Based on the discussion with our hw team, changing the LNn_CFG4 to all 0 is the solution for this issue. > > I will prepare a change to this. > That's great! I've run all my panels with the adjust zeroed and everything just works. Thanks for

drm/msm/dsi: hs_zero timing

> > > On 08/27/2015 07:12 AM, Werner Johansson wrote: >> On Aug 26, 2015 11:31 AM, "Rob Clark" > > wrote: >> > >> > I'm not completely sure.. I did observe that we calculated slightly >> > different settings w/ the auo novatek panel on z3, compared to what >> >

drm/msm/dsi: hs_zero timing

On 08/27/2015 07:12 AM, Werner Johansson wrote: > On Aug 26, 2015 11:31 AM, "Rob Clark" > wrote: > > > > I'm not completely sure.. I did observe that we calculated slightly > > different settings w/ the auo novatek panel on z3, compared to what > > downstream

drm/msm/dsi: hs_zero timing

On Aug 27, 2015 10:56 PM, "Archit Taneja" wrote: > > There are certain modes (generally for HDMI/DVI) where the refresh rate > isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The > above calculation may not work well with such modes. > [...] > We have platforms where the DSI

drm/msm/dsi: hs_zero timing

On Aug 26, 2015 11:31 AM, "Rob Clark" wrote: > > I'm not completely sure.. I did observe that we calculated slightly > different settings w/ the auo novatek panel on z3, compared to what > downstream had hard-coded in dts (which presumably came from > magic-spreadsheet), because (I think) of

drm/msm/dsi: hs_zero timing

On Wed, Aug 26, 2015 at 2:22 PM, Werner Johansson wrote: > > On Aug 26, 2015 10:46, "Rob Clark" wrote: >> >> btw, w/ some of these clk rounding issues, I suspect we need 'struct >> drm_display_mode' to be able to represent mode clock with greater >> accuracy than Khz.. > > Interesting point!

drm/msm/dsi: hs_zero timing

; werner.johansson at sonymobile.com; dri-devel at lists.freedesktop.org Subject: RE: drm/msm/dsi: hs_zero timing On Aug 26, 2015 08:34, "Hai Li" mailto:hali at codeaurora.org> > wrote: > > Hi Werner, > > Thanks for sharing this. The DPHY timings in downstream

drm/msm/dsi: hs_zero timing

On Wed, Aug 26, 2015 at 1:39 PM, Werner Johansson wrote: > > On Aug 26, 2015 08:34, "Hai Li" wrote: >> >> Hi Werner, >> >> Thanks for sharing this. The DPHY timings in downstream dtsi are exactly >> the same as the excel calculation, but slightly different from the output of >> drm code as you

drm/msm/dsi: hs_zero timing

...@gmail.com] Sent: Monday, August 24, 2015 9:24 PM To: Hai Li Cc: Rob Clark; Johansson, Werner; dri-devel at lists.freedesktop.org Subject: Re: drm/msm/dsi: hs_zero timing On Mon, Aug 24, 2015 at 7:32 AM, Hai Li wrote: > Hi Werner, > > Yes, the register is to adjust hs_zero. > Cou

drm/msm/dsi: hs_zero timing

On Aug 26, 2015 10:46, "Rob Clark" wrote: > > btw, w/ some of these clk rounding issues, I suspect we need 'struct > drm_display_mode' to be able to represent mode clock with greater > accuracy than Khz.. Interesting point! However, in this case I had to adjust the clock hundreds of kHz to make

drm/msm/dsi: hs_zero timing

On Aug 26, 2015 10:49, "Hai Li" wrote: > > Thanks Werner to test it out. I will focus on the dphy timing calculation then. Happy to help, we want this to work as much as you do! > It’s better to avoid discussing the excel formula publicly. J That's what I figured! :) /wj -- next

drm/msm/dsi: hs_zero timing

On Aug 26, 2015 08:34, "Hai Li" wrote: > > Hi Werner, > > Thanks for sharing this. The DPHY timings in downstream dtsi are exactly the same as the excel calculation, but slightly different from the output of drm code as you posted. (e.g hs_zero is 116 vs 118) > I think it is caused by some

drm/msm/dsi: hs_zero timing

On Mon, Aug 24, 2015 at 7:32 AM, Hai Li wrote: > Hi Werner, > > Yes, the register is to adjust hs_zero. > Could you share the panel's video timing and dphy timings (or the panel DT), > used by downstream driver? > > The dphy timing calculations in the phy driver are from the excel sheet as >

drm/msm/dsi: hs_zero timing

code making the difference. Thanks, Hai -Original Message- From: Rob Clark [mailto:robdcl...@gmail.com] Sent: Saturday, August 22, 2015 9:25 AM To: Johansson, Werner Cc: Hai Li; dri-devel at lists.freedesktop.org Subject: Re: drm/msm/dsi: hs_zero timing On Fri, Aug 21, 2015 at 4:38 PM

drm/msm/dsi: hs_zero timing

On Sat, Aug 22, 2015 at 6:25 AM, Rob Clark wrote: > > fwiw, if the values are related to the physical cabling/wiring, rather > than the panel timing, we should probably get them from DT.. > > if a combination of the timing and the wiring, that gets a bit more > complicated > > (I am not actually

drm/msm/dsi: hs_zero timing

On Fri, Aug 21, 2015 at 4:38 PM, Johansson, Werner wrote: >> From: Hai Li [mailto:hali at codeaurora.org] >> Sent: den 21 augusti 2015 12:56 >> >> When I made DSI changes, I tried to limit the information in DT (like >> our downstream driver), until there is a case driver really cannot >> figure

drm/msm/dsi: hs_zero timing

> From: Hai Li [mailto:hali at codeaurora.org] > Sent: den 21 augusti 2015 12:56 > > When I made DSI changes, I tried to limit the information in DT (like > our downstream driver), until there is a case driver really cannot > figure it out by the existing information. > I think this is the

drm/msm/dsi: hs_zero timing

Hi, In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly

drm/msm/dsi: hs_zero timing

: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Johansson, Werner Sent: Friday, August 21, 2015 2:27 PM To: dri-devel at lists.freedesktop.org Subject: drm/msm/dsi: hs_zero timing Hi, In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number&quo

drm/msm/dsi: hs_zero timing

Hi, In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly

drm/msm/dsi: hs_zero timing

Hi, In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly