| Message ID | 20190401171724.215780-1-dianders@chromium.org |
|---|---|
| Headers | show |
| Series | drm/panel: simple: Add mode support to devicetree | expand |
Hi, On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote: > > Let's document the display timings that most veyron chromebooks (like > jaq, jerry, mighty, speedy) have been using out in the field. This > uses the standard blankings but a slightly slower clock rate, thus > getting a refresh rate 58.3 Hz. > > NOTE: this won't really do anything except cause DRM to properly > report the refresh rate since vop_crtc_mode_fixup() was rounding the > pixel clock to 74.25 MHz anyway. Apparently the adjusted rate isn't > exposed to userspace so it's important that the rate we're trying to > achieve is mostly right. I just thought it would be worth mentioning that I have picked & tested a close to 60Hz mode on two veyron speedys of mine, but thought it too much effort to try and upstream, especially as it was done as a change to the actual panel info: https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae The difference would be in this format just setting hfront-porch = 87 and vback-porch = 14. Anyways the point is: I support moving this mode info into the dts, and I'd like to know how if at all should i go about getting a 60Hz(ish) mode upstreamed?
Hi, On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote: > > Hi, > > On Mon, Apr 1, 2019 at 5:18 PM Douglas Anderson <dianders@chromium.org> wrote: > > > > Let's document the display timings that most veyron chromebooks (like > > jaq, jerry, mighty, speedy) have been using out in the field. This > > uses the standard blankings but a slightly slower clock rate, thus > > getting a refresh rate 58.3 Hz. > > > > NOTE: this won't really do anything except cause DRM to properly > > report the refresh rate since vop_crtc_mode_fixup() was rounding the > > pixel clock to 74.25 MHz anyway. Apparently the adjusted rate isn't > > exposed to userspace so it's important that the rate we're trying to > > achieve is mostly right. > > I just thought it would be worth mentioning that I have picked & > tested a close to 60Hz mode on two veyron speedys of mine, but thought > it too much effort to try and upstream, especially as it was done as a > change to the actual panel info: > https://github.com/urjaman/linux/commit/23d46278911e18df138b7adde1bebc23f606baae > > The difference would be in this format just setting hfront-porch = 87 > and vback-porch = 14. > Anyways the point is: I support moving this mode info into the dts, > and I'd like to know how if at all should i go about getting a > 60Hz(ish) mode upstreamed? I'm a bit torn here. I like the idea of actually getting 60 Hz and you also increase the vblank time by a little bit (which means that if anyone ever gets DDRFreq upstream it will work better). ...but I'm also slightly nervous changing something like this without a really good motivation. As you said in your commit message the pixels clocks claimed by the spec don't actually all work and thus, to some extent, we can only rely on trial-and-error here. While your new mode works well on your device (and you wisely gave it a bit of margin), it is _possible_ that there could be devices out there where it doesn't work (especially across various temperature extremes). All devices were tested in the factory with the old timings and presumably have been running fine for years like that... I will certainly admit that it's unlikely devices would be affected, but at the same time I'd want to know how much of a difference going from 58.3 Hz to 60 Hz made for you. Could you actually notice any visible difference, or was it just nice to be at 60 Hz? -Doug
Hi, On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote: > > > > Hi, <snip> > > > > The difference would be in this format just setting hfront-porch = 87 > > and vback-porch = 14. > > Anyways the point is: I support moving this mode info into the dts, > > and I'd like to know how if at all should i go about getting a > > 60Hz(ish) mode upstreamed? > > I'm a bit torn here. I like the idea of actually getting 60 Hz and > you also increase the vblank time by a little bit (which means that if > anyone ever gets DDRFreq upstream it will work better). ...but I'm > also slightly nervous changing something like this without a really > good motivation. As you said in your commit message the pixels clocks > claimed by the spec don't actually all work and thus, to some extent, > we can only rely on trial-and-error here. While your new mode works > well on your device (and you wisely gave it a bit of margin), it is > _possible_ that there could be devices out there where it doesn't work > (especially across various temperature extremes). All devices were > tested in the factory with the old timings and presumably have been > running fine for years like that... Re: the trial and error: it might be the case that the panels actually work at 1506 vtotal if you also adjust the sync length and/or back porch "accordingly", whatever that accordingly would be for this panel since the datasheet doesnt tell. I missed this point when i was doing my testing and just adjusted the variables with the most "adjustability" (bigger starting value) to them. > I will certainly admit that it's unlikely devices would be affected, > but at the same time I'd want to know how much of a difference going > from 58.3 Hz to 60 Hz made for you. Could you actually notice any > visible difference, or was it just nice to be at 60 Hz? Honestly I was just doing this because i really liked the idea of actually making it 60Hz and my eyes arent that good at noticing high-fps things - i think the one case where it might be visible to a keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..) frames a second if running at 58.3 Hz. But currently the C201 isnt doing a lot of that given i dont think i/we have a good software setup for it. That could be changing in the future with panfrost and the VPU hardware decoder support, etc. Anyways I'm thinking it would be prudent to first get this framework of device-tree modes in and then maybe adjust the mode later. Testing the 60Hz mode is simple enough: xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802 -HSync -VSync xrandr --addmode eDP-1 1366x768p60 xrandr --output eDP-1 --mode 1366x768p60 (The mode name can be anything...) So meanwhile I would appreciate it if we could get some test reports of the mode with other veyron chromebooks that have this panel :)
Hi, On Mon, Apr 8, 2019 at 9:26 AM Urja Rannikko <urjaman@gmail.com> wrote: > > Hi, > > On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko <urjaman@gmail.com> wrote: > > > > > > Hi, > <snip> > > > > > > The difference would be in this format just setting hfront-porch = 87 > > > and vback-porch = 14. > > > Anyways the point is: I support moving this mode info into the dts, > > > and I'd like to know how if at all should i go about getting a > > > 60Hz(ish) mode upstreamed? > > > > I'm a bit torn here. I like the idea of actually getting 60 Hz and > > you also increase the vblank time by a little bit (which means that if > > anyone ever gets DDRFreq upstream it will work better). ...but I'm > > also slightly nervous changing something like this without a really > > good motivation. As you said in your commit message the pixels clocks > > claimed by the spec don't actually all work and thus, to some extent, > > we can only rely on trial-and-error here. While your new mode works > > well on your device (and you wisely gave it a bit of margin), it is > > _possible_ that there could be devices out there where it doesn't work > > (especially across various temperature extremes). All devices were > > tested in the factory with the old timings and presumably have been > > running fine for years like that... > Re: the trial and error: it might be the case that the panels actually > work at 1506 vtotal if you also adjust the sync length and/or back > porch "accordingly", whatever that accordingly would be for this panel > since the datasheet doesnt tell. I missed this point when i was doing > my testing and just adjusted the variables with the most > "adjustability" (bigger starting value) to them. Fair enough. I guess I just have my gut instincts that say that this will break some device somewhere, but it's certainly possible that's wrong. > > I will certainly admit that it's unlikely devices would be affected, > > but at the same time I'd want to know how much of a difference going > > from 58.3 Hz to 60 Hz made for you. Could you actually notice any > > visible difference, or was it just nice to be at 60 Hz? > Honestly I was just doing this because i really liked the idea of > actually making it 60Hz and my eyes arent that good at noticing > high-fps things - i think the one case where it might be visible to a > keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..) > frames a second if running at 58.3 Hz. But currently the C201 isnt > doing a lot of that given i dont think i/we have a good software setup > for it. That could be changing in the future with panfrost and the VPU > hardware decoder support, etc. Yeah, I'd definitely wonder how easy this is to notice. Since I haven't ever heard of anyone who thought that the current 58.3 Hz was causing problems that they could actually notice it makes me hesitant to change it. > Anyways I'm thinking it would be prudent to first get this framework > of device-tree modes in and then maybe adjust the mode later. If you're OK with it, let's aim to land things with the current 58.3 and then we can do think about the 60 Hz mode. ...I'm probably sounding super paranoid here since (presumably) anyone who is running upstream Linux on their Chromebook is more than capable of bisecting problems like this if it causes problems, but I guess I'm worried that this could eventually make its way into a Chrome OS tree (either through a kernel uprev or simple cherry-picks) and affect people. > Testing the 60Hz mode is simple enough: > xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802 > -HSync -VSync > xrandr --addmode eDP-1 1366x768p60 > xrandr --output eDP-1 --mode 1366x768p60 > > (The mode name can be anything...) > So meanwhile I would appreciate it if we could get some test reports > of the mode with other veyron chromebooks that have this panel :) I still haven't done this and I'm not in front of my Chromebook now. I'll try to give it a try soon. The kinds of problems I'd expect (if there are any) would be flickers that happen _very_ rarely though, but I can at least do some basic testing. One other note to justify my paranoia: on a past Chromebook we certainly had crazy flickering problems. On one device one day you'd get two flickers and then see nothing for the next two weeks. ...some devices would see at least a flicker a day and some would see no flickers ever. Obviously it's unlikely that would happen here, but such past experience just makes me paranoid. ;-) -Doug
Am Montag, 1. April 2019, 19:17:17 CEST schrieb Douglas Anderson: > I'm reviving Sean Paul's old patchset to get mode support in device > tree. The cover letter for his v3 is at: > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html > > No code is different between v4 and v5, just commit messages and text > in the bindings. > > I've pulled together the patches that didn't land in v3, addressed > outstanding feedback, and reposted. Atop them I've added patches for > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and > rk3288-veryon-minnie. > > Please let me know how they look. > > In general I have added people to the whole series who I think would > like the whole series and then let get_maintainer pick extra people it > thinks are relevant to each individual patch. If I see you respond to > any of the patches in the series, though, I'll add you to the whole > series Cc list next time. sadly it looks like the panel-simple parts haven't made it into drm-misc yet and the conversation on patch 1/7 seems to have stalled after Doug's replies. Thierry, do you have an opinion on these? Thanks Heiko > Changes in v5: > - Removed bit about OS may ignore (Rob/Ezequiel) > - Added Heiko's Tested-by > - It's not just jerry, it's most rk3288 Chromebooks (Heiko) > > Changes in v4: > - Simplify desc. for when override should be used (Thierry/Laurent) > - Removed Rob H review since it's been a year and wording changed > - Don't add mode from timing if override was specified (Thierry) > - Add warning if timing and fixed mode was specified (Thierry) > - Don't add fixed mode if timing was specified (Thierry) > - Refactor/rename a bit to avoid extra indentation from "if" tests > - i should be unsigned (Thierry) > - Add annoying WARN_ONs for some cases (Thierry) > - Simplify 'No display_timing found' handling (Thierry) > - Rename to panel_simple_parse_override_mode() (Thierry) > - Rebase to top of Heiko's tree > - Converted changelog to after-the-cut for non-DRM change. > - display_timing for Innolux n116bge new for v4. > - display_timing for AUO b101ean01 new for v4. > - rk3288-veyron-jerry patch new for v4. > - rk3288-veyron-minnie patch new for v4. > > Changes in v3: > - Go back to using the timing subnode directly, but rename to > panel-timing (Rob) > - No longer parse display-timings subnode, use panel-timing (Rob) > - Unwrap the timing from display-timings and rename panel-timing (Rob) > > Changes in v2: > - Split out the binding into a new patch (Rob) > - display-timings is a new section (Rob) > - Use the full display-timings subnode instead of picking the timing > out (Rob/Thierry) > - Parse the full display-timings node (using the native-mode) (Rob) > - Wrap the timing in display-timings node to match binding (Rob/Thierry) > > Douglas Anderson (4): > drm/panel: simple: Use display_timing for Innolux n116bge > drm/panel: simple: Use display_timing for AUO b101ean01 > ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings > ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings > > Sean Paul (3): > dt-bindings: Add panel-timing subnode to simple-panel > drm/panel: simple: Add ability to override typical timing > arm64: dts: rockchip: Specify override mode for kevin panel > > .../bindings/display/panel/simple-panel.txt | 22 +++ > .../boot/dts/rk3288-veyron-chromebook.dtsi | 14 ++ > arch/arm/boot/dts/rk3288-veyron-minnie.dts | 14 ++ > .../boot/dts/rockchip/rk3399-gru-kevin.dts | 14 ++ > drivers/gpu/drm/panel/panel-simple.c | 171 ++++++++++++++---- > 5 files changed, 203 insertions(+), 32 deletions(-) > >
Hi Douglas. On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote: > I'm reviving Sean Paul's old patchset to get mode support in device > tree. The cover letter for his v3 is at: > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html > > No code is different between v4 and v5, just commit messages and text > in the bindings. > > I've pulled together the patches that didn't land in v3, addressed > outstanding feedback, and reposted. Atop them I've added patches for > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and > rk3288-veryon-minnie. > > Please let me know how they look. > > In general I have added people to the whole series who I think would > like the whole series and then let get_maintainer pick extra people it > thinks are relevant to each individual patch. If I see you respond to > any of the patches in the series, though, I'll add you to the whole > series Cc list next time. > > Changes in v5: > - Removed bit about OS may ignore (Rob/Ezequiel) > - Added Heiko's Tested-by > - It's not just jerry, it's most rk3288 Chromebooks (Heiko) What are the plans to move forward with this? Or did you drop the whole idea again? Sam
Hi, On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote: > > Hi Douglas. > > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote: > > I'm reviving Sean Paul's old patchset to get mode support in device > > tree. The cover letter for his v3 is at: > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html > > > > No code is different between v4 and v5, just commit messages and text > > in the bindings. > > > > I've pulled together the patches that didn't land in v3, addressed > > outstanding feedback, and reposted. Atop them I've added patches for > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and > > rk3288-veryon-minnie. > > > > Please let me know how they look. > > > > In general I have added people to the whole series who I think would > > like the whole series and then let get_maintainer pick extra people it > > thinks are relevant to each individual patch. If I see you respond to > > any of the patches in the series, though, I'll add you to the whole > > series Cc list next time. > > > > Changes in v5: > > - Removed bit about OS may ignore (Rob/Ezequiel) > > - Added Heiko's Tested-by > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko) > > What are the plans to move forward with this? > Or did you drop the whole idea again? At the moment I'm blocked on Thierry responding, either taking the patch or telling me what I need to do to fix it. I saw Sean Paul ping Thierry on IRC on June 3rd and as far as I could tell there was no response. https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true ...and as you can see Heiko pinged this thread on June 14th. Thierry: can you help give us some direction? Are you uninterested in reviewing them and would prefer that I find someone to land them in drm-misc directly? -Doug
Hi, On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote: > > > > Hi Douglas. > > > > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote: > > > I'm reviving Sean Paul's old patchset to get mode support in device > > > tree. The cover letter for his v3 is at: > > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html > > > > > > No code is different between v4 and v5, just commit messages and text > > > in the bindings. > > > > > > I've pulled together the patches that didn't land in v3, addressed > > > outstanding feedback, and reposted. Atop them I've added patches for > > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and > > > rk3288-veryon-minnie. > > > > > > Please let me know how they look. > > > > > > In general I have added people to the whole series who I think would > > > like the whole series and then let get_maintainer pick extra people it > > > thinks are relevant to each individual patch. If I see you respond to > > > any of the patches in the series, though, I'll add you to the whole > > > series Cc list next time. > > > > > > Changes in v5: > > > - Removed bit about OS may ignore (Rob/Ezequiel) > > > - Added Heiko's Tested-by > > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko) > > > > What are the plans to move forward with this? > > Or did you drop the whole idea again? > > At the moment I'm blocked on Thierry responding, either taking the > patch or telling me what I need to do to fix it. I saw Sean Paul ping > Thierry on IRC on June 3rd and as far as I could tell there was no > response. > > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true > > ...and as you can see Heiko pinged this thread on June 14th. > > Thierry: can you help give us some direction? Are you uninterested in > reviewing them and would prefer that I find someone to land them in > drm-misc directly? Sam: Oh! I hadn't noticed that you've been added as a panel maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer for drm/panel"). Does that mean you are able to provide some advice for how to land this series? As far as I know everything is in order for it to land, but if you are aware of something I need to do to spin it then please let me know! Thanks! -Doug
On Fri, Jun 28, 2019 at 9:55 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Jun 26, 2019 at 7:41 AM Doug Anderson <dianders@chromium.org> wrote: > > > > Hi, > > > > On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg <sam@ravnborg.org> wrote: > > > > > > Hi Douglas. > > > > > > On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote: > > > > I'm reviving Sean Paul's old patchset to get mode support in device > > > > tree. The cover letter for his v3 is at: > > > > https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html > > > > > > > > No code is different between v4 and v5, just commit messages and text > > > > in the bindings. > > > > > > > > I've pulled together the patches that didn't land in v3, addressed > > > > outstanding feedback, and reposted. Atop them I've added patches for > > > > rk3288-veyron-chromebook (used for jaq, jerry, mighty, speedy) and > > > > rk3288-veryon-minnie. > > > > > > > > Please let me know how they look. > > > > > > > > In general I have added people to the whole series who I think would > > > > like the whole series and then let get_maintainer pick extra people it > > > > thinks are relevant to each individual patch. If I see you respond to > > > > any of the patches in the series, though, I'll add you to the whole > > > > series Cc list next time. > > > > > > > > Changes in v5: > > > > - Removed bit about OS may ignore (Rob/Ezequiel) > > > > - Added Heiko's Tested-by > > > > - It's not just jerry, it's most rk3288 Chromebooks (Heiko) > > > > > > What are the plans to move forward with this? > > > Or did you drop the whole idea again? > > > > At the moment I'm blocked on Thierry responding, either taking the > > patch or telling me what I need to do to fix it. I saw Sean Paul ping > > Thierry on IRC on June 3rd and as far as I could tell there was no > > response. > > > > https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2019-06-03&show_html=true > > > > ...and as you can see Heiko pinged this thread on June 14th. > > > > Thierry: can you help give us some direction? Are you uninterested in > > reviewing them and would prefer that I find someone to land them in > > drm-misc directly? > > Sam: Oh! I hadn't noticed that you've been added as a panel > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer > for drm/panel"). Does that mean you are able to provide some advice > for how to land this series? As far as I know everything is in order > for it to land, but if you are aware of something I need to do to spin > it then please let me know! BTW, at least for the binding, this will get implicitly supported in the schema conversion[1] as simple-panel as a binding is gone and panel-common already had timing node defined. A schema for the timing node is still needed though (hint :) ). Rob [1] https://patchwork.ozlabs.org/patch/1121538/
Hi Doug. > Sam: Oh! I hadn't noticed that you've been added as a panel > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer > for drm/panel"). Does that mean you are able to provide some advice > for how to land this series? Reviewer only, not maintainer.... It is on my TODO list for the weekend to go through the patch set in details and provide feedback. I have read them before, but I miss to do a more detailed read through. But I cannot apply this unless Thierry or one of the DRM maintainers ack it. We simply need someone with a better general knowledge of DRM to ack it than I have. Sam
Hi Sam, Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg: > Hi Doug. > > > Sam: Oh! I hadn't noticed that you've been added as a panel > > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer > > for drm/panel"). Does that mean you are able to provide some advice > > for how to land this series? > Reviewer only, not maintainer.... > > It is on my TODO list for the weekend to go through the patch set in > details and provide feedback. I have read them before, but I miss to do > a more detailed read through. > > But I cannot apply this unless Thierry or one of the DRM maintainers > ack it. > We simply need someone with a better general knowledge of DRM to ack it > than I have. So Thierry was able to look at the patches yesterday it seems and has Acked all the relevant ones. As a drm-misc-contributor I could also apply them myself, but now don't want to preempt any additional comments you might have ;-) . So I guess my question would be if you still want to do a review or if I should apply them. In any case, I'd like to take the actual dts patches (patches 3+6+7 if I'm not mistaken) through my tree up to arm-soc after the fact, to prevent conflicts. Thanks Heiko
Hi Sam, On Sat, Jun 29, 2019 at 7:09 AM Heiko Stübner <heiko@sntech.de> wrote: > > Hi Sam, > > Am Freitag, 28. Juni 2019, 19:13:42 CEST schrieb Sam Ravnborg: > > Hi Doug. > > > > > Sam: Oh! I hadn't noticed that you've been added as a panel > > > maintainer in commit ef0db94f94a0 ("MAINTAINERS: Add Sam as reviewer > > > for drm/panel"). Does that mean you are able to provide some advice > > > for how to land this series? > > Reviewer only, not maintainer.... > > > > It is on my TODO list for the weekend to go through the patch set in > > details and provide feedback. I have read them before, but I miss to do > > a more detailed read through. > > > > But I cannot apply this unless Thierry or one of the DRM maintainers > > ack it. > > We simply need someone with a better general knowledge of DRM to ack it > > than I have. > > So Thierry was able to look at the patches yesterday it seems and has Acked > all the relevant ones. As a drm-misc-contributor I could also apply them > myself, but now don't want to preempt any additional comments you might > have ;-) . So I guess my question would be if you still want to do a review > or if I should apply them. Hopefully you saw, but I responded to all of your review feedback. In the end, I thought it'd be OK to land the series as-is and I can fix up nits in a follow-up series, though I'm waiting for your responses to a couple questions first. It would be ideal if you could confirm that you're OK with this plan even if you don't have time to respond in detail to my emails yet. I think Heiko can land them all through the appropriate channels since the patches have all the proper Acks. Thanks! -Doug
Hi Dough. > > So Thierry was able to look at the patches yesterday it seems and has Acked > > all the relevant ones. As a drm-misc-contributor I could also apply them > > myself, but now don't want to preempt any additional comments you might > > have ;-) . So I guess my question would be if you still want to do a review > > or if I should apply them. > > Hopefully you saw, but I responded to all of your review feedback. In > the end, I thought it'd be OK to land the series as-is and I can fix > up nits in a follow-up series, though I'm waiting for your responses > to a couple questions first. > > It would be ideal if you could confirm that you're OK with this plan > even if you don't have time to respond in detail to my emails yet. I > think Heiko can land them all through the appropriate channels since > the patches have all the proper Acks. My main concern was the bug cocerning override_mode - which turned out to be me confused. There is one part about flags that does not yet makes sense but we can fix it later. Please resend a series that applies to drm-misc-next so we can land this. Sam
Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson: > Let's document the display timings that most veyron chromebooks (like > jaq, jerry, mighty, speedy) have been using out in the field. This > uses the standard blankings but a slightly slower clock rate, thus > getting a refresh rate 58.3 Hz. > > NOTE: this won't really do anything except cause DRM to properly > report the refresh rate since vop_crtc_mode_fixup() was rounding the > pixel clock to 74.25 MHz anyway. Apparently the adjusted rate isn't > exposed to userspace so it's important that the rate we're trying to > achieve is mostly right. > > For the downstream kernel change related to this see See > https://crrev.com/c/324558. > > NOTE: minnie uses a different panel will be fixed up in a future > patch, so for now we'll just delete the panel timings there. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> applied for 5.3 Thanks Heiko
Am Montag, 1. April 2019, 19:17:24 CEST schrieb Douglas Anderson: > Just like we did for rk3288-veyron-chromebook, we want to be able to > use one of the fixed PLLs in the system to make the pixel clock for > minnie. > > Specifying these timings matches us with how the display is used on > the downstream Chrome OS kernel. See https://crrev.com/c/323211. > > Unlike what we did for rk3288-veyron-chromebook, this CL actually > changes the timings (though not the pixel clock) that is used when > using the upstream kernel. Booting up a minnie shows that it ended up > with a 66.67 MHz pixel clock but it was still using the > porches/blankings it would have wanted for a 72.5 MHz pixel clock. > > NOTE: compared to the downstream kernel, this seems to cause a > slightly different result reported in the 'modetest' command on a > Chromebook. The downstream kernel shows: > 1280x800 60 1280 1298 1330 1351 800 804 822 830 66667 > > With this patch we have: > 1280x800 59 1280 1298 1330 1351 800 804 822 830 66666 > > Specifically modetest was reporting 60 Hz on the downstream kernel but > the upstream kernel does the math and comesup with 59 (because we > actually achieve 59.45 Hz). Also upstream doesn't round the Hz up > when converting to kHz--it seems to truncate. > > ALSO NOTE: when I look at the EDID from the datasheet, I see: > -hsync -vsync > ...but it seems like we've never actually run with that so I've > continued leaving that out. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> applied for 5.4 Thanks Heiko
Am Donnerstag, 11. Juli 2019, 23:27:44 CEST schrieb Heiko Stübner: > Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson: > > Let's document the display timings that most veyron chromebooks (like > > jaq, jerry, mighty, speedy) have been using out in the field. This > > uses the standard blankings but a slightly slower clock rate, thus > > getting a refresh rate 58.3 Hz. > > > > NOTE: this won't really do anything except cause DRM to properly > > report the refresh rate since vop_crtc_mode_fixup() was rounding the > > pixel clock to 74.25 MHz anyway. Apparently the adjusted rate isn't > > exposed to userspace so it's important that the rate we're trying to > > achieve is mostly right. > > > > For the downstream kernel change related to this see See > > https://crrev.com/c/324558. > > > > NOTE: minnie uses a different panel will be fixed up in a future > > patch, so for now we'll just delete the panel timings there. > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > applied for 5.3 5.4 obviously [just to not confuse people reading that later]