Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1243673 > unrolled thread

bcm2835 (Raspberry Pi) KMS driver

Back to article view | Back to linux.kernel

Contents

  bcm2835 (Raspberry Pi) KMS driver Eric Anholt <eric@anholt.net> - 2015-10-09 23:30 +0200
    [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4. Eric Anholt <eric@anholt.net> - 2015-10-09 23:40 +0200
      Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4. Sebastian Reichel <sre@kernel.org> - 2015-10-10 01:40 +0200
        Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4. Eric Anholt <eric@anholt.net> - 2015-10-13 20:20 +0200
      Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4. Rob Herring <robh@kernel.org> - 2015-10-13 15:30 +0200
        Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4. Eric Anholt <eric@anholt.net> - 2015-10-13 20:30 +0200
          Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4. Rob Herring <robh@kernel.org> - 2015-10-14 00:00 +0200
    [PATCH v3 4/7] drm/vc4: Use the fbdev_cma helpers Eric Anholt <eric@anholt.net> - 2015-10-09 23:40 +0200
    Re: bcm2835 (Raspberry Pi) KMS driver Stefan Wahren <info@lategoodbye.de> - 2015-10-11 14:50 +0200
      Re: bcm2835 (Raspberry Pi) KMS driver Stephen Warren <swarren@wwwdotorg.org> - 2015-10-12 22:40 +0200
        Re: bcm2835 (Raspberry Pi) KMS driver Eric Anholt <eric@anholt.net> - 2015-10-12 23:00 +0200
    Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi. Stefan Wahren <info@lategoodbye.de> - 2015-10-11 16:10 +0200
      Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi. Eric Anholt <eric@anholt.net> - 2015-10-13 20:20 +0200
        Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi. Stefan Wahren <info@lategoodbye.de> - 2015-10-13 21:00 +0200
          Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi. Stefan Wahren <info@lategoodbye.de> - 2015-10-13 21:10 +0200

#1243673 — bcm2835 (Raspberry Pi) KMS driver

This is a respin of the Raspberry Pi KMS series.  Now that we've got a
real clock driver, I can actually set new video modes.  Also in this
version, most of the custom DT stuff from before is gone, thanks to
finding exynos's platform_driver component matching code (I have sent
separate patches to drivers/base to make helpers for doing it).

https://github.com/anholt/linux/tree/vc4-kms-squash-2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1243675 — [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
other Broadcom SoCs.

This binding follows the model of msm, imx, sti, and others, where
there is a subsystem node for the whole GPU, with nodes for the
individual HW components within it.

Signed-off-by: Eric Anholt <eric@anholt.net>
---

v2: Extend the commit message, fix several nits from Stephen Warren.
v3: Rename the compatibility strings, clean up node names, drop the
    unnecessary lists of components.  Use compatibility strings for
    choosing CRTC HVS channel numbers.  Document the HDMI clock usage.

 .../devicetree/bindings/gpu/brcm,bcm-vc4.txt       | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
