[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King]

Some ARM platforms do not wire the HDLCD interrupt.  Allow hdlcd to
initialise without an interrupt present.

Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
 Documentation/devicetree/bindings/display/arm,hdlcd.txt |  6 +++---
 drivers/gpu/drm/arm/hdlcd_drv.c                         | 13 ++++++++-----
 2 files changed, 11 insertions(+), 8 deletions(-)

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;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King]

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(-)

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;
-- 
2.7.4

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>

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.

-- 
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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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.

-- 
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.

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> 

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.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> > 
> 
> 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...)

-- 
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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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...)

-- 
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.

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> > > 
> > 
> > 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.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Rob Herring]

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-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/display/arm,hdlcd.txt |  6 +++---

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

>  drivers/gpu/drm/arm/hdlcd_drv.c                         | 13 ++++++++-----
>  2 files changed, 11 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Rob Herring]

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(-)

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Vladimir Murzin]

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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Vladimir Murzin]

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

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Vladimir Murzin]

On 10/08/17 13:15, Vladimir Murzin wrote:
> 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.

Ok, with CONFIG_FORCE_MAX_ZONEORDER=12 I see

[    5.242423] [drm] found ARM HDLCD version r0p0
[    5.493835] tda998x 2-0070: found TDA19988
[    5.527771] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x1470f8)
[    5.535819] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    5.543478] [drm] No driver support for vblank timestamp query.
[    7.443189] hdlcd 40205000.hdlcd: fb0:  frame buffer device
[    7.501975] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0

when display is connected.

To make fb-test [1] happy I had to apply following diff:

diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 9a18e1b..d4cb1b1 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -10,6 +10,7 @@ config DRM_HDLCD
        select DRM_ARM
        select DRM_KMS_HELPER
        select DRM_KMS_CMA_HELPER
+       select FB_PROVIDE_GET_FB_UNMAPPED_AREA if !MMU
        help
          Choose this option if you have an ARM High Definition Colour LCD
          controller.

(The only user of FB_PROVIDE_GET_FB_UNMAPPED_AREA is NOMMU only drivers/gpu/drm/stm/)

However, I do not see anything on the screen. I'm probably missing something
obvious, so if you have an idea, please let me know and I can test the patch.

[1] https://github.com/prpplague/fb-test-app.git 

Thanks
Vladimir

> 
> Cheers
> Vladimir
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Vladimir Murzin]

On 10/08/17 13:15, Vladimir Murzin wrote:
> 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.

Ok, with CONFIG_FORCE_MAX_ZONEORDER=12 I see

[    5.242423] [drm] found ARM HDLCD version r0p0
[    5.493835] tda998x 2-0070: found TDA19988
[    5.527771] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x1470f8)
[    5.535819] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    5.543478] [drm] No driver support for vblank timestamp query.
[    7.443189] hdlcd 40205000.hdlcd: fb0:  frame buffer device
[    7.501975] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0

when display is connected.

To make fb-test [1] happy I had to apply following diff:

diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 9a18e1b..d4cb1b1 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -10,6 +10,7 @@ config DRM_HDLCD
        select DRM_ARM
        select DRM_KMS_HELPER
        select DRM_KMS_CMA_HELPER
+       select FB_PROVIDE_GET_FB_UNMAPPED_AREA if !MMU
        help
          Choose this option if you have an ARM High Definition Colour LCD
          controller.

(The only user of FB_PROVIDE_GET_FB_UNMAPPED_AREA is NOMMU only drivers/gpu/drm/stm/)

However, I do not see anything on the screen. I'm probably missing something
obvious, so if you have an idea, please let me know and I can test the patch.

[1] https://github.com/prpplague/fb-test-app.git 

Thanks
Vladimir

> 
> Cheers
> Vladimir
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

On Mon, Aug 21, 2017 at 03:45:21PM +0100, Vladimir Murzin wrote:
> On 10/08/17 13:15, Vladimir Murzin wrote:
> > 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.
> 
> Ok, with CONFIG_FORCE_MAX_ZONEORDER=12 I see
> 
> [    5.242423] [drm] found ARM HDLCD version r0p0
> [    5.493835] tda998x 2-0070: found TDA19988
> [    5.527771] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x1470f8)
> [    5.535819] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    5.543478] [drm] No driver support for vblank timestamp query.
> [    7.443189] hdlcd 40205000.hdlcd: fb0:  frame buffer device
> [    7.501975] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0
> 
> when display is connected.
> 
> To make fb-test [1] happy I had to apply following diff:
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index 9a18e1b..d4cb1b1 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -10,6 +10,7 @@ config DRM_HDLCD
>         select DRM_ARM
>         select DRM_KMS_HELPER
>         select DRM_KMS_CMA_HELPER
> +       select FB_PROVIDE_GET_FB_UNMAPPED_AREA if !MMU
>         help
>           Choose this option if you have an ARM High Definition Colour LCD
>           controller.
> 
> (The only user of FB_PROVIDE_GET_FB_UNMAPPED_AREA is NOMMU only drivers/gpu/drm/stm/)
> 
> However, I do not see anything on the screen. I'm probably missing something
> obvious, so if you have an idea, please let me know and I can test the patch.

Do you have fbdev/fbcon enabled? If not, then you need some userspace that
makes use of the DRM interface. I usually play with the tests from
libdrm, you can start with modetest.

Best regards,
Liviu

> 
> [1] https://github.com/prpplague/fb-test-app.git 
> 
> Thanks
> Vladimir
> 
> > 
> > Cheers
> > Vladimir
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

On Mon, Aug 21, 2017 at 03:45:21PM +0100, Vladimir Murzin wrote:
> On 10/08/17 13:15, Vladimir Murzin wrote:
> > 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.
> 
> Ok, with CONFIG_FORCE_MAX_ZONEORDER=12 I see
> 
> [    5.242423] [drm] found ARM HDLCD version r0p0
> [    5.493835] tda998x 2-0070: found TDA19988
> [    5.527771] hdlcd 40205000.hdlcd: bound 2-0070 (ops 0x1470f8)
> [    5.535819] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    5.543478] [drm] No driver support for vblank timestamp query.
> [    7.443189] hdlcd 40205000.hdlcd: fb0:  frame buffer device
> [    7.501975] [drm] Initialized hdlcd 1.0.0 20151021 for 40205000.hdlcd on minor 0
> 
> when display is connected.
> 
> To make fb-test [1] happy I had to apply following diff:
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index 9a18e1b..d4cb1b1 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -10,6 +10,7 @@ config DRM_HDLCD
>         select DRM_ARM
>         select DRM_KMS_HELPER
>         select DRM_KMS_CMA_HELPER
> +       select FB_PROVIDE_GET_FB_UNMAPPED_AREA if !MMU
>         help
>           Choose this option if you have an ARM High Definition Colour LCD
>           controller.
> 
> (The only user of FB_PROVIDE_GET_FB_UNMAPPED_AREA is NOMMU only drivers/gpu/drm/stm/)
> 
> However, I do not see anything on the screen. I'm probably missing something
> obvious, so if you have an idea, please let me know and I can test the patch.

Do you have fbdev/fbcon enabled? If not, then you need some userspace that
makes use of the DRM interface. I usually play with the tests from
libdrm, you can start with modetest.

Best regards,
Liviu

> 
> [1] https://github.com/prpplague/fb-test-app.git 
> 
> Thanks
> Vladimir
> 
> > 
> > Cheers
> > Vladimir
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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.

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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...

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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...

-- 
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

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Liviu Dudau]

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

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm: hdlcd: allow HDLCD to be used without interrupt

[Russell King - ARM Linux]

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.

-- 
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