| Message ID | E1daJCF-0003pG-DI@rmk-PC.armlinux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > initialise without an interrupt present. > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> This isn't fully functional on ARM MPS platforms yet, but at least gets us further. Without any display connected: [ 14.315986] [drm] found ARM HDLCD version r0p0 [ 14.557038] tda998x 2-0070: found TDA19988 [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 14.639335] [drm] No driver support for vblank timestamp query. [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0 With a TV connected, the driver doesn't initialise: [ 14.422810] [drm] found ARM HDLCD version r0p0 [ 14.657227] tda998x 2-0070: found TDA19988 [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 14.739538] [drm] No driver support for vblank timestamp query. [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 [ 15.365082] tda998x: probe of 2-0070 failed with error -12 I don't think this is correct behaviour - if we fail to set an initial configuration (which will be based on the resolution of the connected display) why should the driver fail to probe - it's not that there is no device, it's (in this case) that there aren't the resources for the chosen mode. Userspace could always try setting a different mode. I suspect the above failure is down to either (a) not having enough memory available to allocate a 1920x1080 frame buffer, or (b) not (yet) being able to program the hdlcd pixel clock for this platform, which is currently hard-coded in DT at 23.75MHz.
On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > initialise without an interrupt present. > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > Hi Russell, Sorry for my silence, I was on holiday this week and just came back today. > This isn't fully functional on ARM MPS platforms yet, but at least > gets us further. Without any display connected: > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > [ 14.557038] tda998x 2-0070: found TDA19988 > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 14.639335] [drm] No driver support for vblank timestamp query. > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0 > > With a TV connected, the driver doesn't initialise: > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > [ 14.657227] tda998x 2-0070: found TDA19988 > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [ 14.739538] [drm] No driver support for vblank timestamp query. > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > I don't think this is correct behaviour - if we fail to set an initial > configuration (which will be based on the resolution of the connected > display) why should the driver fail to probe - it's not that there is > no device, it's (in this case) that there aren't the resources for the > chosen mode. Userspace could always try setting a different mode. > > I suspect the above failure is down to either (a) not having enough > memory available to allocate a 1920x1080 frame buffer, or (b) not > (yet) being able to program the hdlcd pixel clock for this platform, > which is currently hard-coded in DT at 23.75MHz. I don't think it is the clock, if that fails then you would not see the r0p0 version number being printed. Due to the fact that until now HDLCD has run mostly on platforms that have SCP, which takes care of actual setup of the clocks, it is pretty lax on errors on pixel clock setup. That is the reason why I have added the 'clocks' entry in debugfs, to be able to find out the actual clock setup vs what HDLCD would like to have for the current mode. If is quite likely to be a memory issue (-12 points that way too). Also, may I ask what MPS platform you are trying to use? I might be able to source one internally and try to reproduce your problems. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net.
On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote: > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > > initialise without an interrupt present. > > > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > > Hi Russell, > > Sorry for my silence, I was on holiday this week and just came back > today. > > > This isn't fully functional on ARM MPS platforms yet, but at least > > gets us further. Without any display connected: > > > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > > [ 14.557038] tda998x 2-0070: found TDA19988 > > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [ 14.639335] [drm] No driver support for vblank timestamp query. > > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0 > > > > With a TV connected, the driver doesn't initialise: > > > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > > [ 14.657227] tda998x 2-0070: found TDA19988 > > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [ 14.739538] [drm] No driver support for vblank timestamp query. > > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. > > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > > > I don't think this is correct behaviour - if we fail to set an initial > > configuration (which will be based on the resolution of the connected > > display) why should the driver fail to probe - it's not that there is > > no device, it's (in this case) that there aren't the resources for the > > chosen mode. Userspace could always try setting a different mode. > > > > I suspect the above failure is down to either (a) not having enough > > memory available to allocate a 1920x1080 frame buffer, or (b) not > > (yet) being able to program the hdlcd pixel clock for this platform, > > which is currently hard-coded in DT at 23.75MHz. > > I don't think it is the clock, if that fails then you would not see the > r0p0 version number being printed. Due to the fact that until now HDLCD > has run mostly on platforms that have SCP, which takes care of actual > setup of the clocks, it is pretty lax on errors on pixel clock setup. Note, however, that in this case, the clock is a fixed frequency clock. I wasn't meaning a failure to obtain the clock, I was meaning a failure to set the appropriate rate. > Also, may I ask what MPS platform you are trying to use? I might be able > to source one internally and try to reproduce your problems. I'll point you in the direction of Ian Rickards in ARM for that information. (I'm not sure if I can mention the board publically yet as its early days...)
On Fri, Jul 28, 2017 at 04:58:27PM +0100, Russell King - ARM Linux wrote: > On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote: > > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > > > initialise without an interrupt present. > > > > > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > > > > > Hi Russell, > > > > Sorry for my silence, I was on holiday this week and just came back > > today. > > > > > This isn't fully functional on ARM MPS platforms yet, but at least > > > gets us further. Without any display connected: > > > > > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > > > [ 14.557038] tda998x 2-0070: found TDA19988 > > > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.639335] [drm] No driver support for vblank timestamp query. > > > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > > > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > > > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0 > > > > > > With a TV connected, the driver doesn't initialise: > > > > > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > > > [ 14.657227] tda998x 2-0070: found TDA19988 > > > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.739538] [drm] No driver support for vblank timestamp query. > > > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. > > > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > > > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > > > > > I don't think this is correct behaviour - if we fail to set an initial > > > configuration (which will be based on the resolution of the connected > > > display) why should the driver fail to probe - it's not that there is > > > no device, it's (in this case) that there aren't the resources for the > > > chosen mode. Userspace could always try setting a different mode. > > > > > > I suspect the above failure is down to either (a) not having enough > > > memory available to allocate a 1920x1080 frame buffer, or (b) not > > > (yet) being able to program the hdlcd pixel clock for this platform, > > > which is currently hard-coded in DT at 23.75MHz. > > > > I don't think it is the clock, if that fails then you would not see the > > r0p0 version number being printed. Due to the fact that until now HDLCD > > has run mostly on platforms that have SCP, which takes care of actual > > setup of the clocks, it is pretty lax on errors on pixel clock setup. > > Note, however, that in this case, the clock is a fixed frequency clock. > I wasn't meaning a failure to obtain the clock, I was meaning a failure > to set the appropriate rate. Yeah, we both meant the same thing. :) HDLCD is not checking that strictly that the appropriate rate was set, although looking into hdlcd_crtc_atomic_check() we do return -EINVAL if the set rate differs from what the mode wants. Maybe add a printk there to see if you hit that case? > > > Also, may I ask what MPS platform you are trying to use? I might be able > > to source one internally and try to reproduce your problems. > > I'll point you in the direction of Ian Rickards in ARM for that > information. (I'm not sure if I can mention the board publically > yet as its early days...) Thanks, I'll get in touch with Ian. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net.
On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > initialise without an interrupt present. > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > --- > Documentation/devicetree/bindings/display/arm,hdlcd.txt | 6 +++--- Acked-by: Rob Herring <robh@kernel.org> > drivers/gpu/drm/arm/hdlcd_drv.c | 13 ++++++++----- > 2 files changed, 11 insertions(+), 8 deletions(-)
On 26/07/17 11:27, Russell King - ARM Linux wrote: > I suspect the above failure is down to either (a) not having enough > memory available to allocate a 1920x1080 frame buffer, or (b) not > (yet) being able to program the hdlcd pixel clock for this platform, > which is currently hard-coded in DT at 23.75MHz. Given it is NOMMU it is likely (a). Usually, tweaking FORCE_MAX_ZONEORDER helped me in such cases. Cheers Vladimir
On Fri, Jul 28, 2017 at 04:58:27PM +0100, Russell King - ARM Linux wrote: > On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote: > > On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote: > > > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote: > > > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to > > > > initialise without an interrupt present. > > > > > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> > > > > > > > Hi Russell, > > > > Sorry for my silence, I was on holiday this week and just came back > > today. > > > > > This isn't fully functional on ARM MPS platforms yet, but at least > > > gets us further. Without any display connected: > > > > > > [ 14.315986] [drm] found ARM HDLCD version r0p0 > > > [ 14.557038] tda998x 2-0070: found TDA19988 > > > [ 14.622232] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.630406] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.639335] [drm] No driver support for vblank timestamp query. > > > [ 14.653210] [drm] Cannot find any crtc or sizes - going 1024x768 > > > [ 15.232556] hdlcd 40205000.hdlcd: fb0: frame buffer device > > > [ 15.284076] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0 > > > > > > With a TV connected, the driver doesn't initialise: > > > > > > [ 14.422810] [drm] found ARM HDLCD version r0p0 > > > [ 14.657227] tda998x 2-0070: found TDA19988 > > > [ 14.722439] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x213534) > > > [ 14.730613] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > > [ 14.739538] [drm] No driver support for vblank timestamp query. > > > [ 15.311977] hdlcd 40205000.hdlcd: Failed to set initial hw configuration. > > > [ 15.357402] hdlcd 40205000.hdlcd: master bind failed: -12 > > > [ 15.365082] tda998x: probe of 2-0070 failed with error -12 > > > > > > I don't think this is correct behaviour - if we fail to set an initial > > > configuration (which will be based on the resolution of the connected > > > display) why should the driver fail to probe - it's not that there is > > > no device, it's (in this case) that there aren't the resources for the > > > chosen mode. Userspace could always try setting a different mode. > > > > > > I suspect the above failure is down to either (a) not having enough > > > memory available to allocate a 1920x1080 frame buffer, or (b) not > > > (yet) being able to program the hdlcd pixel clock for this platform, > > > which is currently hard-coded in DT at 23.75MHz. > > > > I don't think it is the clock, if that fails then you would not see the > > r0p0 version number being printed. Due to the fact that until now HDLCD > > has run mostly on platforms that have SCP, which takes care of actual > > setup of the clocks, it is pretty lax on errors on pixel clock setup. > > Note, however, that in this case, the clock is a fixed frequency clock. > I wasn't meaning a failure to obtain the clock, I was meaning a failure > to set the appropriate rate. > > > Also, may I ask what MPS platform you are trying to use? I might be able > > to source one internally and try to reproduce your problems. > > I'll point you in the direction of Ian Rickards in ARM for that > information. (I'm not sure if I can mention the board publically > yet as its early days...) Hi Russell, I've worked with Vladimir Murzin inside ARM to try to sort out problems on the board like the one that you have. He's got to a point where the HDLCD starts correctly after adding a non-fixed pxlclk source, but then the rest of the setup is semi-useless without a working IRQ because DRM atomic calls will give you a vblank timeout splat everytime you invoke them. So I'm not sure how you want to progress with this patch, as not having an IRQ line means you will not get any vblank interrupts and you can't use the driver with userspace that calls DRM API. The RTL guys are apparently working on a fix, but I have no ETA or details on when they are going to do. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net.
On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote: > I've worked with Vladimir Murzin inside ARM to try to sort out problems > on the board like the one that you have. He's got to a point where the HDLCD > starts correctly after adding a non-fixed pxlclk source, but then the rest of > the setup is semi-useless without a working IRQ because DRM atomic calls > will give you a vblank timeout splat everytime you invoke them. So I'm > not sure how you want to progress with this patch, as not having an IRQ > line means you will not get any vblank interrupts and you can't use the > driver with userspace that calls DRM API. > > The RTL guys are apparently working on a fix, but I have no ETA or > details on when they are going to do. It sounds then like this patch doesn't make sense - so I'm happy for it to be dropped. It's something to bear in mind in the future when folk decide whether to adopt fbdev or DRM support for hardware that gets used in MMU-less hardware...
On Tue, Aug 29, 2017 at 05:48:24PM +0100, Russell King - ARM Linux wrote: > On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote: > > I've worked with Vladimir Murzin inside ARM to try to sort out problems > > on the board like the one that you have. He's got to a point where the HDLCD > > starts correctly after adding a non-fixed pxlclk source, but then the rest of > > the setup is semi-useless without a working IRQ because DRM atomic calls > > will give you a vblank timeout splat everytime you invoke them. So I'm > > not sure how you want to progress with this patch, as not having an IRQ > > line means you will not get any vblank interrupts and you can't use the > > driver with userspace that calls DRM API. > > > > The RTL guys are apparently working on a fix, but I have no ETA or > > details on when they are going to do. > > It sounds then like this patch doesn't make sense - so I'm happy > for it to be dropped. It's something to bear in mind in the future > when folk decide whether to adopt fbdev or DRM support for hardware > that gets used in MMU-less hardware... I don't think this has anything to do with the presence of a MMU or not. If you don't have a way of signaling back to userspace when a vblank event has occured then the driver needs to have additional code to reject ioctls that depend on that functionality. So your patch is not wrong, it just needs more code to be really useful. Best regards, Liviu > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up
On Wed, Aug 30, 2017 at 11:54:14AM +0100, Liviu Dudau wrote: > On Tue, Aug 29, 2017 at 05:48:24PM +0100, Russell King - ARM Linux wrote: > > On Tue, Aug 29, 2017 at 02:33:52PM +0100, Liviu Dudau wrote: > > > I've worked with Vladimir Murzin inside ARM to try to sort out problems > > > on the board like the one that you have. He's got to a point where the HDLCD > > > starts correctly after adding a non-fixed pxlclk source, but then the rest of > > > the setup is semi-useless without a working IRQ because DRM atomic calls > > > will give you a vblank timeout splat everytime you invoke them. So I'm > > > not sure how you want to progress with this patch, as not having an IRQ > > > line means you will not get any vblank interrupts and you can't use the > > > driver with userspace that calls DRM API. > > > > > > The RTL guys are apparently working on a fix, but I have no ETA or > > > details on when they are going to do. > > > > It sounds then like this patch doesn't make sense - so I'm happy > > for it to be dropped. It's something to bear in mind in the future > > when folk decide whether to adopt fbdev or DRM support for hardware > > that gets used in MMU-less hardware... > > I don't think this has anything to do with the presence of a MMU or not. It doesn't directly, but nommu is probably more likely to not wire the interrupt than mmu systems, on the grounds that nommu is more embedded.
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt b/Documentation/devicetree/bindings/display/arm,hdlcd.txt index 78bc24296f3e..7f78b455c4b2 100644 --- a/Documentation/devicetree/bindings/display/arm,hdlcd.txt +++ b/Documentation/devicetree/bindings/display/arm,hdlcd.txt @@ -8,9 +8,6 @@ digital encoder (DVI or HDMI). Required properties: - compatible: "arm,hdlcd" - reg: Physical base address and length of the controller's registers. - - interrupts: One interrupt used by the display controller to notify the - interrupt controller when any of the interrupt sources programmed in - the interrupt mask register have activated. - clocks: A list of phandle + clock-specifier pairs, one for each entry in 'clock-names'. - clock-names: A list of clock names. For HDLCD it should contain: @@ -22,6 +19,9 @@ digital encoder (DVI or HDMI). Documentation/devicetree/bindings/graph.txt. Optional properties: + - interrupts: One interrupt used by the display controller to notify the + interrupt controller when any of the interrupt sources programmed in + the interrupt mask register have activated. - memory-region: phandle to a node describing memory (see Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to be used for the framebuffer; if not present, the framebuffer may be located diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c index d3da87fbd85a..283c435fe90b 100644 --- a/drivers/gpu/drm/arm/hdlcd_drv.c +++ b/drivers/gpu/drm/arm/hdlcd_drv.c @@ -36,7 +36,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned long flags) struct platform_device *pdev = to_platform_device(drm->dev); struct resource *res; u32 version; - int ret; + int ret, irq; hdlcd->clk = devm_clk_get(drm->dev, "pxlclk"); if (IS_ERR(hdlcd->clk)) @@ -82,10 +82,13 @@ static int hdlcd_load(struct drm_device *drm, unsigned long flags) goto setup_fail; } - ret = drm_irq_install(drm, platform_get_irq(pdev, 0)); - if (ret < 0) { - DRM_ERROR("failed to install IRQ handler\n"); - goto irq_fail; + irq = platform_get_irq(pdev, 0); + if (irq > 0) { + ret = drm_irq_install(drm, irq); + if (ret < 0) { + DRM_ERROR("failed to install IRQ handler\n"); + goto irq_fail; + } } return 0;
Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to initialise without an interrupt present. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> --- Documentation/devicetree/bindings/display/arm,hdlcd.txt | 6 +++--- drivers/gpu/drm/arm/hdlcd_drv.c | 13 ++++++++----- 2 files changed, 11 insertions(+), 8 deletions(-)