new file mode 100644
index 0000000..175bcde
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
@@ -0,0 +1,64 @@
+Broadcom VC4 GPU
+
+The VC4 device present on the Raspberry Pi includes a display system
+with HDMI output and the HVS scaler for compositing display planes.
+
+Required properties for VC4:
+- compatible:	Should be "brcm,bcm2835-vc4"
+
+Required properties for Pixel Valve:
+- compatible:	Should be one of "brcm,bcm2835-pixelvalve0",
+		"brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
+- reg:		Physical base address and length of the PV's registers
+- interrupts:	The interrupt number
+		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HVS:
+- compatible:	Should be "brcm,bcm2835-hvs"
+- reg:		Physical base address and length of the HVS's registers
+- interrupts:	The interrupt number
+		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
+Required properties for HDMI
+- compatible:	Should be "brcm,bcm2835-hdmi"
+- reg:		Physical base address and length of the two register ranges
+		  ("HDMI" and "HD", in that order)
+- interrupts:	The interrupt numbers
+		  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+- ddc:		phandle of the I2C controller used for DDC EDID probing
+- clocks:	a) hdmi: The HDMI state machine clock
+		b) pixel: The pixel clock.
+
+Optional properties for HDMI:
+- hpd-gpio:	The GPIO pin for HDMI hotplug detect (if it doesn't appear
+		  as an interrupt/status bit in the HDMI controller
+		  itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
+
+Example:
+pixelvalve@7e807000 {
+	compatible = "brcm,bcm2835-pixelvalve2";
+	reg = <0x7e807000 0x100>;
+	interrupts = <2 10>; /* pixelvalve */
+};
+
+hvs@7e400000 {
+	compatible = "brcm,bcm2835-hvs";
+	reg = <0x7e400000 0x6000>;
+	interrupts = <2 1>;
+};
+
+hdmi: hdmi@7e902000 {
+	compatible = "brcm,bcm2835-hdmi";
+	reg = <0x7e902000 0x600>,
+	      <0x7e808000 0x100>;
+	interrupts = <2 8>, <2 9>;
+	ddc = <&i2c2>;
+	hpd-gpio = <&gpio 46 GPIO_ACTIVE_HIGH>;
+	clocks = <&clocks BCM2835_PLLH_PIX>,
+		 <&clocks BCM2835_CLOCK_HSM>;
+	clock-names = "pixel", "hdmi";
+};
+
+vc4: gpu@7e4c0000 {
+	compatible = "brcm,bcm2835-vc4";
+};
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243740 — Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Fri, Oct 09, 2015 at 02:27:42PM -0700, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
> other Broadcom SoCs.
> 
> This binding follows the model of msm, imx, sti, and others, where
> there is a subsystem node for the whole GPU, with nodes for the
> individual HW components within it.

I think it would be useful to have the acronyms written out one time
in the document (VC4, HVS).

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#1246019 — Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

[Multipart message — attachments visible in raw view] — view raw

Sebastian Reichel <sre@kernel.org> writes:

> Hi,
>
> On Fri, Oct 09, 2015 at 02:27:42PM -0700, Eric Anholt wrote:
>> VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
>> other Broadcom SoCs.
>> 
>> This binding follows the model of msm, imx, sti, and others, where
>> there is a subsystem node for the whole GPU, with nodes for the
>> individual HW components within it.
>
> I think it would be useful to have the acronyms written out one time
> in the document (VC4, HVS).

Done.

[toc] | [prev] | [next] | [standalone]

#1245703 — Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

On Fri, Oct 9, 2015 at 4:27 PM, Eric Anholt <eric@anholt.net> wrote:
> VC4 is the GPU (display and 3D) subsystem present on the 2835 and some
> other Broadcom SoCs.
>
> This binding follows the model of msm, imx, sti, and others, where
> there is a subsystem node for the whole GPU, with nodes for the

The subsystem node is gone now, right?

> individual HW components within it.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>
> v2: Extend the commit message, fix several nits from Stephen Warren.
> v3: Rename the compatibility strings, clean up node names, drop the
>     unnecessary lists of components.  Use compatibility strings for
>     choosing CRTC HVS channel numbers.  Document the HDMI clock usage.
>
>  .../devicetree/bindings/gpu/brcm,bcm-vc4.txt       | 64 ++++++++++++++++++++++

Can you put this in bindings/display/ instead? Things are moving there in 4.4.


>  1 file changed, 64 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
> new file mode 100644
> index 0000000..175bcde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
> @@ -0,0 +1,64 @@
> +Broadcom VC4 GPU
> +
> +The VC4 device present on the Raspberry Pi includes a display system
> +with HDMI output and the HVS scaler for compositing display planes.
> +
> +Required properties for VC4:
> +- compatible:  Should be "brcm,bcm2835-vc4"

reg property? interrupts? clocks?

> +
> +Required properties for Pixel Valve:
> +- compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
> +               "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
> +- reg:         Physical base address and length of the PV's registers
> +- interrupts:  The interrupt number
> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> +
> +Required properties for HVS:
> +- compatible:  Should be "brcm,bcm2835-hvs"
> +- reg:         Physical base address and length of the HVS's registers
> +- interrupts:  The interrupt number
> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> +
> +Required properties for HDMI

Is HDMI the only output possibility? If not, then you should have OF
graph nodes describing the connection between HDMI block and HVS (or
PV?).

> +- compatible:  Should be "brcm,bcm2835-hdmi"
> +- reg:         Physical base address and length of the two register ranges
> +                 ("HDMI" and "HD", in that order)
> +- interrupts:  The interrupt numbers
> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
> +- ddc:         phandle of the I2C controller used for DDC EDID probing
> +- clocks:      a) hdmi: The HDMI state machine clock
> +               b) pixel: The pixel clock.
> +
> +Optional properties for HDMI:
> +- hpd-gpio:    The GPIO pin for HDMI hotplug detect (if it doesn't appear

*-gpio is deprecated, so "hpd-gpios".

Really, I think this and ddc should be in hdmi-connector binding node.
What has been done for bindings so far is all over the map though.

> +                 as an interrupt/status bit in the HDMI controller
> +                 itself).  See bindings/pinctrl/brcm,bcm2835-gpio.txt
> +
> +Example:
> +pixelvalve@7e807000 {
> +       compatible = "brcm,bcm2835-pixelvalve2";
> +       reg = <0x7e807000 0x100>;
> +       interrupts = <2 10>; /* pixelvalve */
> +};
> +
> +hvs@7e400000 {
> +       compatible = "brcm,bcm2835-hvs";
> +       reg = <0x7e400000 0x6000>;
> +       interrupts = <2 1>;
> +};
> +
> +hdmi: hdmi@7e902000 {
> +       compatible = "brcm,bcm2835-hdmi";
> +       reg = <0x7e902000 0x600>,
> +             <0x7e808000 0x100>;
> +       interrupts = <2 8>, <2 9>;
> +       ddc = <&i2c2>;
> +       hpd-gpio = <&gpio 46 GPIO_ACTIVE_HIGH>;
> +       clocks = <&clocks BCM2835_PLLH_PIX>,
> +                <&clocks BCM2835_CLOCK_HSM>;
> +       clock-names = "pixel", "hdmi";
> +};
> +
> +vc4: gpu@7e4c0000 {
> +       compatible = "brcm,bcm2835-vc4";
> +};
> --
> 2.1.4
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1246032 — Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

[Multipart message — attachments visible in raw view] — view raw

Rob Herring <robh@kernel.org> writes:

> On Fri, Oct 9, 2015 at 4:27 PM, Eric Anholt <eric@anholt.net> wrote:
>> ---
>>
>> v2: Extend the commit message, fix several nits from Stephen Warren.
>> v3: Rename the compatibility strings, clean up node names, drop the
>>     unnecessary lists of components.  Use compatibility strings for
>>     choosing CRTC HVS channel numbers.  Document the HDMI clock usage.
>>
>>  .../devicetree/bindings/gpu/brcm,bcm-vc4.txt       | 64 ++++++++++++++++++++++
>
> Can you put this in bindings/display/ instead? Things are moving there in 4.4.

Sure.

>>  1 file changed, 64 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>> new file mode 100644
>> index 0000000..175bcde
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>> @@ -0,0 +1,64 @@
>> +Broadcom VC4 GPU
>> +
>> +The VC4 device present on the Raspberry Pi includes a display system
>> +with HDMI output and the HVS scaler for compositing display planes.
>> +
>> +Required properties for VC4:
>> +- compatible:  Should be "brcm,bcm2835-vc4"
>
> reg property? interrupts? clocks?

This is the subsystem node.  It has no other properties currently.

>> +Required properties for Pixel Valve:
>> +- compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
>> +               "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
>> +- reg:         Physical base address and length of the PV's registers
>> +- interrupts:  The interrupt number
>> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>> +
>> +Required properties for HVS:
>> +- compatible:  Should be "brcm,bcm2835-hvs"
>> +- reg:         Physical base address and length of the HVS's registers
>> +- interrupts:  The interrupt number
>> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>> +
>> +Required properties for HDMI
>
> Is HDMI the only output possibility? If not, then you should have OF
> graph nodes describing the connection between HDMI block and HVS (or
> PV?).

I'm using compatible strings for the different instances of the module:
brcm,bcm2835-pixelvalve0/1/2.  This lets the connections get wired up
cleanly and understandably within the driver.  I spent a long time
trying to come up with an OF graph-based implementation, and I
eventually gave up.

>> +- compatible:  Should be "brcm,bcm2835-hdmi"
>> +- reg:         Physical base address and length of the two register ranges
>> +                 ("HDMI" and "HD", in that order)
>> +- interrupts:  The interrupt numbers
>> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>> +- ddc:         phandle of the I2C controller used for DDC EDID probing
>> +- clocks:      a) hdmi: The HDMI state machine clock
>> +               b) pixel: The pixel clock.
>> +
>> +Optional properties for HDMI:
>> +- hpd-gpio:    The GPIO pin for HDMI hotplug detect (if it doesn't appear
>
> *-gpio is deprecated, so "hpd-gpios".
>
> Really, I think this and ddc should be in hdmi-connector binding node.
> What has been done for bindings so far is all over the map though.

You say hpd-gpios is deprectated, but that I should use the
hdmi-connector binding that uses hpd-gpios.  Which one is it?  If
hpd-gpios deprecated, what is supposed to be used instead?

[toc] | [prev] | [next] | [standalone]

#1246192 — Re: [PATCH v3 1/7] drm/vc4: Add devicetree bindings for VC4.

On Tue, Oct 13, 2015 at 1:17 PM, Eric Anholt <eric@anholt.net> wrote:
> Rob Herring <robh@kernel.org> writes:
>
>> On Fri, Oct 9, 2015 at 4:27 PM, Eric Anholt <eric@anholt.net> wrote:
>>> ---
>>>
>>> v2: Extend the commit message, fix several nits from Stephen Warren.
>>> v3: Rename the compatibility strings, clean up node names, drop the
>>>     unnecessary lists of components.  Use compatibility strings for
>>>     choosing CRTC HVS channel numbers.  Document the HDMI clock usage.
>>>
>>>  .../devicetree/bindings/gpu/brcm,bcm-vc4.txt       | 64 ++++++++++++++++++++++
>>
>> Can you put this in bindings/display/ instead? Things are moving there in 4.4.
>
> Sure.
>
>>>  1 file changed, 64 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>>> new file mode 100644
>>> index 0000000..175bcde
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-vc4.txt
>>> @@ -0,0 +1,64 @@
>>> +Broadcom VC4 GPU
>>> +
>>> +The VC4 device present on the Raspberry Pi includes a display system
>>> +with HDMI output and the HVS scaler for compositing display planes.
>>> +
>>> +Required properties for VC4:
>>> +- compatible:  Should be "brcm,bcm2835-vc4"
>>
>> reg property? interrupts? clocks?
>
> This is the subsystem node.  It has no other properties currently.

In the example, it looks like the gpu. You also have a unit address
which implies you need a reg property.

>>> +Required properties for Pixel Valve:
>>> +- compatible:  Should be one of "brcm,bcm2835-pixelvalve0",
>>> +               "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
>>> +- reg:         Physical base address and length of the PV's registers
>>> +- interrupts:  The interrupt number
>>> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>>> +
>>> +Required properties for HVS:
>>> +- compatible:  Should be "brcm,bcm2835-hvs"
>>> +- reg:         Physical base address and length of the HVS's registers
>>> +- interrupts:  The interrupt number
>>> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>>> +
>>> +Required properties for HDMI
>>
>> Is HDMI the only output possibility? If not, then you should have OF
>> graph nodes describing the connection between HDMI block and HVS (or
>> PV?).
>
> I'm using compatible strings for the different instances of the module:
> brcm,bcm2835-pixelvalve0/1/2.  This lets the connections get wired up
> cleanly and understandably within the driver.  I spent a long time
> trying to come up with an OF graph-based implementation, and I
> eventually gave up.

I missed that before, but sorry, that's not how you should be using
compatible strings. What was your issue with OF graph? It can be
difficult to parse. I'd like to improve that with more common parsing
code.


>>> +- compatible:  Should be "brcm,bcm2835-hdmi"
>>> +- reg:         Physical base address and length of the two register ranges
>>> +                 ("HDMI" and "HD", in that order)
>>> +- interrupts:  The interrupt numbers
>>> +                 See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
>>> +- ddc:         phandle of the I2C controller used for DDC EDID probing
>>> +- clocks:      a) hdmi: The HDMI state machine clock
>>> +               b) pixel: The pixel clock.
>>> +
>>> +Optional properties for HDMI:
>>> +- hpd-gpio:    The GPIO pin for HDMI hotplug detect (if it doesn't appear
>>
>> *-gpio is deprecated, so "hpd-gpios".
>>
>> Really, I think this and ddc should be in hdmi-connector binding node.
>> What has been done for bindings so far is all over the map though.
>
> You say hpd-gpios is deprectated, but that I should use the
> hdmi-connector binding that uses hpd-gpios.  Which one is it?  If
> hpd-gpios deprecated, what is supposed to be used instead?

No, I said "hpd-gpio" with no "s" is deprecated. In other words,
always use -gpios whether it is 1 or more gpio.

The connector part is a separate issue of the location of these
properties. If you think about it, the gpio line and I2C bus have
nothing to do with the HDMI node. That's different than cases of HDMI
bridges which have a HPD signal and dedicated I2C controller. Most
examples in the kernel have not followed this and do as you have. I
only have a desire to have common binding and code to handle
connectors at this point, but that is the direction I want to go.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1243677 — [PATCH v3 4/7] drm/vc4: Use the fbdev_cma helpers

From: Derek Foreman <derekf@osg.samsung.com>

Keep the fbdev_cma pointer around so we can use it on hotplog and close
to ensure the frame buffer console is in a useful state.

Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
 drivers/gpu/drm/vc4/vc4_drv.c | 14 ++++++++++++++
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_kms.c | 18 +++++++++++++++---
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 3c3ccff..6e73060 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -14,6 +14,7 @@
 #include <linux/module.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
+#include "drm_fb_cma_helper.h"
 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
@@ -49,6 +50,14 @@ static void vc4_drm_preclose(struct drm_device *dev, struct drm_file *file)
 		vc4_cancel_page_flip(crtc, file);
 }
 
+static void vc4_lastclose(struct drm_device *dev)
+{
+	struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+	if (vc4->fbdev)
+		drm_fbdev_cma_restore_mode(vc4->fbdev);
+}
+
 static const struct file_operations vc4_drm_fops = {
 	.owner = THIS_MODULE,
 	.open = drm_open,
@@ -71,6 +80,7 @@ static struct drm_driver vc4_drm_driver = {
 			    DRIVER_ATOMIC |
 			    DRIVER_GEM |
 			    DRIVER_PRIME),
+	.lastclose = vc4_lastclose,
 	.preclose = vc4_drm_preclose,
 
 	.enable_vblank = vc4_enable_vblank,
@@ -199,6 +209,10 @@ static void vc4_drm_unbind(struct device *dev)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct drm_device *drm = platform_get_drvdata(pdev);
+	struct vc4_dev *vc4 = to_vc4_dev(drm);
+
+	if (vc4->fbdev)
+		drm_fbdev_cma_fini(vc4->fbdev);
 
 	drm_mode_config_cleanup(drm);
 
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index c710e03..23e7bac2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -15,6 +15,8 @@ struct vc4_dev {
 	struct vc4_hdmi *hdmi;
 	struct vc4_hvs *hvs;
 	struct vc4_crtc *crtc[3];
+
+	struct drm_fbdev_cma *fbdev;
 };
 
 static inline struct vc4_dev *
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index c241c8f..ee3e004 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -21,7 +21,16 @@
 #include "drm_fb_cma_helper.h"
 #include "vc4_drv.h"
 
+static void vc4_output_poll_changed(struct drm_device *dev)
+{
+	struct vc4_dev *vc4 = to_vc4_dev(dev);
+
+	if (vc4->fbdev)
+		drm_fbdev_cma_hotplug_event(vc4->fbdev);
+}
+
 static const struct drm_mode_config_funcs vc4_mode_funcs = {
+	.output_poll_changed = vc4_output_poll_changed,
 	.atomic_check = drm_atomic_helper_check,
 	.atomic_commit = drm_atomic_helper_commit,
 	.fb_create = drm_fb_cma_create,
@@ -29,6 +38,7 @@ static const struct drm_mode_config_funcs vc4_mode_funcs = {
 
 int vc4_kms_load(struct drm_device *dev)
 {
+	struct vc4_dev *vc4 = to_vc4_dev(dev);
 	int ret;
 
 	ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
@@ -44,9 +54,11 @@ int vc4_kms_load(struct drm_device *dev)
 
 	drm_mode_config_reset(dev);
 
-	drm_fbdev_cma_init(dev, 32,
-			   dev->mode_config.num_crtc,
-			   dev->mode_config.num_connector);
+	vc4->fbdev = drm_fbdev_cma_init(dev, 32,
+					dev->mode_config.num_crtc,
+					dev->mode_config.num_connector);
+	if (IS_ERR(vc4->fbdev))
+		vc4->fbdev = NULL;
 
 	drm_kms_helper_poll_init(dev);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1244116

Am 09.10.2015 um 23:27 schrieb Eric Anholt:
> This is a respin of the Raspberry Pi KMS series.  Now that we've got a
> real clock driver, I can actually set new video modes.  Also in this
> version, most of the custom DT stuff from before is gone, thanks to
> finding exynos's platform_driver component matching code (I have sent
> separate patches to drivers/base to make helpers for doing it).
>
> https://github.com/anholt/linux/tree/vc4-kms-squash-2
>
>

I want to point out that git format-patch could prepare a nice cover 
letter and usually the changelog should go there.

Regards
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1245117

On 10/11/2015 06:39 AM, Stefan Wahren wrote:
> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>> This is a respin of the Raspberry Pi KMS series.  Now that we've got a
>> real clock driver, I can actually set new video modes.  Also in this
>> version, most of the custom DT stuff from before is gone, thanks to
>> finding exynos's platform_driver component matching code (I have sent
>> separate patches to drivers/base to make helpers for doing it).
>>
>> https://github.com/anholt/linux/tree/vc4-kms-squash-2
>
> I want to point out that git format-patch could prepare a nice cover
> letter and usually the changelog should go there.

Well, I guess you could put it there, but that wouldn't remove the need 
to put the changelog in the individual patches too, so that reviewers 
don't have to switch back and forth between different messages just to 
find out what changed in each patch.

+1 on sending the cover letter using git format-patch/send-email 
thoughl; the threading here is a little odd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1245133

[Multipart message — attachments visible in raw view] — view raw

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 10/11/2015 06:39 AM, Stefan Wahren wrote:
>> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>>> This is a respin of the Raspberry Pi KMS series.  Now that we've got a
>>> real clock driver, I can actually set new video modes.  Also in this
>>> version, most of the custom DT stuff from before is gone, thanks to
>>> finding exynos's platform_driver component matching code (I have sent
>>> separate patches to drivers/base to make helpers for doing it).
>>>
>>> https://github.com/anholt/linux/tree/vc4-kms-squash-2
>>
>> I want to point out that git format-patch could prepare a nice cover
>> letter and usually the changelog should go there.
>
> Well, I guess you could put it there, but that wouldn't remove the need 
> to put the changelog in the individual patches too, so that reviewers 
> don't have to switch back and forth between different messages just to 
> find out what changed in each patch.
>
> +1 on sending the cover letter using git format-patch/send-email 
> thoughl; the threading here is a little odd.

I was using git send-email --compose.  I guess I'll play with
format-patch --cover-letter, but it seems odd that threading would be
any different between the two.

[toc] | [prev] | [next] | [standalone]

#1244136 — Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

Hi Eric,

Am 09.10.2015 um 23:27 schrieb Eric Anholt:
> This is enough for fbcon and bringing up X using
> xf86-video-modesetting.  It doesn't support the 3D accelerator or
> power management yet.
>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>
> v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
>      ordering instead of using the .load hook.  Structure registration
>      more like tegra's, but still using the typical "component" code.
>      Drop no-op hooks for atomic_begin and mode_fixup() now that
>      they're optional.  Drop sentinel in Makefile.  Fix minor style
>      nits I noticed on another reread.
>
> v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
>      of having a fixed video mode.  Use exynos-style component driver
>      matching instead of devicetree nodes to list the component driver
>      instances.  Rename compatibility strings to say bcm2835, and
>      distinguish pv0/1/2.  Clean up some h/vsync code, and add in
>      interlaced mode setup.  Fix up probe/bind error paths.  Use
>      bitops.h macros for vc4_regs.h
>
>   drivers/gpu/drm/Kconfig           |   2 +
>   drivers/gpu/drm/Makefile          |   1 +
>   drivers/gpu/drm/vc4/Kconfig       |  13 +
>   drivers/gpu/drm/vc4/Makefile      |  17 +
>   drivers/gpu/drm/vc4/vc4_bo.c      |  52 +++
>   drivers/gpu/drm/vc4/vc4_crtc.c    | 675 ++++++++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/vc4/vc4_debugfs.c |  39 +++
>   drivers/gpu/drm/vc4/vc4_drv.c     | 284 ++++++++++++++++
>   drivers/gpu/drm/vc4/vc4_drv.h     | 115 +++++++
>   drivers/gpu/drm/vc4/vc4_hdmi.c    | 588 +++++++++++++++++++++++++++++++++
>   drivers/gpu/drm/vc4/vc4_hvs.c     | 163 +++++++++
>   drivers/gpu/drm/vc4/vc4_kms.c     |  54 +++
>   drivers/gpu/drm/vc4/vc4_plane.c   | 320 ++++++++++++++++++
>   drivers/gpu/drm/vc4/vc4_regs.h    | 570 ++++++++++++++++++++++++++++++++
>   14 files changed, 2893 insertions(+)
>   create mode 100644 drivers/gpu/drm/vc4/Kconfig
>   create mode 100644 drivers/gpu/drm/vc4/Makefile
>   create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
>   create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
>   create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 1a0a8df..c4bf9a1 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
>   source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>
>   source "drivers/gpu/drm/imx/Kconfig"
> +
> +source "drivers/gpu/drm/vc4/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719..0edc9e2 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA)	+= mga/
>   obj-$(CONFIG_DRM_I810)	+= i810/
>   obj-$(CONFIG_DRM_I915)  += i915/
>   obj-$(CONFIG_DRM_MGAG200) += mgag200/
> +obj-$(CONFIG_DRM_VC4)  += vc4/
>   obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>   obj-$(CONFIG_DRM_SIS)   += sis/
>   obj-$(CONFIG_DRM_SAVAGE)+= savage/
> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> new file mode 100644
> index 0000000..e810ef7
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/Kconfig
> @@ -0,0 +1,13 @@
> +config DRM_VC4
> +	tristate "Broadcom VC4 Graphics"
> +	depends on ARCH_BCM2835

depends on (ARCH_BCM2835 || COMPILE_TEST) ?

> +	depends on DRM
> +	select DRM_KMS_HELPER
> +	select DRM_KMS_CMA_HELPER
> +	help
> +	  Choose this option if you have a system that has a Broadcom
> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
> +
> +	  This driver requires that "avoid_warnings=2" be present in
> +	  the config.txt for the firmware, to keep it from smashing
> +	  our display setup.
> + [...]
> +static void vc4_crtc_disable(struct drm_crtc *crtc)
> +{
> +	struct drm_device *dev = crtc->dev;
> +	struct vc4_dev *vc4 = to_vc4_dev(dev);
> +	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +	u32 chan = vc4_crtc->channel;
> +
> +	require_hvs_enabled(dev);
> +
> +	CRTC_WRITE(PV_V_CONTROL,
> +		   CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
> +	while (CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN)
> +		cpu_relax();
> +
> +	/* Without a wait here, we end up with a black screen. */
> +	msleep(30);

This looks a little bit strange. First we do a busy loop without any 
timeout and then a fixed msleep without reason for the exact duration.

Sorry for the possibly dumb questions:

Is it safe to read PV_V_CONTROL exactly after writing to them? No 
sleeping required?

How did you come to the 30 milli seconds?

> +  [...]
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> new file mode 100644
> index 0000000..ae37fec
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -0,0 +1,588 @@
> +/*
> + * Copyright (C) 2015 Broadcom
> + * Copyright (c) 2014 The Linux Foundation. All rights reserved.
> + * Copyright (C) 2013 Red Hat
> + * Author: Rob Clark <robdclark@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along with
> + * this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +/**
> + * DOC: VC4 Falcon HDMI module
> + *
> + * The HDMI core has a state machine and a PHY.  Most of the unit
> + * operates off of the HSM clock from CPRMAN.  It also internally uses
> + * the PLLH_PIX clock for the PHY.
> + */
> +
> +#include "drm_atomic_helper.h"
> +#include "drm_crtc_helper.h"
> +#include "drm_edid.h"
> +#include "linux/clk.h"
> +#include "linux/component.h"

#include "linux/i2c.h" ?

> +#include "linux/of_gpio.h"
> +#include "linux/of_platform.h"
> +#include "vc4_drv.h"
> +#include "vc4_regs.h"
> +
> +/* General HDMI hardware state. */
> +struct vc4_hdmi {
> +	struct platform_device *pdev;
> +
> +	struct drm_encoder *encoder;
> +	struct drm_connector *connector;
> +
> +	struct i2c_adapter *ddc;
> +	void __iomem *hdmicore_regs;
> +	void __iomem *hd_regs;
> +	int hpd_gpio;
> +
> +	struct clk *pixel_clock;
> +	struct clk *hsm_clock;
> +};
> +

Best regards
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1246024 — Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Multipart message — attachments visible in raw view] — view raw

Stefan Wahren <info@lategoodbye.de> writes:

> Hi Eric,
>
> Am 09.10.2015 um 23:27 schrieb Eric Anholt:
>> This is enough for fbcon and bringing up X using
>> xf86-video-modesetting.  It doesn't support the 3D accelerator or
>> power management yet.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>>
>> v2: Drop FB_HELPER select thanks to Archit's patches.  Do manual init
>>      ordering instead of using the .load hook.  Structure registration
>>      more like tegra's, but still using the typical "component" code.
>>      Drop no-op hooks for atomic_begin and mode_fixup() now that
>>      they're optional.  Drop sentinel in Makefile.  Fix minor style
>>      nits I noticed on another reread.
>>
>> v3: Use the new bcm2835 clk driver to manage pixel/HSM clocks instead
>>      of having a fixed video mode.  Use exynos-style component driver
>>      matching instead of devicetree nodes to list the component driver
>>      instances.  Rename compatibility strings to say bcm2835, and
>>      distinguish pv0/1/2.  Clean up some h/vsync code, and add in
>>      interlaced mode setup.  Fix up probe/bind error paths.  Use
>>      bitops.h macros for vc4_regs.h
>>
>>   drivers/gpu/drm/Kconfig           |   2 +
>>   drivers/gpu/drm/Makefile          |   1 +
>>   drivers/gpu/drm/vc4/Kconfig       |  13 +
>>   drivers/gpu/drm/vc4/Makefile      |  17 +
>>   drivers/gpu/drm/vc4/vc4_bo.c      |  52 +++
>>   drivers/gpu/drm/vc4/vc4_crtc.c    | 675 ++++++++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/vc4/vc4_debugfs.c |  39 +++
>>   drivers/gpu/drm/vc4/vc4_drv.c     | 284 ++++++++++++++++
>>   drivers/gpu/drm/vc4/vc4_drv.h     | 115 +++++++
>>   drivers/gpu/drm/vc4/vc4_hdmi.c    | 588 +++++++++++++++++++++++++++++++++
>>   drivers/gpu/drm/vc4/vc4_hvs.c     | 163 +++++++++
>>   drivers/gpu/drm/vc4/vc4_kms.c     |  54 +++
>>   drivers/gpu/drm/vc4/vc4_plane.c   | 320 ++++++++++++++++++
>>   drivers/gpu/drm/vc4/vc4_regs.h    | 570 ++++++++++++++++++++++++++++++++
>>   14 files changed, 2893 insertions(+)
>>   create mode 100644 drivers/gpu/drm/vc4/Kconfig
>>   create mode 100644 drivers/gpu/drm/vc4/Makefile
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
>>   create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 1a0a8df..c4bf9a1 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
>>   source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>>
>>   source "drivers/gpu/drm/imx/Kconfig"
>> +
>> +source "drivers/gpu/drm/vc4/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 45e7719..0edc9e2 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA)	+= mga/
>>   obj-$(CONFIG_DRM_I810)	+= i810/
>>   obj-$(CONFIG_DRM_I915)  += i915/
>>   obj-$(CONFIG_DRM_MGAG200) += mgag200/
>> +obj-$(CONFIG_DRM_VC4)  += vc4/
>>   obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>>   obj-$(CONFIG_DRM_SIS)   += sis/
>>   obj-$(CONFIG_DRM_SAVAGE)+= savage/
>> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
>> new file mode 100644
>> index 0000000..e810ef7
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/Kconfig
>> @@ -0,0 +1,13 @@
>> +config DRM_VC4
>> +	tristate "Broadcom VC4 Graphics"
>> +	depends on ARCH_BCM2835
>
> depends on (ARCH_BCM2835 || COMPILE_TEST) ?

Done.

>> +	depends on DRM
>> +	select DRM_KMS_HELPER
>> +	select DRM_KMS_CMA_HELPER
>> +	help
>> +	  Choose this option if you have a system that has a Broadcom
>> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
>> +
>> +	  This driver requires that "avoid_warnings=2" be present in
>> +	  the config.txt for the firmware, to keep it from smashing
>> +	  our display setup.
>> + [...]
>> +static void vc4_crtc_disable(struct drm_crtc *crtc)
>> +{
>> +	struct drm_device *dev = crtc->dev;
>> +	struct vc4_dev *vc4 = to_vc4_dev(dev);
>> +	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>> +	u32 chan = vc4_crtc->channel;
>> +
>> +	require_hvs_enabled(dev);
>> +
>> +	CRTC_WRITE(PV_V_CONTROL,
>> +		   CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
>> +	while (CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN)
>> +		cpu_relax();
>> +
>> +	/* Without a wait here, we end up with a black screen. */
>> +	msleep(30);
>
> This looks a little bit strange. First we do a busy loop without any 
> timeout and then a fixed msleep without reason for the exact duration.
>
> Sorry for the possibly dumb questions:
>
> Is it safe to read PV_V_CONTROL exactly after writing to them? No 
> sleeping required?

Correct.  We're waiting for the value to land, so you just read until it
does.

I've pulled in a later change for doing waits with timouts.

> How did you come to the 30 milli seconds?

a bit more than a frame.  The comment was there to document why the
sleep was there.  It looks like in retesting now that it's not required.

>> +  [...]
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> new file mode 100644
>> index 0000000..ae37fec
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -0,0 +1,588 @@
>> +/*
>> + * Copyright (C) 2015 Broadcom
>> + * Copyright (c) 2014 The Linux Foundation. All rights reserved.
>> + * Copyright (C) 2013 Red Hat
>> + * Author: Rob Clark <robdclark@gmail.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along with
>> + * this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +/**
>> + * DOC: VC4 Falcon HDMI module
>> + *
>> + * The HDMI core has a state machine and a PHY.  Most of the unit
>> + * operates off of the HSM clock from CPRMAN.  It also internally uses
>> + * the PLLH_PIX clock for the PHY.
>> + */
>> +
>> +#include "drm_atomic_helper.h"
>> +#include "drm_crtc_helper.h"
>> +#include "drm_edid.h"
>> +#include "linux/clk.h"
>> +#include "linux/component.h"
>
> #include "linux/i2c.h" ?

Done.

[toc] | [prev] | [next] | [standalone]

#1246057 — Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

Am 13.10.2015 um 20:19 schrieb Eric Anholt:
> Stefan Wahren <info@lategoodbye.de> writes:
>
>>> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
>>> new file mode 100644
>>> index 0000000..e810ef7
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/vc4/Kconfig
>>> @@ -0,0 +1,13 @@
>>> +config DRM_VC4
>>> +	tristate "Broadcom VC4 Graphics"
>>> +	depends on ARCH_BCM2835
>>
>> depends on (ARCH_BCM2835 || COMPILE_TEST) ?
>
> Done.

Sorry for the bad suggestion. The parentheses should be necessary.

>
>>> +	depends on DRM
>>> +	select DRM_KMS_HELPER
>>> +	select DRM_KMS_CMA_HELPER
>>> +	help
>>> +	  Choose this option if you have a system that has a Broadcom
>>> +	  VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
>>> +
>>> +	  This driver requires that "avoid_warnings=2" be present in
>>> +	  the config.txt for the firmware, to keep it from smashing
>>> +	  our display setup.
>>> + [...]
>>> +static void vc4_crtc_disable(struct drm_crtc *crtc)
>>> +{
>>> +	struct drm_device *dev = crtc->dev;
>>> +	struct vc4_dev *vc4 = to_vc4_dev(dev);
>>> +	struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
>>> +	u32 chan = vc4_crtc->channel;
>>> +
>>> +	require_hvs_enabled(dev);
>>> +
>>> +	CRTC_WRITE(PV_V_CONTROL,
>>> +		   CRTC_READ(PV_V_CONTROL) & ~PV_VCONTROL_VIDEN);
>>> +	while (CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN)
>>> +		cpu_relax();
>>> +
>>> +	/* Without a wait here, we end up with a black screen. */
>>> +	msleep(30);
>>
>> This looks a little bit strange. First we do a busy loop without any
>> timeout and then a fixed msleep without reason for the exact duration.
>>
>> Sorry for the possibly dumb questions:
>>
>> Is it safe to read PV_V_CONTROL exactly after writing to them? No
>> sleeping required?
>
> Correct.  We're waiting for the value to land, so you just read until it
> does.

The reason for my question was the possibility that writing to 
PV_V_CONTROL could take some time and reading directly after writing 
could return the old value. In such a case the busy loop has no effect.

But if it is not the case here everything is fine :-)

>
> I've pulled in a later change for doing waits with timouts.
>
>> How did you come to the 30 milli seconds?
>
> a bit more than a frame.  The comment was there to document why the
> sleep was there.  It looks like in retesting now that it's not required.

Sounds better

Regards
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1246060 — Re: [PATCH v3 3/7] drm/vc4: Add KMS support for Raspberry Pi.

Am 13.10.2015 um 20:50 schrieb Stefan Wahren:
> Am 13.10.2015 um 20:19 schrieb Eric Anholt:
>> Stefan Wahren <info@lategoodbye.de> writes:
>>
>>>> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
>>>> new file mode 100644
>>>> index 0000000..e810ef7
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/vc4/Kconfig
>>>> @@ -0,0 +1,13 @@
>>>> +config DRM_VC4
>>>> +    tristate "Broadcom VC4 Graphics"
>>>> +    depends on ARCH_BCM2835
>>>
>>> depends on (ARCH_BCM2835 || COMPILE_TEST) ?
>>
>> Done.
>
> Sorry for the bad suggestion. The parentheses should be necessary.

The parentheses aren't necessary.

Sorry for the noise

Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web