RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
> -Original Message-
> From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
> Sent: Tuesday, June 18, 2013 9:50 PM
> To: linux-samsung-...@vger.kernel.org;
devicetree-disc...@lists.ozlabs.org;
> dri-devel@lists.freedesktop.org
> Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
> jo...@samsung.com; r.sh.o...@gmail.com; Rahul Sharma
> Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
>
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
Hi Rahul,
Could you separate this patch into two patches, driver side and document
side, and the below patch also?
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
Thanks,
Inki Dae
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
> Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
> Documentation/devicetree/bindings/video/exynos_mixer.txt |7 +--
> drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
> drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> drivers/gpu/drm/exynos/exynos_mixer.c | 12
++--
> 8 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required properties:
> Example:
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mi
RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Wednesday, June 19, 2013 4:06 PM
> To: 'Rahul Sharma'; 'linux-samsung-...@vger.kernel.org'; 'devicetree-
> disc...@lists.ozlabs.org'; 'dri-devel@lists.freedesktop.org'
> Cc: 'kgene@samsung.com'; 'sw0312@samsung.com';
'jo...@samsung.com';
> 'r.sh.o...@gmail.com'
> Subject: RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
>
>
>
> > -Original Message-
> > From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
> > Sent: Tuesday, June 18, 2013 9:50 PM
> > To: linux-samsung-...@vger.kernel.org; devicetree-
> disc...@lists.ozlabs.org;
> > dri-devel@lists.freedesktop.org
> > Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
> > jo...@samsung.com; r.sh.o...@gmail.com; Rahul Sharma
> > Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> > subsystem
> >
> > This patch renames the combatible strings for hdmi, mixer, ddc
> > and hdmiphy. It follows the convention of using compatible string
> > which represent the SoC in which the IP was added for the first
> > time.
> >
>
> Hi Rahul,
>
> Could you separate this patch into two patches, driver side and document
> side, and the below patch also?
> [PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
>
Sorry, just will merge them.
To devicetree maintainers, please give me ACK.
Thanks,
Inki Dae
> Thanks,
> Inki Dae
>
> > Signed-off-by: Rahul Sharma
> > ---
> > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
--
> > Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> > Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6
--
> > Documentation/devicetree/bindings/video/exynos_mixer.txt |7
+--
> > drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> > drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
> > drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> > drivers/gpu/drm/exynos/exynos_mixer.c | 12
++-
> -
> > 8 files changed, 26 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > index 589edee..2ac01ca 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > @@ -1,7 +1,9 @@
> > Device-Tree bindings for drm hdmi driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmi".
> > +- compatible: value should be one among the following:
> > + 1) "samsung,exynos4210-hdmi"
> > + 2) "samsung,exynos4212-hdmi"
> > - reg: physical base address of the hdmi and length of memory mapped
> > region.
> > - interrupts: interrupt number to the cpu.
> > @@ -15,7 +17,7 @@ Required properties:
> > Example:
> >
> > hdmi {
> > - compatible = "samsung,exynos5-hdmi";
> > + compatible = "samsung,exynos4212-hdmi";
> > reg = <0x1453 0x10>;
> > interrupts = <0 95 0>;
> > hpd-gpio = <&gpx3 7 0xf 1 3>;
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > index fa166d9..c1bd2ea 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > @@ -1,12 +1,12 @@
> > Device-Tree bindings for hdmiddc driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmiddc".
> > +- compatible: value should be "samsung,exynos4210-hdmiddc".
> > - reg: I2C address of the hdmiddc device.
> >
> > Example:
> >
> > hdmiddc {
> > - compatible = "samsung,exynos5-hdmiddc";
> > + compatible = "samsung,exynos4210-hdmiddc";
> > reg = <0x50>;
> > };
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > index 858f4f9..e59d793 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > @@ -1,12 +1,14 @@
> > Device-Tree bindings for hdmiphy driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmiphy".
> > +- compatible: value should be
> > + 1) "samsung,exynos4210-hdmiphy".
> > + 2) "samsung,exynos4212-hdmiphy".
> > - reg: I2C address of the hdmiphy device.
> >
> > Example:
> >
> > hdmiphy {
> > - compatible = "samsung,exynos5-hdmiphy";
> > + compatible = "samsung,exynos4210-hdmiphy";
> > reg = <0x38>;
> > };
> > diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> > b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> > index 9b2ea03..a8b0
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #72 from Marc Dietrich --- yup, heaven works, kronos test suite reports doesn't crash anymore, but fail (misrenders) on sin/cos as expected. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi Rahul,
On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
>2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
> ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
Sorry, but it's a NAK from me.
DeviceTree bindings are considered an ABI. This is to allow older dtbs to
work with new kernels.
If you just change the binding this way, you break all the existing users
of this compatible value.
In addition you are doing it in a way that breaks bisection:
- patch 1/4 breaks existing in-tree users of current compatible values,
- after patch 2 and 3 it is still broken,
- and eventually all in-tree users are fixed by patch 4 (but you can't
fix out-of-tree users).
Please do it without changing existing compatible values. Even if they are
misleading, this is all can be described in the documentation - just list
SoCs that can be used with each compatible value there.
Best regards,
Tomasz
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt index
> fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt index
> 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt index
> 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required proper
Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> Hi Rahul,
>
> On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> > This patch renames the combatible strings for hdmi, mixer, ddc
> > and hdmiphy. It follows the convention of using compatible string
> > which represent the SoC in which the IP was added for the first
> > time.
> >
> > Signed-off-by: Rahul Sharma
> > ---
> > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
> >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> > +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
> > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> > 589edee..2ac01ca 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > @@ -1,7 +1,9 @@
> > Device-Tree bindings for drm hdmi driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmi".
> > +- compatible: value should be one among the following:
> > + 1) "samsung,exynos4210-hdmi"
> > + 2) "samsung,exynos4212-hdmi"
> > - reg: physical base address of the hdmi and length of memory mapped
> > region.
> > - interrupts: interrupt number to the cpu.
> > @@ -15,7 +17,7 @@ Required properties:
> > Example:
> >
> > hdmi {
> > - compatible = "samsung,exynos5-hdmi";
> > + compatible = "samsung,exynos4212-hdmi";
>
> Sorry, but it's a NAK from me.
>
> DeviceTree bindings are considered an ABI. This is to allow older dtbs to
> work with new kernels.
>
> If you just change the binding this way, you break all the existing users
> of this compatible value.
>
> In addition you are doing it in a way that breaks bisection:
> - patch 1/4 breaks existing in-tree users of current compatible values,
> - after patch 2 and 3 it is still broken,
> - and eventually all in-tree users are fixed by patch 4 (but you can't
> fix out-of-tree users).
>
> Please do it without changing existing compatible values. Even if they are
> misleading, this is all can be described in the documentation - just list
> SoCs that can be used with each compatible value there.
>
Or you could just introduce the new compatible value and make all
in-tree users use this, but keep the old values around and still accept
them in the drivers. This way you get the goodness of the cleaner new
symbols without breaking existing users. Just mark the old values as
deprecated in the documentation, so no new devicetree usees them.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> Behalf Of Lucas Stach
> Sent: Wednesday, June 19, 2013 4:59 PM
> To: Tomasz Figa
> Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
> sw0312@samsung.com; jo...@samsung.com;
dri-devel@lists.freedesktop.org;
> linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
> s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
>
> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> > Hi Rahul,
> >
> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> > > This patch renames the combatible strings for hdmi, mixer, ddc
> > > and hdmiphy. It follows the convention of using compatible string
> > > which represent the SoC in which the IP was added for the first
> > > time.
> > >
> > > Signed-off-by: Rahul Sharma
> > > ---
> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
|
> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> > > 589edee..2ac01ca 100644
> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > @@ -1,7 +1,9 @@
> > > Device-Tree bindings for drm hdmi driver
> > >
> > > Required properties:
> > > -- compatible: value should be "samsung,exynos5-hdmi".
> > > +- compatible: value should be one among the following:
> > > + 1) "samsung,exynos4210-hdmi"
> > > + 2) "samsung,exynos4212-hdmi"
> > > - reg: physical base address of the hdmi and length of memory mapped
> > > region.
> > > - interrupts: interrupt number to the cpu.
> > > @@ -15,7 +17,7 @@ Required properties:
> > > Example:
> > >
> > > hdmi {
> > > - compatible = "samsung,exynos5-hdmi";
> > > + compatible = "samsung,exynos4212-hdmi";
> >
> > Sorry, but it's a NAK from me.
> >
> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
> to
> > work with new kernels.
> >
> > If you just change the binding this way, you break all the existing
> users
> > of this compatible value.
> >
> > In addition you are doing it in a way that breaks bisection:
> > - patch 1/4 breaks existing in-tree users of current compatible values,
> > - after patch 2 and 3 it is still broken,
> > - and eventually all in-tree users are fixed by patch 4 (but you can't
> > fix out-of-tree users).
> >
> > Please do it without changing existing compatible values. Even if they
> are
> > misleading, this is all can be described in the documentation - just
> list
> > SoCs that can be used with each compatible value there.
> >
>
> Or you could just introduce the new compatible value and make all
> in-tree users use this, but keep the old values around and still accept
> them in the drivers. This way you get the goodness of the cleaner new
> symbols without breaking existing users. Just mark the old values as
> deprecated in the documentation, so no new devicetree usees them.
>
That's a good idea. We really need to mitigate such misleading somehow or
other.
Thanks,
Inki Dae
> Regards,
> Lucas
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); ... And the below can be used as access types: DMA_BUF_ACCESS_R - CPU will access a buffer for read. DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94 https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.
Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi All,
On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
>> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
>> Behalf Of Lucas Stach
>> Sent: Wednesday, June 19, 2013 4:59 PM
>> To: Tomasz Figa
>> Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
>> sw0312@samsung.com; jo...@samsung.com;
> dri-devel@lists.freedesktop.org;
>> linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
>> s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
>> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
>> subsystem
>>
>> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
>> > Hi Rahul,
>> >
>> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
>> > > This patch renames the combatible strings for hdmi, mixer, ddc
>> > > and hdmiphy. It follows the convention of using compatible string
>> > > which represent the SoC in which the IP was added for the first
>> > > time.
>> > >
>> > > Signed-off-by: Rahul Sharma
>> > > ---
>> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
>> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
>> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
>> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
>> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
> |
>> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
>> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
>> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
>> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
>> > > 589edee..2ac01ca 100644
>> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > @@ -1,7 +1,9 @@
>> > > Device-Tree bindings for drm hdmi driver
>> > >
>> > > Required properties:
>> > > -- compatible: value should be "samsung,exynos5-hdmi".
>> > > +- compatible: value should be one among the following:
>> > > + 1) "samsung,exynos4210-hdmi"
>> > > + 2) "samsung,exynos4212-hdmi"
>> > > - reg: physical base address of the hdmi and length of memory mapped
>> > > region.
>> > > - interrupts: interrupt number to the cpu.
>> > > @@ -15,7 +17,7 @@ Required properties:
>> > > Example:
>> > >
>> > > hdmi {
>> > > - compatible = "samsung,exynos5-hdmi";
>> > > + compatible = "samsung,exynos4212-hdmi";
>> >
>> > Sorry, but it's a NAK from me.
>> >
>> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
>> to
>> > work with new kernels.
>> >
>> > If you just change the binding this way, you break all the existing
>> users
>> > of this compatible value.
>> >
>> > In addition you are doing it in a way that breaks bisection:
>> > - patch 1/4 breaks existing in-tree users of current compatible values,
>> > - after patch 2 and 3 it is still broken,
>> > - and eventually all in-tree users are fixed by patch 4 (but you can't
>> > fix out-of-tree users).
>> >
@Tomasz, I understand your point but how is it possible to change
compatible types in driver as well as in dtbs by not breaking either of them
other then putting changes in a single patch. I ensured that hdmi stuff is
intact with whole series merged in either tree (drm or arch). Please suggest
a better way.
The Only existing user is Exynos5250, which is modified in the same patch
set.
>> > Please do it without changing existing compatible values. Even if they
>> are
>> > misleading, this is all can be described in the documentation - just
>> list
>> > SoCs that can be used with each compatible value there.
>> >
>>
>> Or you could just introduce the new compatible value and make all
>> in-tree users use this, but keep the old values around and still accept
>> them in the drivers. This way you get the goodness of the cleaner new
>> symbols without breaking existing users. Just mark the old values as
>> deprecated in the documentation, so no new devicetree usees them.
>>
I agree, above is a decent approach, but in this case we have only one
user for this compatible type including in flight patches which I have
modified along.
If it seems better to keep old compatible type (deprecated), it is fine
with me.
>
> That's a good idea. We really need to mitigate such misleading somehow or
> other.
Please sugggest me how to proceed.
regards,
Rahul Sharma.
>
> Thanks,
> Inki Dae
>
>> Regards,
>> Lucas
>> --
>> Pengutronix e.K. | Lucas Stach |
>> Industrial Linux Solutions | http://www.pengutronix.de/ |
>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi Rahul,
On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
> Hi All,
>
> On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae wrote:
> >> -Original Message-
> >> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
> >> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
> >> Behalf Of Lucas Stach
> >> Sent: Wednesday, June 19, 2013 4:59 PM
> >> To: Tomasz Figa
> >> Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
> >> sw0312@samsung.com; jo...@samsung.com;
> >
> > dri-devel@lists.freedesktop.org;
> >
> >> linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
> >> s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
> >> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> >> subsystem
> >>
> >> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> >> > Hi Rahul,
> >> >
> >> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> >> > > This patch renames the combatible strings for hdmi, mixer, ddc
> >> > > and hdmiphy. It follows the convention of using compatible string
> >> > > which represent the SoC in which the IP was added for the first
> >> > > time.
> >> > >
> >> > > Signed-off-by: Rahul Sharma
> >> > > ---
> >> > >
> >> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> >> > >
> >> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> >> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> >> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> >> > >
> >> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
> >> > >
> >> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> >> > >
> >> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|
> >> > > 4
> >> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c |
> >> > > 12
> >> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> >> > >
> >> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> >> > > 589edee..2ac01ca 100644
> >> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > @@ -1,7 +1,9 @@
> >> > >
> >> > > Device-Tree bindings for drm hdmi driver
> >> > >
> >> > > Required properties:
> >> > > -- compatible: value should be "samsung,exynos5-hdmi".
> >> > > +- compatible: value should be one among the following:
> >> > > + 1) "samsung,exynos4210-hdmi"
> >> > > + 2) "samsung,exynos4212-hdmi"
> >> > >
> >> > > - reg: physical base address of the hdmi and length of memory mapped
> >> > >
> >> > > region.
> >> > >
> >> > > - interrupts: interrupt number to the cpu.
> >> > >
> >> > > @@ -15,7 +17,7 @@ Required properties:
> >> > > Example:
> >> > > hdmi {
> >> > >
> >> > > - compatible = "samsung,exynos5-hdmi";
> >> > > + compatible = "samsung,exynos4212-hdmi";
> >> >
> >> > Sorry, but it's a NAK from me.
> >> >
> >> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
> >>
> >> to
> >>
> >> > work with new kernels.
> >> >
> >> > If you just change the binding this way, you break all the existing
> >>
> >> users
> >>
> >> > of this compatible value.
> >> >
> >> > In addition you are doing it in a way that breaks bisection:
> >> > - patch 1/4 breaks existing in-tree users of current compatible
> >> > values,
> >> > - after patch 2 and 3 it is still broken,
> >> > - and eventually all in-tree users are fixed by patch 4 (but you can't
> >> >
> >> > fix out-of-tree users).
>
> @Tomasz, I understand your point but how is it possible to change
> compatible types in driver as well as in dtbs by not breaking either of them
> other then putting changes in a single patch.
It's very easy. (Let's forget about the fact that DT bindings are an ABI
temporarily) You can simply add new compatible values to the driver in first
patch, then modify dts files in second one and then remove old compatibles
values from the driver in third patch. (Now we remember about DT being ABI
again.)
> I ensured that hdmi stuff is
> intact with whole series merged in either tree (drm or arch). Please
> suggest a better way.
>
> The Only existing user is Exynos5250, which is modified in the same patch
> set.
This is not true. You have modified only the existing _in_ _tree_ users.
Keep in mind that device tree is not a part of the kernel. It is currently
located in the same tree, but it is _not_ a part of the kernel.
Now think about existing boards (like exynos5250-snow) that have a dtb built
from older dts sources stored in their flash memory. You need to maintain
compatibilty with this old dtb in new kernels as well.
> >> > Please do it without changing existing compatible values. Even if they
> >>
> >> are
> >>
> >> > misleading, this i
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > -Original Message- > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > Sent: Tuesday, June 18, 2013 6:47 PM > > To: Inki Dae > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > ker...@lists.infradead.org; linux-me...@vger.kernel.org > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > > framework > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > [...] > > > > > > > a display device driver. It shouldn't be used within a single driver > > > > as a means of passing buffers between userspace and kernel space. > > > > > > What I try to do is not really such ugly thing. What I try to do is to > > > notify that, when CPU tries to access a buffer , to kernel side through > > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > > > Thanks, > > > Inki Dae > > > > > The most basic question about why you are trying to implement this sort > > of thing in the dma_buf framework still stands. > > > > Once you imported a dma_buf into your DRM driver it's a GEM object and > > you can and should use the native DRM ioctls to prepare/end a CPU access > > to this BO. Then internally to your driver you can use the dma_buf > > reservation/fence stuff to provide the necessary cross-device sync. > > > > I don't really want that is used only for DRM drivers. We really need > it for all other DMA devices; i.e., v4l2 based drivers. That is what I > try to do. And my approach uses reservation to use dma-buf resources > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > driver for why we need dma fence stuff, and how we can use it if > needed. > Still I don't see the point why you need syncpoints above dma-buf. In both the DRM and the V4L2 world we have defined points in the API where a buffer is allowed to change domain from device to CPU and vice versa. In DRM if you want to access a buffer with the CPU you do a cpu_prepare. The buffer changes back to GPU domain once you do the execbuf validation, queue a pageflip to the buffer or similar things. In V4L2 the syncpoints for cache operations are the queue/dequeue API entry points. Those are also the exact points to synchronize with other hardware thus using dma-buf reserve/fence. In all this I can't see any need for a new syncpoint primitive slapped on top of dma-buf. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
On Wed, Jun 19, 2013 at 3:20 PM, Tomasz Figa wrote:
> Hi Rahul,
>
> On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
>> Hi All,
>>
>> On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae wrote:
>> >> -Original Message-
>> >> From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
>> >> [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
>> >> Behalf Of Lucas Stach
>> >> Sent: Wednesday, June 19, 2013 4:59 PM
>> >> To: Tomasz Figa
>> >> Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
>> >> sw0312@samsung.com; jo...@samsung.com;
>> >
>> > dri-devel@lists.freedesktop.org;
>> >
>> >> linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
>> >> s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
>> >> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
>> >> subsystem
>> >>
>> >> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
>> >> > Hi Rahul,
>> >> >
>> >> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
>> >> > > This patch renames the combatible strings for hdmi, mixer, ddc
>> >> > > and hdmiphy. It follows the convention of using compatible string
>> >> > > which represent the SoC in which the IP was added for the first
>> >> > > time.
>> >> > >
>> >> > > Signed-off-by: Rahul Sharma
>> >> > > ---
>> >> > >
>> >> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
>> >> > >
>> >> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
>> >> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
>> >> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
>> >> > >
>> >> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
>> >> > >
>> >> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
>> >> > >
>> >> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|
>> >> > > 4
>> >> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c |
>> >> > > 12
>> >> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>> >> > >
>> >> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
>> >> > > 589edee..2ac01ca 100644
>> >> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > @@ -1,7 +1,9 @@
>> >> > >
>> >> > > Device-Tree bindings for drm hdmi driver
>> >> > >
>> >> > > Required properties:
>> >> > > -- compatible: value should be "samsung,exynos5-hdmi".
>> >> > > +- compatible: value should be one among the following:
>> >> > > + 1) "samsung,exynos4210-hdmi"
>> >> > > + 2) "samsung,exynos4212-hdmi"
>> >> > >
>> >> > > - reg: physical base address of the hdmi and length of memory mapped
>> >> > >
>> >> > > region.
>> >> > >
>> >> > > - interrupts: interrupt number to the cpu.
>> >> > >
>> >> > > @@ -15,7 +17,7 @@ Required properties:
>> >> > > Example:
>> >> > > hdmi {
>> >> > >
>> >> > > - compatible = "samsung,exynos5-hdmi";
>> >> > > + compatible = "samsung,exynos4212-hdmi";
>> >> >
>> >> > Sorry, but it's a NAK from me.
>> >> >
>> >> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
>> >>
>> >> to
>> >>
>> >> > work with new kernels.
>> >> >
>> >> > If you just change the binding this way, you break all the existing
>> >>
>> >> users
>> >>
>> >> > of this compatible value.
>> >> >
>> >> > In addition you are doing it in a way that breaks bisection:
>> >> > - patch 1/4 breaks existing in-tree users of current compatible
>> >> > values,
>> >> > - after patch 2 and 3 it is still broken,
>> >> > - and eventually all in-tree users are fixed by patch 4 (but you can't
>> >> >
>> >> > fix out-of-tree users).
>>
>> @Tomasz, I understand your point but how is it possible to change
>> compatible types in driver as well as in dtbs by not breaking either of them
>> other then putting changes in a single patch.
>
> It's very easy. (Let's forget about the fact that DT bindings are an ABI
> temporarily) You can simply add new compatible values to the driver in first
> patch, then modify dts files in second one and then remove old compatibles
> values from the driver in third patch. (Now we remember about DT being ABI
> again.)
>
>> I ensured that hdmi stuff is
>> intact with whole series merged in either tree (drm or arch). Please
>> suggest a better way.
>>
>> The Only existing user is Exynos5250, which is modified in the same patch
>> set.
>
> This is not true. You have modified only the existing _in_ _tree_ users.
>
> Keep in mind that device tree is not a part of the kernel. It is currently
> located in the same tree, but it is _not_ a part of the kernel.
>
> Now think about existing boards (like exynos5250-snow) that have a dtb built
> from older dts sources stored in their flash memory. You need to maintain
> compatibilty with this old dtb in
RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Lucas Stach [mailto:l.st...@pengutronix.de] > Sent: Wednesday, June 19, 2013 7:22 PM > To: Inki Dae > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > ker...@lists.infradead.org; linux-me...@vger.kernel.org > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > > > -Original Message- > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > Sent: Tuesday, June 18, 2013 6:47 PM > > > To: Inki Dae > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > > ker...@lists.infradead.org; linux-me...@vger.kernel.org > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > synchronization > > > framework > > > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > > [...] > > > > > > > > > a display device driver. It shouldn't be used within a single > driver > > > > > as a means of passing buffers between userspace and kernel space. > > > > > > > > What I try to do is not really such ugly thing. What I try to do is > to > > > > notify that, when CPU tries to access a buffer , to kernel side > through > > > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > > > > > Thanks, > > > > Inki Dae > > > > > > > The most basic question about why you are trying to implement this > sort > > > of thing in the dma_buf framework still stands. > > > > > > Once you imported a dma_buf into your DRM driver it's a GEM object and > > > you can and should use the native DRM ioctls to prepare/end a CPU > access > > > to this BO. Then internally to your driver you can use the dma_buf > > > reservation/fence stuff to provide the necessary cross-device sync. > > > > > > > I don't really want that is used only for DRM drivers. We really need > > it for all other DMA devices; i.e., v4l2 based drivers. That is what I > > try to do. And my approach uses reservation to use dma-buf resources > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > > driver for why we need dma fence stuff, and how we can use it if > > needed. > > > > Still I don't see the point why you need syncpoints above dma-buf. In > both the DRM and the V4L2 world we have defined points in the API where > a buffer is allowed to change domain from device to CPU and vice versa. > > In DRM if you want to access a buffer with the CPU you do a cpu_prepare. > The buffer changes back to GPU domain once you do the execbuf > validation, queue a pageflip to the buffer or similar things. > > In V4L2 the syncpoints for cache operations are the queue/dequeue API > entry points. Those are also the exact points to synchronize with other > hardware thus using dma-buf reserve/fence. If so, what if we want to access a buffer with the CPU _in V4L2_? We should open a drm device node, and then do a cpu_prepare? Thanks, Inki Dae > > In all this I can't see any need for a new syncpoint primitive slapped > on top of dma-buf. > > Regards, > Lucas > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/shmobile: Enable compilation on all ARM platforms
This is required to support multi-arch kernels. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/shmobile/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig index 7e7d52b..62905b4 100644 --- a/drivers/gpu/drm/shmobile/Kconfig +++ b/drivers/gpu/drm/shmobile/Kconfig @@ -1,6 +1,6 @@ config DRM_SHMOBILE tristate "DRM Support for SH Mobile" - depends on DRM && (SUPERH || ARCH_SHMOBILE) + depends on DRM && (ARM || SUPERH) select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Improve manual IRQ installation documentation
Signed-off-by: Laurent Pinchart --- Documentation/DocBook/drm.tmpl | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index f9df3b8..738b727 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -186,11 +186,12 @@ DRIVER_HAVE_IRQDRIVER_IRQ_SHARED - DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. The - DRM core will automatically register an interrupt handler when the - flag is set. DRIVER_IRQ_SHARED indicates whether the device & - handler support shared IRQs (note that this is required of PCI - drivers). + DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler + managed by the DRM Core. The core will support simple IRQ handler + installation when the flag is set. The installation process is + described in . + DRIVER_IRQ_SHARED indicates whether the device & handler + support shared IRQs (note that this is required of PCI drivers). @@ -344,7 +345,8 @@ char *date; The DRM core tries to facilitate IRQ handler registration and unregistration by providing drm_irq_install and drm_irq_uninstall functions. Those functions only - support a single interrupt per device. + support a single interrupt per device, devices that use more than one + IRQs need to be handled manually. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae: > > > -Original Message- > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > Sent: Wednesday, June 19, 2013 7:22 PM > > To: Inki Dae > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > ker...@lists.infradead.org; linux-me...@vger.kernel.org > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > > framework > > > > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > > > > > -Original Message- > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > > Sent: Tuesday, June 18, 2013 6:47 PM > > > > To: Inki Dae > > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > > > ker...@lists.infradead.org; linux-me...@vger.kernel.org > > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > > synchronization > > > > framework > > > > > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > > > [...] > > > > > > > > > > > a display device driver. It shouldn't be used within a single > > driver > > > > > > as a means of passing buffers between userspace and kernel space. > > > > > > > > > > What I try to do is not really such ugly thing. What I try to do is > > to > > > > > notify that, when CPU tries to access a buffer , to kernel side > > through > > > > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > > > > > > > Thanks, > > > > > Inki Dae > > > > > > > > > The most basic question about why you are trying to implement this > > sort > > > > of thing in the dma_buf framework still stands. > > > > > > > > Once you imported a dma_buf into your DRM driver it's a GEM object and > > > > you can and should use the native DRM ioctls to prepare/end a CPU > > access > > > > to this BO. Then internally to your driver you can use the dma_buf > > > > reservation/fence stuff to provide the necessary cross-device sync. > > > > > > > > > > I don't really want that is used only for DRM drivers. We really need > > > it for all other DMA devices; i.e., v4l2 based drivers. That is what I > > > try to do. And my approach uses reservation to use dma-buf resources > > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > > > driver for why we need dma fence stuff, and how we can use it if > > > needed. > > > > > > > Still I don't see the point why you need syncpoints above dma-buf. In > > both the DRM and the V4L2 world we have defined points in the API where > > a buffer is allowed to change domain from device to CPU and vice versa. > > > > In DRM if you want to access a buffer with the CPU you do a cpu_prepare. > > The buffer changes back to GPU domain once you do the execbuf > > validation, queue a pageflip to the buffer or similar things. > > > > In V4L2 the syncpoints for cache operations are the queue/dequeue API > > entry points. Those are also the exact points to synchronize with other > > hardware thus using dma-buf reserve/fence. > > > If so, what if we want to access a buffer with the CPU _in V4L2_? We > should open a drm device node, and then do a cpu_prepare? > Not at all. As I said the syncpoints are the queue/dequeue operations. When dequeueing a buffer you are explicitly dragging the buffer domain back from device into userspace and thus CPU domain. If you are operating on an mmap of a V4L2 processed buffer it's either before or after it got processed by the hardware and therefore all DMA operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls. That is where cache operations and synchronization should happen. The V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it back into CPU domain while there is still DMA ongoing. Equally the queue ioctrl should make sure caches are properly written back to memory. The results of reading/writing to the mmap of a V4L2 buffer while it is enqueued to the hardware is simply undefined and there is nothing suggesting that this is a valid usecase. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: update lockup tracking when scheduling in empty ring
From: Jerome Glisse
There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.
Signed-off-by: Jerome Glisse
Tested-by: Andy Lutomirski
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index e17faa7..82434018 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct
radeon_ring *ring, unsi
return -ENOMEM;
/* Align requested size with padding so unlock_commit can
* pad safely */
+ radeon_ring_free_size(rdev, ring);
+ if (ring->ring_free_dw == (ring->ring_size / 4)) {
+ /* This is an empty ring update lockup info to avoid
+* false positive.
+*/
+ radeon_ring_lockup_update(ring);
+ }
ndw = (ndw + ring->align_mask) & ~ring->align_mask;
while (ndw > (ring->ring_free_dw - 1)) {
radeon_ring_free_size(rdev, ring);
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.
https://bugzilla.kernel.org/show_bug.cgi?id=59761 --- Comment #2 from t3s...@mail.ru 2013-06-19 14:36:31 --- Quite hard/time consuming for me at this point. But if no other options left, I probably can try since this bug is quite annoying. Right now I know that MESA 9.0.x has been working perfectly with that HD5770. But MESA 9.1 and up (9.2 git, etc) are broken. This also seems to produce some visually visible artifacts on textured objects in mentioned "Ryzom" game. Say, "metallic" objects However as for kernel itself - the problem is that kernel detects lock-up but then EPIC FAILs when trying to reset GPU. I bet there should be no "BUG: unable to handle kernel paging request" at very least. Then, kernel never manages to recover from this condition. Neither old 3.8 kernel, nor recent changed GPU reset code from 3.9/3.10 would work. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/shmobile: Drop usage of removed drm_plane enabled field
The enabled field has been removed from struct drm_plane. Don't use it
in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This fixes a compilation error in drm-next. I will send a pull request for the
shmob-drm patches by the end of the week.
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
index 6898f6f..060ae03 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
@@ -166,7 +166,7 @@ void shmob_drm_plane_setup(struct drm_plane *plane)
{
struct shmob_drm_plane *splane = to_shmob_plane(plane);
- if (plane->fb == NULL || !plane->enabled)
+ if (plane->fb == NULL)
return;
__shmob_drm_plane_setup(splane, plane->fb);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: update lockup tracking when scheduling in empty ring
Am 19.06.2013 16:02, schrieb j.gli...@gmail.com:
From: Jerome Glisse
There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.
Signed-off-by: Jerome Glisse
Tested-by: Andy Lutomirski
Cc: sta...@vger.kernel.org
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index e17faa7..82434018 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct
radeon_ring *ring, unsi
return -ENOMEM;
/* Align requested size with padding so unlock_commit can
* pad safely */
+ radeon_ring_free_size(rdev, ring);
+ if (ring->ring_free_dw == (ring->ring_size / 4)) {
+ /* This is an empty ring update lockup info to avoid
+* false positive.
+*/
+ radeon_ring_lockup_update(ring);
+ }
ndw = (ndw + ring->align_mask) & ~ring->align_mask;
while (ndw > (ring->ring_free_dw - 1)) {
radeon_ring_free_size(rdev, ring);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
2013/6/19 Lucas Stach > Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae: > > > > > -Original Message- > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > Sent: Wednesday, June 19, 2013 7:22 PM > > > To: Inki Dae > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > > ker...@lists.infradead.org; linux-me...@vger.kernel.org > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > synchronization > > > framework > > > > > > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > > > > > > > -Original Message- > > > > > From: Lucas Stach [mailto:l.st...@pengutronix.de] > > > > > Sent: Tuesday, June 18, 2013 6:47 PM > > > > > To: Inki Dae > > > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; > 'DRI > > > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > > > > ker...@lists.infradead.org; linux-me...@vger.kernel.org > > > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > > > synchronization > > > > > framework > > > > > > > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > > > > [...] > > > > > > > > > > > > > a display device driver. It shouldn't be used within a single > > > driver > > > > > > > as a means of passing buffers between userspace and kernel > space. > > > > > > > > > > > > What I try to do is not really such ugly thing. What I try to do > is > > > to > > > > > > notify that, when CPU tries to access a buffer , to kernel side > > > through > > > > > > dmabuf interface. So it's not really to send the buffer to > kernel. > > > > > > > > > > > > Thanks, > > > > > > Inki Dae > > > > > > > > > > > The most basic question about why you are trying to implement this > > > sort > > > > > of thing in the dma_buf framework still stands. > > > > > > > > > > Once you imported a dma_buf into your DRM driver it's a GEM object > and > > > > > you can and should use the native DRM ioctls to prepare/end a CPU > > > access > > > > > to this BO. Then internally to your driver you can use the dma_buf > > > > > reservation/fence stuff to provide the necessary cross-device sync. > > > > > > > > > > > > > I don't really want that is used only for DRM drivers. We really need > > > > it for all other DMA devices; i.e., v4l2 based drivers. That is what > I > > > > try to do. And my approach uses reservation to use dma-buf resources > > > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > > > > driver for why we need dma fence stuff, and how we can use it if > > > > needed. > > > > > > > > > > Still I don't see the point why you need syncpoints above dma-buf. In > > > both the DRM and the V4L2 world we have defined points in the API where > > > a buffer is allowed to change domain from device to CPU and vice versa. > > > > > > In DRM if you want to access a buffer with the CPU you do a > cpu_prepare. > > > The buffer changes back to GPU domain once you do the execbuf > > > validation, queue a pageflip to the buffer or similar things. > > > > > > In V4L2 the syncpoints for cache operations are the queue/dequeue API > > > entry points. Those are also the exact points to synchronize with other > > > hardware thus using dma-buf reserve/fence. > > > > > > If so, what if we want to access a buffer with the CPU _in V4L2_? We > > should open a drm device node, and then do a cpu_prepare? > > > Not at all. As I said the syncpoints are the queue/dequeue operations. > When dequeueing a buffer you are explicitly dragging the buffer domain > back from device into userspace and thus CPU domain. > > If you are operating on an mmap of a V4L2 processed buffer it's either > before or after it got processed by the hardware and therefore all DMA > operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls. > That is where cache operations and synchronization should happen. The > V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it > back into CPU domain while there is still DMA ongoing. Equally the queue > ioctrl should make sure caches are properly written back to memory. The > results of reading/writing to the mmap of a V4L2 buffer while it is > enqueued to the hardware is simply undefined and there is nothing > suggesting that this is a valid usecase. Thanks to comments. However, that's not definitely my point, and you just say the conventional way. My point is to more enhance the conventional way. The conventional way is (sorry but I'm not really a good painter) : CPU -> DMA, ioctl(qbuf command) ioctl(streamon) | | | | qbuf <- syncpoint start streaming <- dma access DMA accesses a queued buffer with start streaming if source and destination queues are ready. And DMA -> CPU, ioctl(dqbuf command) | | dqb
Re: [PATCH 1/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.
On 13-06-17 09:19 AM, Julia Lemire wrote:
+static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode *
mode,
+ int bits_per_pixel)
+{
+ uint64_t active_area, total_area, pixels_per_second;
+ uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
+
+ if(!mode->htotal || !mode->vtotal || !mode->clock)
+ return 0;
+
+ active_area = mode->hdisplay * mode->vdisplay;
+ total_area = mode->htotal * mode->vtotal;
+ pixels_per_second = active_area * mode->clock * 1000 / total_area;
+ return (uint32_t)(pixels_per_second * bytes_per_pixel * 100 / (1024));
+}
I found a bug while testing this on a 32-bit machine linked to the
64-bit division. Sorry.
--
Julia Lemire Jr. Eng./Ing.
Software Designer
Matrox Graphics Inc.
Phone : 514 822-6000 x7010
Email :julia.lem...@matrox.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #10 from Jerome Glisse --- What is the motherboard and cpu reference ? AMD A4-3400 ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #11 from wojtek --- Motherboard: Gigabyte Technology Co., Ltd. GA-A75M-UD2H/GA-A75M-UD2H, BIOS F5 11/03/2011 CPU: AMD A4-3400 APU with Radeon(tm) HD Graphics (fam: 12, model: 01, stepping: 00) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
Thanks Mr. Kim,
I will post v4 with aforesaid change.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim wrote:
> On 06/19/13 22:50, Kukjin Kim wrote:
>>
>> On 06/19/13 21:51, Rahul Sharma wrote:
>>>
>>> This patch renames the combatible strings for hdmi, mixer, ddc
>>> and hdmiphy. It follows the convention of using compatible string
>>> which represent the SoC in which the IP was added for the first
>>> time.
>>>
>>> Signed-off-by: Rahul Sharma
>>
>>
>> Acked-by: Kukjin Kim
>>
>
> Just one nit in subject:
>
> [PATCH] ARM: dts: . for exynos5250
>
> Thanks,
>
> - Kukjin
>
>>> ---
>>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>>> b/arch/arm/boot/dts/cros5250-common.dtsi
>>> index 3f0239e..dc259e8b 100644
>>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>>> @@ -190,7 +190,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc@50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -224,7 +224,7 @@
>>> samsung,i2c-max-bus-freq =<378000>;
>>>
>>> hdmiphy@38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> index 3e0c792..f320d7c 100644
>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> @@ -72,7 +72,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc@50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -102,7 +102,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiphy@38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 0673524..2f7763b 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -601,7 +601,7 @@
>>> };
>>>
>>> hdmi {
>>> - compatible = "samsung,exynos5-hdmi";
>>> + compatible = "samsung,exynos4212-hdmi";
>>> reg =<0x1453 0x7>;
>>> interrupts =<0 95 0>;
>>> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
>>> @@ -611,7 +611,7 @@
>>> };
>>>
>>> mixer {
>>> - compatible = "samsung,exynos5-mixer";
>>> + compatible = "samsung,exynos5250-mixer";
>>> reg =<0x1445 0x1>;
>>> interrupts =<0 94 0>;
>>> };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #14 from Alex Deucher --- I'd suggest sending it to the mailing list (mesa-...@lists.freedesktop.org). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #15 from Alex Deucher --- Please use git to format the patch and include a description of what the patch does and how it fixes the issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 21:51, Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma
Acked-by: Kukjin Kim
- Kukjin
---
arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
arch/arm/boot/dts/exynos5250.dtsi |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq =<66000>;
hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq =<378000>;
hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq =<66000>;
hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq =<66000>;
hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg =<0x1453 0x7>;
interrupts =<0 95 0>;
clocks =<&clock 333>,<&clock 136>,<&clock 137>,
@@ -611,7 +611,7 @@
};
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg =<0x1445 0x1>;
interrupts =<0 94 0>;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/video/exynos_mixer.txt |1 +
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +++-
drivers/gpu/drm/exynos/regs-mixer.h|7 +++
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index a8b063f..c64ddc1 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsung,exynos5250-mixer"
+ 3) "samsung,exynos5420-mixer"
- reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+ MXR_VER_128_0_0_184,
};
struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
- /* choosing between porper HD and SD mode */
- if (height <= 480)
- val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
- else if (height <= 576)
- val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
- else if (height <= 720)
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
- else if (height <= 1080)
- val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
- else
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+ /* choosing between proper HD and SD mode */
+ if (height <= 480)
+ val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+ else if (height <= 576)
+ val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+ else if (height <= 720)
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ else if (height <= 1080)
+ val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+ else
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ }
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
}
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
+ /* setup display size */
+ if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+ win == MIXER_DEFAULT_WIN) {
+ val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+ val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+ mixer_reg_write(res, MXR_RESOLUTION, val);
+ }
+
val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
mixer_cfg_layer(ctx, win, true);
/* layer update mandatory for mixer 16.0.33.0 */
- if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+ ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
{
+ struct mixer_context *mixer_ctx = ctx;
u32 w, h;
w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
+ if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+ mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+ return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
exynos_drm_hdmi_context *ctx,
return 0;
}
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+ .version = MXR_VER_128_0_0_184,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @
[PATCH v3 0/3] exynos5420/hdmi: add support for hdmi subsystem
Add support for exynos5420 hdmi subsystem. It adds compatible strings for exynos5420 mixer and Changes the drivers as per IP modifications. This set doesn't have changes for hdmiphy, which will posted independently. This set is based on drm-next branch of Inki Dae's tree at http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git. v3: 1) instead of replacing with old compatible strings, new ones are added without removing the support for older ones. 2) removed patch "drm/exynos: fix interlace resolutions for exynos5420" as it is independently merged. v2: 1)update device mixer tree binding document with "samsung,exynos5420-mixer" Rahul Sharma (3): drm/exynos: add new compatible strings for hdmi subsystem drm/exynos: add support for exynos5420 mixer ARM/dts: change compatible strings for hdmi subsystem .../devicetree/bindings/video/exynos_hdmi.txt |7 ++- .../devicetree/bindings/video/exynos_hdmiddc.txt |7 ++- .../devicetree/bindings/video/exynos_hdmiphy.txt |7 ++- .../devicetree/bindings/video/exynos_mixer.txt |9 ++- arch/arm/boot/dts/cros5250-common.dtsi |4 +- arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +- arch/arm/boot/dts/exynos5250.dtsi |4 +- drivers/gpu/drm/exynos/exynos_ddc.c|2 + drivers/gpu/drm/exynos/exynos_hdmi.c |3 + drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 ++ drivers/gpu/drm/exynos/exynos_mixer.c | 62 ++-- drivers/gpu/drm/exynos/regs-mixer.h|7 +++ 12 files changed, 89 insertions(+), 31 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/exynos: add new compatible strings for hdmi subsystem
This patch adds new combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt |7 +--
.../devicetree/bindings/video/exynos_hdmiddc.txt |7 +--
.../devicetree/bindings/video/exynos_hdmiphy.txt |7 +--
Documentation/devicetree/bindings/video/exynos_mixer.txt |8 ++--
drivers/gpu/drm/exynos/exynos_ddc.c |2 ++
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++
drivers/gpu/drm/exynos/exynos_hdmiphy.c |4
drivers/gpu/drm/exynos/exynos_mixer.c | 13 -
8 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..c71d0f0 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,10 @@
Device-Tree bindings for drm hdmi driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: value should be one among the following:
+ 1) "samsung,exynos5-hdmi"
+ 2) "samsung,exynos4210-hdmi"
+ 3) "samsung,exynos4212-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -15,7 +18,7 @@ Required properties:
Example:
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 0xf 1 3>;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..41eee97 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,15 @@
Device-Tree bindings for hdmiddc driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmiddc".
+- compatible: value should be one of the following
+ 1) "samsung,exynos5-hdmiddc"
+ 2) "samsung,exynos4210-hdmiddc"
+
- reg: I2C address of the hdmiddc device.
Example:
hdmiddc {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..162f641 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,15 @@
Device-Tree bindings for hdmiphy driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmiphy".
+- compatible: value should be one of the following:
+ 1) "samsung,exynos5-hdmiphy"
+ 2) "samsung,exynos4210-hdmiphy".
+ 3) "samsung,exynos4212-hdmiphy".
- reg: I2C address of the hdmiphy device.
Example:
hdmiphy {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..9131b99 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,11 @@
Device-Tree bindings for mixer driver
Required properties:
-- compatible: value should be "samsung,exynos5-mixer".
+- compatible: value should be one of the following:
+ 1) "samsung,exynos5-mixer"
+ 2) "samsung,exynos4210-mixer"
+ 3) "samsung,exynos5250-mixer"
+
- reg: physical base address of the mixer and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -9,7 +13,7 @@ Required properties:
Example:
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..95c75ed 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -53,6 +53,8 @@ static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiddc",
[PATCH v3 2/3] drm/exynos: add support for exynos5420 mixer
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/video/exynos_mixer.txt |1 +
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +++-
drivers/gpu/drm/exynos/regs-mixer.h|7 +++
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9131b99..3334b0a 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -5,6 +5,7 @@ Required properties:
1) "samsung,exynos5-mixer"
2) "samsung,exynos4210-mixer"
3) "samsung,exynos5250-mixer"
+ 4) "samsung,exynos5420-mixer"
- reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6225501..b1280b4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+ MXR_VER_128_0_0_184,
};
struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
- /* choosing between porper HD and SD mode */
- if (height <= 480)
- val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
- else if (height <= 576)
- val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
- else if (height <= 720)
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
- else if (height <= 1080)
- val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
- else
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+ /* choosing between proper HD and SD mode */
+ if (height <= 480)
+ val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+ else if (height <= 576)
+ val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+ else if (height <= 720)
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ else if (height <= 1080)
+ val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+ else
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ }
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
}
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
+ /* setup display size */
+ if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+ win == MIXER_DEFAULT_WIN) {
+ val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+ val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+ mixer_reg_write(res, MXR_RESOLUTION, val);
+ }
+
val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
mixer_cfg_layer(ctx, win, true);
/* layer update mandatory for mixer 16.0.33.0 */
- if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+ ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
{
+ struct mixer_context *mixer_ctx = ctx;
u32 w, h;
w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
+ if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+ mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+ return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
exynos_drm_hdmi_context *ctx,
return 0;
}
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+ .version = MXR_VER_128_0_0_184,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1145,6 +1167
[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
arch/arm/boot/dts/exynos5250.dtsi |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq = <66000>;
hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq = <378000>;
hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq = <66000>;
hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq = <66000>;
hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
clocks = <&clock 333>, <&clock 136>, <&clock 137>,
@@ -611,7 +611,7 @@
};
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 22:50, Kukjin Kim wrote:
On 06/19/13 21:51, Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma
Acked-by: Kukjin Kim
Just one nit in subject:
[PATCH] ARM: dts: . for exynos5250
Thanks,
- Kukjin
---
arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq =<66000>;
hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq =<378000>;
hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq =<66000>;
hdmiddc@50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg =<0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq =<66000>;
hdmiphy@38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg =<0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg =<0x1453 0x7>;
interrupts =<0 95 0>;
clocks =<&clock 333>,<&clock 136>,<&clock 137>,
@@ -611,7 +611,7 @@
};
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg =<0x1445 0x1>;
interrupts =<0 94 0>;
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
On 06/19/13 13:04, Rahul Sharma wrote: + mike Mike, I'm waiting for your reply on this. If you're OK, let me take this series on top of exynos5420 stuff in samsung tree. Of course, if any concerns, please let me know. Thanks, - Kukjin On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote: Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. This set dependents on the following patches which add support for Exynos5420 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html Rahul Sharma (5): clk/exynos5420: add sclk_hdmiphy to the list of special clocks clk/exynos5420: add gate clock for tv sysmmu clk/exynos5420: fix the order of parents of hdmi mux clk/exynos5420: add hdmi mux to change parents in hdmi driver clk/exynos5420: assign sclk_pixel id to pixel clock divider .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ drivers/clk/samsung/clk-exynos5420.c | 18 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote: > On the other hand, the below shows how we could enhance the conventional > way with my approach (just example): > > CPU -> DMA, > ioctl(qbuf command) ioctl(streamon) > | | > | | > qbuf <- dma_buf_sync_get start streaming <- syncpoint > > dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object. And > the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA > accesses the sync buffer. > > And DMA -> CPU, > ioctl(dqbuf command) > | > | > dqbuf <- nothing to do > > Actual syncpoint is when DMA operation is completed (in interrupt handler): > the syncpoint is performed by calling dma_buf_sync_unlock(). > Hence, my approach is to move the syncpoints into just before dma access > as long as possible. What you've just described does *not* work on architectures such as ARMv7 which do speculative cache fetches from memory at any time that that memory is mapped with a cacheable status, and will lead to data corruption. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: add hotspot support for cursors.
From: Dave Airlie
So it looks like for virtual hw cursors on QXL we need to inform
the "hw" device what the cursor hotspot parameters are. This
makes sense if you think the host has to draw the cursor and interpret
clicks from it. However the current modesetting interface doesn't support
passing the hotspot information from userspace.
This implements a new cursor ioctl, that takes the hotspot info as well,
userspace can try calling the new interface and if it -ENOSYS, can just
fallback to the old non-hotspot interface.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_crtc.c | 35 +--
drivers/gpu/drm/drm_drv.c | 1 +
include/drm/drm_crtc.h | 5 +
include/uapi/drm/drm.h | 1 +
include/uapi/drm/drm_mode.h | 13 +
5 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..cc9eada 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2099,10 +2099,10 @@ out:
return ret;
}
-int drm_mode_cursor_ioctl(struct drm_device *dev,
- void *data, struct drm_file *file_priv)
+static int drm_mode_cursor_common(struct drm_device *dev,
+ struct drm_mode_cursor2 *req,
+ struct drm_file *file_priv)
{
- struct drm_mode_cursor *req = data;
struct drm_mode_object *obj;
struct drm_crtc *crtc;
int ret = 0;
@@ -2122,13 +2122,17 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
mutex_lock(&crtc->mutex);
if (req->flags & DRM_MODE_CURSOR_BO) {
- if (!crtc->funcs->cursor_set) {
+ if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
ret = -ENXIO;
goto out;
}
/* Turns off the cursor if handle is 0 */
- ret = crtc->funcs->cursor_set(crtc, file_priv, req->handle,
- req->width, req->height);
+ if (crtc->funcs->cursor_set2)
+ ret = crtc->funcs->cursor_set2(crtc, file_priv,
req->handle,
+ req->width, req->height,
req->hot_x, req->hot_y);
+ else
+ ret = crtc->funcs->cursor_set(crtc, file_priv,
req->handle,
+ req->width, req->height);
}
if (req->flags & DRM_MODE_CURSOR_MOVE) {
@@ -2143,6 +2147,25 @@ out:
mutex_unlock(&crtc->mutex);
return ret;
+
+}
+int drm_mode_cursor_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_cursor *req = data;
+ struct drm_mode_cursor2 new_req;
+
+ memcpy(&new_req, req, sizeof(struct drm_mode_cursor));
+ new_req.hot_x = new_req.hot_y = 0;
+
+ return drm_mode_cursor_common(dev, &new_req, file_priv);
+}
+
+int drm_mode_cursor2_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_cursor2 *req = data;
+ return drm_mode_cursor_common(dev, req, file_priv);
}
/* Original addfb only supported RGB formats, so figure out which one */
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9cc247f..99fcd7c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -166,6 +166,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES,
drm_mode_obj_get_properties_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY,
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR2, drm_mode_cursor2_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..093c030 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -339,6 +339,9 @@ struct drm_crtc_funcs {
/* cursor controls */
int (*cursor_set)(struct drm_crtc *crtc, struct drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height);
+ int (*cursor_set2)(struct drm_crtc *crtc, struct drm_file *file_priv,
+ uint32_t handle, uint32_t width, uint32_t height,
+ int32_t hot_x, int32_t hot_y);
int (*cursor_move)(struct drm_crtc *crtc, int x, int y);
/* Set gamma on the CRTC */
@@ -1022,6 +1025,8 @@ extern int drm_mode_setplane(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_cursor_ioctl(str
[PATCH 2/2] drm/qxl: add support for cursor hotspot.
From: Dave Airlie
This uses the cursor hotspot info from userspace and passes
it to the qxl hw layer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_display.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 823d29e..489e879 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -255,11 +255,11 @@ qxl_hide_cursor(struct qxl_device *qdev)
qxl_release_unreserve(qdev, release);
}
-static int qxl_crtc_cursor_set(struct drm_crtc *crtc,
- struct drm_file *file_priv,
- uint32_t handle,
- uint32_t width,
- uint32_t height)
+static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
+ struct drm_file *file_priv,
+ uint32_t handle,
+ uint32_t width,
+ uint32_t height, int32_t hot_x, int32_t hot_y)
{
struct drm_device *dev = crtc->dev;
struct qxl_device *qdev = dev->dev_private;
@@ -315,8 +315,8 @@ static int qxl_crtc_cursor_set(struct drm_crtc *crtc,
cursor->header.type = SPICE_CURSOR_TYPE_ALPHA;
cursor->header.width = 64;
cursor->header.height = 64;
- cursor->header.hot_spot_x = 0;
- cursor->header.hot_spot_y = 0;
+ cursor->header.hot_spot_x = hot_x;
+ cursor->header.hot_spot_y = hot_y;
cursor->data_size = size;
cursor->chunk.next_chunk = 0;
cursor->chunk.prev_chunk = 0;
@@ -397,7 +397,7 @@ static int qxl_crtc_cursor_move(struct drm_crtc *crtc,
static const struct drm_crtc_funcs qxl_crtc_funcs = {
- .cursor_set = qxl_crtc_cursor_set,
+ .cursor_set2 = qxl_crtc_cursor_set2,
.cursor_move = qxl_crtc_cursor_move,
.gamma_set = qxl_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
--
1.8.2.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm/exynos: add support for exynos5420 mixer
Hello Rahul,
This patch is exactly same with v2 2/4 and only rebased on v3 1/3, so my
ack is valid for this patch.
On 2013년 06월 19일 21:51, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
Anyway, this patch can be merged after merging [Patch v3 1/3] as like v2.
Best Regards,
- Seung-Woo Kim
> ---
> .../devicetree/bindings/video/exynos_mixer.txt |1 +
> drivers/gpu/drm/exynos/exynos_mixer.c | 49
> +++-
> drivers/gpu/drm/exynos/regs-mixer.h|7 +++
> 3 files changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9131b99..3334b0a 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -5,6 +5,7 @@ Required properties:
> 1) "samsung,exynos5-mixer"
> 2) "samsung,exynos4210-mixer"
> 3) "samsung,exynos5250-mixer"
> + 4) "samsung,exynos5420-mixer"
>
> - reg: physical base address of the mixer and length of memory mapped
> region.
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 6225501..b1280b4 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
> enum mixer_version_id {
> MXR_VER_0_0_0_16,
> MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
> };
>
> struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> MXR_CFG_SCAN_PROGRASSIVE);
>
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>
> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
> }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
> *ctx, int win)
> /* setup geometry */
> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
> val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> mixer_cfg_layer(ctx, win, true);
>
> /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> mixer_layer_update(ctx);
>
> mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
> {
> + struct mixer_context *mixer_ctx = ctx;
> u32 w, h;
>
> w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
> drm_display_mode *mode)
> mode->hdisplay, mode->vdisplay, mode->vrefresh,
> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> (w >= 1664 && w <= 1920 && h >= 936 && h
Re: [PATCH v3 1/3] drm/exynos: add new compatible strings for hdmi subsystem
Hi Tomasz, Lucas,
How does this patch look to you ? Please share your views.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 6:21 PM, Rahul Sharma wrote:
> This patch adds new combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Drivers continue to support the previous compatible strings
> but further addition of these compatible strings in device tree
> is deprecated.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt |7 +--
> .../devicetree/bindings/video/exynos_hdmiddc.txt |7 +--
> .../devicetree/bindings/video/exynos_hdmiphy.txt |7 +--
> Documentation/devicetree/bindings/video/exynos_mixer.txt |8 ++--
> drivers/gpu/drm/exynos/exynos_ddc.c |2 ++
> drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++
> drivers/gpu/drm/exynos/exynos_hdmiphy.c |4
> drivers/gpu/drm/exynos/exynos_mixer.c | 13
> -
> 8 files changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..c71d0f0 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos5-hdmi"
> + 2) "samsung,exynos4210-hdmi"
> + 3) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +18,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..41eee97 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,15 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be one of the following
> + 1) "samsung,exynos5-hdmiddc"
> + 2) "samsung,exynos4210-hdmiddc"
> +
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..162f641 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,15 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be one of the following:
> + 1) "samsung,exynos5-hdmiphy"
> + 2) "samsung,exynos4210-hdmiphy".
> + 3) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..9131b99 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,11 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be one of the following:
> + 1) "samsung,exynos5-mixer"
> + 2) "samsung,exynos4210-mixer"
> + 3) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +13,7 @@ Required properties:
> Example:
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
> reg = <0x1445 0x1>;
>
Re: [PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT
>> >> Signed-off-by: Benoit Parrot > > Acked-by: Rob Clark Applied to -next, thanks, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/shmobile: Drop usage of removed drm_plane enabled field
On Thu, Jun 20, 2013 at 12:45 AM, Laurent Pinchart wrote: > The enabled field has been removed from struct drm_plane. Don't use it > in the driver. Applied to -next, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] idr: Rework idr_preload()
On Wed, Jun 19, 2013 at 01:18:32AM -0700, Tejun Heo wrote: > Hello, Kent. > > On Tue, Jun 18, 2013 at 05:02:30PM -0700, Kent Overstreet wrote: > > With the new ida implementation, that doesn't work anymore - the new ida > > code grows its bitmap tree by reallocating the entire thing in power of > > two increments. Doh. > > So, I'm not sure about the single contiguous array implementation. It > introduces some nasty characteristics such as possibly too large > contiguous allocation, bursty CPU usages, and loss of the ability to > handle ID allocations clustered in high areas - sure, the old ida > wasn't great on that part either but this can be much worse. > > In addition, I'm not sure what this single contiguous allocation buys > us. Let's say each leaf node size is 4k. Even with in-array tree > implementation, it should be able to serve 2k IDs per-page, which > would be enough for most use cases and with a bit of caching it can > easily achieve both the performance benefits of array implementation > and the flexibility of allocating each leaf separately. Even without > caching, the tree depth would normally be much lower than the current > implementation and the performance should be better. If you're > bothered by having to implement another radix tree for it, it should > be possible to just implement the leaf node logic and use the existing > radix tree for internal nodes, right? With respect to performance, strongly disagree. Leaving pointers out of the interior nodes cuts our space requirements by a factor of _64_ - that's huge, and with data structures the dominating factors w.r.t. performance tend to be the amount of memory you touch and the amount of pointer chasing. The lack of pointer chasing also means I could add prefetching to the tree walking code (child nodes are always contiguous in memory) like I did in bcache's binary search trees - I didn't realize DLM was using this for so many ids so I'll probably add that. That means for quite large bitmaps, _all_ the interior nodes will fit onto a couple cachelines which are all contiguous in memory. That's _huge_. Even for 1 million ids - that's 128 kilobytes for all the leaf nodes, which means all the interior nodes take up 2 kilobytes - which again is contiguous so we can prefetch far in advance as we walk down the tree. (If I was optimizing for huge bitmaps I would've picked a bigger splay factor and the interior nodes would take up even less memory, but I've been assuming the common case for the bitmap size is less than a page in which case BITS_PER_LONG should be about right). Also, idr_find() was slower than radix_tree_lookup() before, as tested for some aio patches - decoupling the id allocation from the radix tree gives the id allocator more freedom in its data structures (couldn't realloc before without breaking RCU lookup). I'm highly skeptical the bursty CPU usage is going to be a real issue in practice, as that can happen anywhere we do allocation - the realloc is going to be trivial compared to what can happen then. What's important is just the amortized cpu overhead, and in that respect doing the realloc is definitely a performance win. Besides all that, the ida/idr reimplementations deleted > 300 lines of code from idr.[ch]. If you try to add caching to the existing ida code, it's only going to get more complicated - and trying to maintain the behaviour where we always allocate the smallest available id is going to be fun there (the cache has to be kept in sorted order every time you free an id). Sparse id allocations/allocations clustered in the high areas isn't a concern - part of the reason I separated out ida_alloc() from ida_alloc_range() was to make sure none of the existing code was doing anything dumb with the starting id. The only thing that would've been a problem there was idr_alloc_cyclic() (and the code that was open coding ida_alloc_cyclic() as a performance hack), but the new ida_alloc_cyclic() handles that - handles it better than the old version, too. The only real concern I've come across is the fact that this implementation currently can't allocate up to INT_MAX ids with the whole allocation being contiguous - for all the uses I'd looked at I didn't think this was going to be an issue, but turns out it probably will be for DLM. So I've got a bit more work to do there. (I'm still not going to go with anything resembling a radix tree though - instead of having a flat array, I'll have a an array of pointers to fixed size array segments once the entire tree exceeds a certain size). > > So we need a slightly different trick. Note that if all allocations from > > an idr start by calling idr_prealloc() and disabling premption, at > > most nr_cpus() allocations can happen before someone calls > > idr_prealloc() again. > > But we allow mixing preloaded and normal allocations and users are > allowed to allocate as many IDs they want after preloading. It should > guarantee that the first allocation after
Re: [PATCH 10/10] idr: Rework idr_preload()
On Wed, Jun 19, 2013 at 04:33:44PM -0700, Kent Overstreet wrote: > With respect to performance, strongly disagree. Leaving pointers out of > the interior nodes cuts our space requirements by a factor of _64_ - > that's huge, and with data structures the dominating factors w.r.t. > performance tend to be the amount of memory you touch and the amount of > pointer chasing. > > The lack of pointer chasing also means I could add prefetching to the > tree walking code (child nodes are always contiguous in memory) like I > did in bcache's binary search trees - I didn't realize DLM was using > this for so many ids so I'll probably add that. > > That means for quite large bitmaps, _all_ the interior nodes will fit > onto a couple cachelines which are all contiguous in memory. That's > _huge_. Do all that in the leaf node which will be able to serve most use cases with single leaf node anyway, so you really don't lose anything. > Even for 1 million ids - that's 128 kilobytes for all the leaf nodes, > which means all the interior nodes take up 2 kilobytes - which again is > contiguous so we can prefetch far in advance as we walk down the tree. So, that's ~30k IDs per page, right? Let the internal node have 64 fan out, then you'll only have single depth tree for 1mil. Again, you're not losing much, if anything, while gaining more predictable behavior and flexibility. > Also, idr_find() was slower than radix_tree_lookup() before, as tested > for some aio patches - decoupling the id allocation from the radix tree > gives the id allocator more freedom in its data structures (couldn't > realloc before without breaking RCU lookup). Yeah, sure. I don't have any problem implementing idr in terms of ida. I do have problems with ida being one contiguous array. > Besides all that, the ida/idr reimplementations deleted > 300 lines of > code from idr.[ch]. If you try to add caching to the existing ida code, > it's only going to get more complicated - and trying to maintain the > behaviour where we always allocate the smallest available id is going to > be fun there (the cache has to be kept in sorted order every time you > free an id). It's like recursive code. It looks more elegant and looks okay for most cases but breaks in corner cases and we end up converting it to iterative code anyway. Similar thing. Long contiguous arrays just don't work. We're very likely to break it up eventually anyway. > (I'm still not going to go with anything resembling a radix tree though > - instead of having a flat array, I'll have a an array of pointers to > fixed size array segments once the entire tree exceeds a certain size). I don't really care how it gets split but firm nack on single contiguous array. > > But we allow mixing preloaded and normal allocations and users are > > allowed to allocate as many IDs they want after preloading. It should > > guarantee that the first allocation after preloading follows the > > stronger allocation flag, and the above approach can't guarantee that. > > None of the existing code nedes that guarantee, though. Hmmm? ISTR users mixing preloaded and !preloaded allocations. Maybe I'm misremembering. I don't know. But still the API is nasty like hell. Nobody is gonna notice even if it's being misused. It's just gonna have allocation failure after preloading once in a blue moon and we won't be able to track it down. > That's what I documented, and I audited all the existing idr_preload() > users (had to anyways). Generally speaking idr allocations are done from > a central location anyways so IMO it's a pretty trivial issue in > practice. If that has to happen, you need to enforce it. Trigger WARN if somebody violates the rule, but really this is just nasty. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/i915: fix potential NULL pointer dereference in i915_gem_context_get_hang_stats()
From: Wei Yongjun
The dereference should be moved below the NULL test.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ff47145..f32107e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -309,7 +309,7 @@ i915_gem_context_get_hang_stats(struct intel_ring_buffer
*ring,
u32 id)
{
struct drm_i915_private *dev_priv = ring->dev->dev_private;
- struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct drm_i915_file_private *file_priv;
struct i915_hw_context *to;
if (dev_priv->hw_contexts_disabled)
@@ -321,6 +321,7 @@ i915_gem_context_get_hang_stats(struct intel_ring_buffer
*ring,
if (file == NULL)
return ERR_PTR(-EINVAL);
+ file_priv = file->driver_priv;
if (id == DEFAULT_CONTEXT_ID)
return &file_priv->hang_stats;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] gpu: fix printk format warning in i915_gem.c
From: Randy Dunlap
Fix printk format warning in i915_gem.c:
drivers/gpu/drm/i915/i915_gem.c:3113:3: warning: format '%ld' expects argument
of type 'long int', but argument 5 has type 'size_t' [-Wformat]
Signed-off-by: Randy Dunlap
Cc: Daniel Vetter
Cc: David Airlie
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20130619.orig/drivers/gpu/drm/i915/i915_gem.c
+++ linux-next-20130619/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,7 +3110,7 @@ i915_gem_object_bind_to_gtt(struct drm_i
* before evicting everything in a vain attempt to find space.
*/
if (obj->base.size > gtt_max) {
- DRM_ERROR("Attempting to bind an object larger than the
aperture: object=%zd > %s aperture=%ld\n",
+ DRM_ERROR("Attempting to bind an object larger than the
aperture: object=%zd > %s aperture=%zu\n",
obj->base.size,
map_and_fenceable ? "mappable" : "total",
gtt_max);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org > [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On > Behalf Of Russell King - ARM Linux > Sent: Thursday, June 20, 2013 3:29 AM > To: Inki Dae > Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun > Cho; linux-me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote: > > On the other hand, the below shows how we could enhance the conventional > > way with my approach (just example): > > > > CPU -> DMA, > > ioctl(qbuf command) ioctl(streamon) > > | | > > | | > > qbuf <- dma_buf_sync_get start streaming <- syncpoint > > > > dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object. > And > > the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA > > accesses the sync buffer. > > > > And DMA -> CPU, > > ioctl(dqbuf command) > > | > > | > > dqbuf <- nothing to do > > > > Actual syncpoint is when DMA operation is completed (in interrupt > handler): > > the syncpoint is performed by calling dma_buf_sync_unlock(). > > Hence, my approach is to move the syncpoints into just before dma > access > > as long as possible. > > What you've just described does *not* work on architectures such as > ARMv7 which do speculative cache fetches from memory at any time that > that memory is mapped with a cacheable status, and will lead to data > corruption. I didn't explain that enough. Sorry about that. 'nothing to do' means that a dmabuf sync interface isn't called but existing functions are called. So this may be explained again: ioctl(dqbuf command) | | dqbuf <- 1. dma_unmap_sg 2. dma_buf_sync_unlock (syncpoint) The syncpoint I mentioned means lock mechanism; not doing cache operation. In addition, please see the below more detail examples. The conventional way (without dmabuf-sync) is: Task A 1. CPU accesses buf 2. Send the buf to Task B 3. Wait for the buf from Task B 4. go to 1 Task B --- 1. Wait for the buf from Task A 2. qbuf the buf 2.1 insert the buf to incoming queue 3. stream on 3.1 dma_map_sg if ready, and move the buf to ready queue 3.2 get the buf from ready queue, and dma start. 4. dqbuf 4.1 dma_unmap_sg after dma operation completion 4.2 move the buf to outgoing queue 5. back the buf to Task A 6. go to 1 In case that two tasks share buffers, and data flow goes from Task A to Task B, we would need IPC operation to send and receive buffers properly between those two tasks every time CPU or DMA access to buffers is started or completed. With dmabuf-sync: Task A 1. dma_buf_sync_lock <- synpoint (call by user side) 2. CPU accesses buf 3. dma_buf_sync_unlock <- syncpoint (call by user side) 4. Send the buf to Task B (just one time) 5. go to 1 Task B --- 1. Wait for the buf from Task A (just one time) 2. qbuf the buf 1.1 insert the buf to incoming queue 3. stream on 3.1 dma_buf_sync_lock <- syncpoint (call by kernel side) 3.2 dma_map_sg if ready, and move the buf to ready queue 3.3 get the buf from ready queue, and dma start. 4. dqbuf 4.1 dma_buf_sync_unlock <- syncpoint (call by kernel side) 4.2 dma_unmap_sg after dma operation completion 4.3 move the buf to outgoing queue 5. go to 1 On the other hand, in case of using dmabuf-sync, as you can see the above example, we would need IPC operation just one time. That way, I think we could not only reduce performance overhead but also make user application simplified. Of course, this approach can be used for all DMA device drivers such as DRM. I'm not a specialist in v4l2 world so there may be missing point. Thanks, Inki Dae > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Avoid forcing a detection cycle following a hotplug event
Hi Chris, On Saturday 08 June 2013 08:53:30 Chris Wilson wrote: > On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote: > > Could you please also update Documentation/DocBook/drm.tmpl ? > > It looks out of context there, as nothing explains the hotplug -> > fill_modes -> probe -> detect loop... Sorry, I should have been more precise. You patches changes the prototype of the fill_modes() operation and the drm_helper_probe_single_connector_modes() function, documented in drm.tmpl. I'd like to keep the documentation in sync. > > How about: > > Modes > int (*fill_modes)(struct drm_connector *connector, uint32_t > max_width, uint32_t max_height, bool force); > > Fill the mode list with all supported modes for the connector. If the > max_width and max_height > arguments are non-zero, the implementation must ignore all modes wider > than max_width or higher than > max_height. The driver may use the existing > connector status, unless force is passed. During > a hotplug event, the driver may already have updated its knowledge of the > output and so may simply refresh the modes list from the information it > acquired whilst handling the event. However, the caller may explicitly > request that any cached information be dropped, and for the output to be > queried for its current status and modes - under such circumstances > force is true. > That looks good to me (I would split this in two paragraphs, but that's just nitpicking). Could you please also update the drm_helper_probe_single_connector_modes() description in drm.tmpl ? -- Regards, Laurent Pinchart
[PATCH 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality
Hi Joonyoung, On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote: > Hi, > > GEM CMA supports dma_buf but it needs GEM CMA specific functionality for > dma_buf. We can use prime helpers for dma_buf by commit > 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so > this patchset is to replace from using GEM CMA specific functions to > using prime helpers. Overall this looks good to me, except the that prime helpers don't cache mappings, unlike the current implementation in the GEM CMA helpers. Could that be fixed in the prime helpers first ? > Thanks. > > Joonyoung Shim (3): >drm: add mmap function to prime helpers >drm/cma: add low-level hook functions to use prime helpers >drm/cma: remove GEM CMA specific dma_buf functionality > > drivers/gpu/drm/drm_gem_cma_helper.c | 291 --- > drivers/gpu/drm/drm_prime.c | 5 +- > include/drm/drmP.h | 2 + > include/drm/drm_gem_cma_helper.h | 13 +- > 4 files changed, 56 insertions(+), 255 deletions(-) -- Regards, Laurent Pinchart
[PATCH v3 1/3] drm: add prime helpers
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
>
> gem_prime_pin: callback when a buffer is created, used to pin buffers into
> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
> export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
>
> These hooks are optional; drivers can opt in by using drm_gem_prime_import
> and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
> fields of struct drm_driver.
>
> v2:
> - Drop .begin_cpu_access. None of the drivers this code replaces
> implemented it. Having it here was a leftover from when I was trying to
> include i915 in this rework.
> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
> did. This patch series shouldn't change that behavior.
> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
> Rename struct sg_table* variables to 'sgt' for clarity.
> - Update drm.tmpl for these new hooks.
>
> v3:
> - Pass the vaddr down to the driver. This lets drivers that just call
> vunmap on the pointer avoid having to store the pointer in their GEM
> private structures. - Move documentation into a /** DOC */ comment in
> drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
> lines to include documentation of the individual functions from drmP.h, but
> the docproc / kernel-doc scripts barf on that file, so hopefully this is
> good enough for now.
> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
> ("drm/prime: drop reference on imported dma-buf come from gem")
>
> Signed-off-by: Aaron Plattner
> Cc: Daniel Vetter
> Cc: David Airlie
> ---
> Documentation/DocBook/drm.tmpl | 4 +
> drivers/gpu/drm/drm_prime.c| 186 +-
> include/drm/drmP.h | 12 +++
> 3 files changed, 201 insertions(+), 1 deletion(-)
[snip]
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7f12573..366910d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
[snip]
> +/**
> + * DOC: PRIME Helpers
> + *
> + * Drivers can implement @gem_prime_export and @gem_prime_import in terms
> of + * simpler APIs by using the helper functions @drm_gem_prime_export and
> + * @drm_gem_prime_import. These functions implement dma-buf support in
> terms of + * five lower-level driver callbacks:
> + *
> + * Export callbacks:
> + *
> + * - @gem_prime_pin (optional): prepare a GEM object for exporting
> + *
> + * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
> pages + *
> + * - @gem_prime_vmap: vmap a buffer exported by your driver
> + *
> + * - @gem_prime_vunmap: vunmap a buffer exported by your driver
> + *
> + * Import callback:
> + *
> + * - @gem_prime_import_sg_table (import): produce a GEM object from
> another + *driver's scatter/gather table
> + */
> +
> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> + struct drm_gem_object *obj, int flags)
> +{
> + if (dev->driver->gem_prime_pin) {
> + int ret = dev->driver->gem_prime_pin(obj);
> + if (ret)
> + return ERR_PTR(ret);
> + }
> + return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
> + 0600);
Why do you use 0600 instead of the flags passed by the caller ?
> +}
> +EXPORT_SYMBOL(drm_gem_prime_export);
--
Regards,
Laurent Pinchart
[PATCH v3 1/3] drm: add prime helpers
Hi Aaron,
On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
> On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
> > Hi Aaron,
> >
> > A bit late, but here's a small question.
> >
> > On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
> >> Instead of reimplementing all of the dma_buf functionality in every
> >> driver, create helpers drm_prime_import and drm_prime_export that
> >> implement them in terms of new, lower-level hook functions:
> >> gem_prime_pin: callback when a buffer is created, used to pin buffers
> >> into
> >> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
> >> export gem_prime_import_sg_table: convert an sg_table into a
> >> drm_gem_object
> >> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
> >>
> >> These hooks are optional; drivers can opt in by using
> >> drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
> >> and .gem_prime_export fields of struct drm_driver.
> >>
> >> v2:
> >> - Drop .begin_cpu_access. None of the drivers this code replaces
> >> implemented it. Having it here was a leftover from when I was trying to
> >> include i915 in this rework.
> >> - Use mutex_lock instead of mutex_lock_interruptible, as these three
> >> drivers did. This patch series shouldn't change that behavior.
> >> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
> >>
> >>Rename struct sg_table* variables to 'sgt' for clarity.
> >>
> >> - Update drm.tmpl for these new hooks.
> >>
> >> v3:
> >> - Pass the vaddr down to the driver. This lets drivers that just call
> >> vunmap on the pointer avoid having to store the pointer in their GEM
> >> private structures. - Move documentation into a /** DOC */ comment in
> >> drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
> >> lines to include documentation of the individual functions from drmP.h,
> >> but
> >> the docproc / kernel-doc scripts barf on that file, so hopefully this is
> >> good enough for now.
> >> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
> >>
> >>("drm/prime: drop reference on imported dma-buf come from gem")
> >>
> >> Signed-off-by: Aaron Plattner
> >> Cc: Daniel Vetter
> >> Cc: David Airlie
> >> ---
> >>
> >> Documentation/DocBook/drm.tmpl | 4 +
> >> drivers/gpu/drm/drm_prime.c| 186
> >> +-
> >> include/drm/drmP.h | 12 +++
> >> 3 files changed, 201 insertions(+), 1 deletion(-)
> >
> > [snip]
> >
> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >> index 7f12573..366910d 100644
> >> --- a/drivers/gpu/drm/drm_prime.c
> >> +++ b/drivers/gpu/drm/drm_prime.c
> >
> > [snip]
> >
> >> +/**
> >> + * DOC: PRIME Helpers
> >> + *
> >> + * Drivers can implement @gem_prime_export and @gem_prime_import in
> >> terms
> >> of + * simpler APIs by using the helper functions @drm_gem_prime_export
> >> and
> >> + * @drm_gem_prime_import. These functions implement dma-buf support in
> >> terms of + * five lower-level driver callbacks:
> >> + *
> >> + * Export callbacks:
> >> + *
> >> + * - @gem_prime_pin (optional): prepare a GEM object for exporting
> >> + *
> >> + * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
> >> pages + *
> >> + * - @gem_prime_vmap: vmap a buffer exported by your driver
> >> + *
> >> + * - @gem_prime_vunmap: vunmap a buffer exported by your driver
> >> + *
> >> + * Import callback:
> >> + *
> >> + * - @gem_prime_import_sg_table (import): produce a GEM object from
> >> another + *driver's scatter/gather table
> >> + */
> >> +
> >> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> >> + struct drm_gem_object *obj, int flags)
> >> +{
> >> + if (dev->driver->gem_prime_pin) {
> >> + int ret = dev->driver->gem_prime_pin(obj);
> >> + if (ret)
> >> + return ERR_PTR(ret);
> >> + }
> >> + return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
> >> +0600);
> >
> > Why do you use 0600 instead of the flags passed by the caller ?
>
> Because I copied & pasted it from i915_gem_prime_export prior to commit
> 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
> pointed it out just now.
That's a pretty valid reason I guess :-) Should I submit a patch or are you
already working on one ?
> >> +}
> >> +EXPORT_SYMBOL(drm_gem_prime_export);
--
Regards,
Laurent Pinchart
[PATCH v3] drm: Renesas R-Car Display Unit DRM driver
Hello Adam,
Ping ?
Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
get_modes operation that just returns 0 ?
On Friday 14 June 2013 16:03:19 Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 02:54:04AM +0200, Laurent Pinchart wrote:
> > On Friday 07 June 2013 10:50:55 Daniel Vetter wrote:
> > > On Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> > > > On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > > > > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > > > > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > > > > > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > > > > > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > > > > > > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart
wrote:
> > > > > [snip]
> > > > >
> > > > > > > >> > +static int rcar_du_vga_connector_get_modes(struct
> > > > > > > >> > drm_connector
> > > > > > > >> > *connector)
> > > > > > > >> > +{
> > > > > > > >> > + return drm_add_modes_noedid(connector, 1280, 768);
> > > > > > > >> > +}
> > > > > > > >>
> > > > > > > >> This (and the dummy detect function below) looks a bit funny,
> > > > > > > >> since it essentially overrides the default behaviour already
> > > > > > > >> provided by the crtc helpers. Until rcar has at least proper
> > > > > > > >> detect support for VGA
> > > > > > > >
> > > > > > > > I would add that but the DDC signals are not connected on the
> > > > > > > > boards I have access to :-/
> > > > > > > >
> > > > > > > >> I'd just kill this and use the connector force support (and
> > > > > > > >> manually adding the right resolutions).
> > > > > > > >
> > > > > > > > Looks like that's a candidate for better documentation... How
> > > > > > > > does force support work ?
> > > > > > >
> > > > > > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline,
> > > > > > > where you can also force a specific mode. The best I could find
> > > > > > > wrt docs is the kerneldoc for
> > > > > > > drm_mode_parse_command_line_for_connector. With a bit more
> > > > > > > reading it looks like it's intermingled with the fbdev helper
> > > > > > > code, but should be fairly easy to extract and used by your
> > > > > > > driver.
> > > > > >
> > > > > > It makes sense to force the connector state from command line, but
> > > > > > I'm not sure if the same mechanism is the best solution here. As
> > > > > > the driver has no way to know the connector state, the best we can
> > > > > > do is guess what modes are supported. I can just return 0 in the
> > > > > > get_modes handler, but then the core will not call
> > > > > > drm_add_modes_noedid(), and modes will need to be added manually.
> > > > > >
> > > > > > Is your point that for a board on which the VGA connector state
> > > > > > can't be detected, the user should always be responsible for
> > > > > > adding all the modes supported by the VGA monitor on the command
> > > > > > line ?
> > > > >
> > > > > My point is that we already have both an established code for
> > > > > connected outputs without EDID to add fallback modes and means to
> > > > > force connectors to certain states. Your code here seems to reinvent
> > > > > that wheel, so I wonder what we should/need to improve in the common
> > > > > code to suit your needs.
> > > >
> > > > The currently available code might suit my needs, it might just be
> > > > that I fail to see how to use it properly.
> > > >
> > > > Regarding the "code for connected outputs without EDID to add fallback
> > > > modes" you're referring to, is that
> > > >
> > > > if (count == 0 && connector->status ==
> > > > connector_status_connected)
> > > > count = drm_add_modes_noedid(connector, 1024, 768);
> > > >
> > > > in drm_helper_probe_single_connector_modes() ? That function will only
> > > > be called if the connector status is connector_status_connected. There
> > > > are two ways to enforce that:
> > > >
> > > > - returning connector_status_connected from the connector detect()
> > > > operation, which seems to defeat the purpose of having
> > > > connector_status_unknown completely.
> > >
> > > We might want to add such a default mode also for unknown, I'm not sure.
> > > Userspace policy is to first try to light up any connected outputs, and
> > > if> there's none try to light up any unknown outputs. Not sure whether
> > > userspace (i.e. X) will automatically add a default mode. fbcon might
> > > also handle this less gracefully.
> > >
> > > Personally I'm ok with extending this to unknown, it shouldn't really
> > > hurt (since we already try really hard not to leak unknown anywhere
> > > visible).
> >
> > Do you mean something like
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> > b/drivers/gpu/drm/drm_crtc_helper.c index f554516..9aae384 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -160,7
[PATCH 4/4] drm: Constify the pretty-print functions
Hi Ville,
On Friday 07 June 2013 18:43:07 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modified in drm_connector_init().
>
> While at it move the drm_get_connector_status_name() prototype from
> drmP.h to drm_crtc.h where it belongs.
This breaks compilation on drm-next:
drivers/gpu/drm/drm_fb_helper.c: In function
?drm_fb_helper_parse_command_line?:
drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of
?fb_get_options? discards ?const? qualifier from pointer target type [enabled
by default]
In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
include/linux/fb.h:627:12: note: expected ?char *? but argument is of type
?const char
> Signed-off-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_crtc.c | 30 +++---
> include/drm/drmP.h | 1 -
> include/drm/drm_crtc.h | 17 +
> 3 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 079996a..44c3421 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
>
> /* Avoid boilerplate. I'm tired of typing. */
> #define DRM_ENUM_NAME_FN(fnname, list) \
> - char *fnname(int val) \
> + const char *fnname(int val) \
> { \
> int i; \
> for (i = 0; i < ARRAY_SIZE(list); i++) {\
> @@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
> /*
> * Global properties
> */
> -static struct drm_prop_enum_list drm_dpms_enum_list[] =
> +static const struct drm_prop_enum_list drm_dpms_enum_list[] =
> {{ DRM_MODE_DPMS_ON, "On" },
> { DRM_MODE_DPMS_STANDBY, "Standby" },
> { DRM_MODE_DPMS_SUSPEND, "Suspend" },
> @@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> /*
> * Optional properties
> */
> -static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> {
> { DRM_MODE_SCALE_NONE, "None" },
> { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> @@ -125,7 +125,7 @@ static struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] = { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> -static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> {
> { DRM_MODE_DITHERING_OFF, "Off" },
> { DRM_MODE_DITHERING_ON, "On" },
> @@ -135,7 +135,7 @@ static struct drm_prop_enum_list
> drm_dithering_mode_enum_list[] = /*
> * Non-global properties, but "required" for certain connectors.
> */
> -static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -144,7 +144,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
>
> -static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -154,7 +154,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
>drm_dvi_i_subconnector_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -165,7 +165,7 @@ static struct drm_prop_enum_list
> drm_tv_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -177,7 +177,7 @@ static struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
[PATCH v2] drm: Remove some unused stuff from drm_plane
Hello,
On Wednesday 08 May 2013 15:52:10 Laurent Pinchart wrote:
> On Wednesday 08 May 2013 16:40:54 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l?
> >
> > There's a bunch of unused members inside drm_plane, bloating the size of
> > the structure needlessly. Eliminate them.
> >
> > v2: Remove all of it from kernel-doc too
> >
> > Signed-off-by: Ville Syrj?l?
>
> Reviewed-by: Laurent Pinchart
Wow, I've managed to review the patch and miss that it broke compilation of
the shmob-drm driver :-( I'll send a patch to fix it.
> > ---
> >
> > drivers/gpu/drm/drm_crtc.c | 2 +-
> > include/drm/drm_crtc.h | 11 ---
> > 2 files changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d7c449f..e591914 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1739,7 +1739,7 @@ int drm_mode_getplane(struct drm_device *dev, void
> > *data,
> >
> > plane_resp->plane_id = plane->base.id;
> > plane_resp->possible_crtcs = plane->possible_crtcs;
> >
> > - plane_resp->gamma_size = plane->gamma_size;
> > + plane_resp->gamma_size = 0;
> >
> > /*
> >
> > * This ioctl is called twice, once to determine how much space is
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index adb3f9b..e11c6bc 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -654,11 +654,7 @@ struct drm_plane_funcs {
> > * @format_count: number of formats supported
> > * @crtc: currently bound CRTC
> > * @fb: currently bound fb
> > - * @gamma_size: size of gamma table
> > - * @gamma_store: gamma correction table
> > - * @enabled: enabled flag
> > * @funcs: helper functions
> > - * @helper_private: storage for drver layer
> > * @properties: property tracking for this plane
> > */
> >
> > struct drm_plane {
> > @@ -674,14 +670,7 @@ struct drm_plane {
> > struct drm_crtc *crtc;
> > struct drm_framebuffer *fb;
> >
> > - /* CRTC gamma size for reporting to userspace */
> > - uint32_t gamma_size;
> > - uint16_t *gamma_store;
> > -
> > - bool enabled;
> > -
> > const struct drm_plane_funcs *funcs;
> > - void *helper_private;
> >
> > struct drm_object_properties properties;
> > };
--
Regards,
Laurent Pinchart
[PATCH] drm/prime: Honor requested file flags when exporting a buffer
The DRM PRIME API passes file flags to the driver for the exported
buffer. Honor them instead of hardcoding 0600.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_prime.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..e57c675 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -210,8 +210,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags)
{
- return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
-0600);
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
}
EXPORT_SYMBOL(drm_gem_prime_export);
--
Regards,
Laurent Pinchart
[PATCH 4/4] drm: Constify the pretty-print functions
On Wed, Jun 19, 2013 at 10:53 AM, Laurent Pinchart wrote: > Hi Ville, > > On Friday 07 June 2013 18:43:07 ville.syrjala at linux.intel.com wrote: >> From: Ville Syrj?l? >> >> The structures and strings involved with various pretty-print functions >> aren't meant to be modified, so make them all const. The exception is >> drm_connector_enum_list which does get modified in drm_connector_init(). >> >> While at it move the drm_get_connector_status_name() prototype from >> drmP.h to drm_crtc.h where it belongs. > > This breaks compilation on drm-next: > > drivers/gpu/drm/drm_fb_helper.c: In function > ?drm_fb_helper_parse_command_line?: > drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of > ?fb_get_options? discards ?const? qualifier from pointer target type [enabled > by default] > In file included from drivers/gpu/drm/drm_fb_helper.c:35:0: > include/linux/fb.h:627:12: note: expected ?char *? but argument is of type > ?const char The fix is in the fbdev tree, which appears not to be in -next, fail. Dave.
[PATCH] drm/prime: Honor requested file flags when exporting a buffer
On Wed, Jun 19, 2013 at 11:14 AM, Laurent Pinchart wrote: > The DRM PRIME API passes file flags to the driver for the exported > buffer. Honor them instead of hardcoding 0600. > > Signed-off-by: Laurent Pinchart (this time keeping cc's). Pushed to drm-fixes. thanks for noticing/fixing Dave.
[PATCH 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality
On 06/19/2013 08:02 AM, Laurent Pinchart wrote: > Hi Joonyoung, > > On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote: >> Hi, >> >> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for >> dma_buf. We can use prime helpers for dma_buf by commit >> 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so >> this patchset is to replace from using GEM CMA specific functions to >> using prime helpers. > Overall this looks good to me, except the that prime helpers don't cache > mappings, unlike the current implementation in the GEM CMA helpers. Could that > be fixed in the prime helpers first ? Right, i will update it first. Thanks.
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #13 from Krzysztof A. Sobiecki --- Is someone interested in this patch? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/91653786/attachment.html>
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
+ mike On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote: > Add clock changes for hdmi subsystem for exynos5250 SoC. These > include addition of new clocks like mout_hdmi and smmu_tv, associating > ID to clk_hdmiphy and some essential corrections. > > This set is based on kukjin's for-next branch at > http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. > > This set dependents on the following patches which add support for Exynos5420 > http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19264.html > > Rahul Sharma (5): > clk/exynos5420: add sclk_hdmiphy to the list of special clocks > clk/exynos5420: add gate clock for tv sysmmu > clk/exynos5420: fix the order of parents of hdmi mux > clk/exynos5420: add hdmi mux to change parents in hdmi driver > clk/exynos5420: assign sclk_pixel id to pixel clock divider > > .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ > drivers/clk/samsung/clk-exynos5420.c | 18 > +++--- > 2 files changed, 18 insertions(+), 7 deletions(-) > > -- > 1.7.10.4 >
exynos-drm-next todo work.
> -Original Message- > From: Rahul Sharma [mailto:r.sh.open at gmail.com] > Sent: Tuesday, June 18, 2013 6:46 PM > To: Inki Dae > Cc: linux-samsung-soc at vger.kernel.org; DRI mailing list > Subject: Re: exynos-drm-next todo work. > > Hi Mr. Dae, > > Related to HDMI sound support in Alsa, I have posted a working RFC > "exynos-hdmi to CDF complaint display driver". It registers a separate > sound card by registering hdmi audio codec dai and cpu-dai, as you > mentioned. But there is a problem with this approach that I2S being the > single cpu dai for HDMI and Speaker sound card, only one card can > support playback at a time. > > I would like to work on this to provide a more refined solution. > Thanks. However, I think it's not good to use the CDF framework to interface between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF framework is to provide common interfaces to display bus drivers to Linux framebuffer and DRM KMS based display controller drivers as long as I know. So my opinion is to implement ALSA Soc DAI driver-it seems like possible to use as is-based on a new common framework that the other can also use it. Thanks, Inki Dae > regards, > Rahul Sharma. > > On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae wrote: > > Hi all, > > > > I'd like to discuss Exynos DRM TODO work. > > > > There are features we have to solve and implement. The purpose of this > email > > is to share what we have to do so that other guys can be involved > without > > duplicated work. > > > > 1. gscaler based on KMS interfaces - exynos5250 and later use the > gscaler > > device instead of VP device. And now exynos drm driver has gscaler > module as > > a sub module of IPP framework. However, this gscaler module is very > specific > > to IPP framework so it's not easy to reuse this module. So maybe we need > so > > many works for it. > > > > Video play back path using post process (AS IS): > > MFCIPPKMS-FIMD or HDMI > > > > Ideal video play back path using post process (TO BE): > > MFCKMSFIMD or HDMI > > > > The above scenario is to send decoded image data (YUV format) to display > > device via post process. However, we don't really need to use IPP > framework > > in case of using gscaler as VP. All we have to do is to call kms > interface > > (setplane) for it like we did before. > > > > 2. More features for HDMI sound support - we need to implement Exynos > ALSA > > SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, > bit > > rate, and so on from user side should be sent to drm hdmi driver via > ALSA > > interface and the ALSA SoC DAI driver. As of now, it seems like that we > > should implement this driver like OMAP does because there is no common > > framework for interfacing between ALSA SoC DAI driver and DRM HDMI > driver: > > in case of OMAP, it seems like that ALSA SoC audio driver calls > interfaces > > of DSS driver directly. I think we could implement ALSA SoC DAI driver > in > > more generic way if we first implement common framework for it. > > > > Welcome to any volunteer and other opinions. > > > > Thanks, > > Inki Dae > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-samsung- > soc" in > > the body of a message to majordomo at vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] drm/exynos: add support for exynos5420 mixer
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable string
samsung,exynos5420-mixer is added with this patch.
Required properties:
- compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsung,exynos5250-mixer"
+ 3) "samsung,exynos5420-mixer"
Thanks and Regards,
- Seung-Woo Kim
On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 49
> +
> drivers/gpu/drm/exynos/regs-mixer.h |7 +
> 2 files changed, 44 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2fe6d33..d51ff36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
> enum mixer_version_id {
> MXR_VER_0_0_0_16,
> MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
> };
>
> struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> MXR_CFG_SCAN_PROGRASSIVE);
>
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>
> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
> }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
> *ctx, int win)
> /* setup geometry */
> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
> val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> mixer_cfg_layer(ctx, win, true);
>
> /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> mixer_layer_update(ctx);
>
> mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
> {
> + struct mixer_context *mixer_ctx = ctx;
> u32 w, h;
>
> w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
> drm_display_mode *mode)
> mode->hdisplay, mode->vdisplay, mode->vrefresh,
> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
> exynos_drm_hdmi_context *ctx,
> return 0;
> }
>
> +static struct mixer_drv_data exynos5420_mxr_drv_data = {
> + .version = MXR_VER_128_0_0_184,
> + .is_vp_enabled = 0,
> +};
> +
> static struct mixer_drv_data exynos5250_mxr_drv_data = {
> .version = MXR_VER_16_0_33_0,
> .is_vp_enabled = 0,
> @@ -1139,6 +1161,9 @@ static struct platform_device_id mixer_driver_types[] =
> {
>
> static struct of_dev
[PATCH 2/4] drm/exynos: add support for exynos5420 mixer
Sure Seung-Woo,
I will update binding document along with this patch.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 10:54 AM, ??? wrote:
> Hi Rahul,
>
> Code part looks good to me but IMHO, binding document for exynos_mixer
> is also fixed like following because compitable string
> samsung,exynos5420-mixer is added with this patch.
>
> Required properties:
> - compatible: value should be:
> 1) "samsung,exynos4210-mixer"
> 2) "samsung,exynos5250-mixer"
> + 3) "samsung,exynos5420-mixer"
>
> Thanks and Regards,
> - Seung-Woo Kim
>
> On 2013? 06? 18? 21:49, Rahul Sharma wrote:
>> Add support for exynos5420 mixer IP in the drm mixer driver.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> drivers/gpu/drm/exynos/exynos_mixer.c | 49
>> +
>> drivers/gpu/drm/exynos/regs-mixer.h |7 +
>> 2 files changed, 44 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 2fe6d33..d51ff36 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -78,6 +78,7 @@ struct mixer_resources {
>> enum mixer_version_id {
>> MXR_VER_0_0_0_16,
>> MXR_VER_16_0_33_0,
>> + MXR_VER_128_0_0_184,
>> };
>>
>> struct mixer_context {
>> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
>> unsigned int height)
>> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
>> MXR_CFG_SCAN_PROGRASSIVE);
>>
>> - /* choosing between porper HD and SD mode */
>> - if (height <= 480)
>> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
>> - else if (height <= 576)
>> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
>> - else if (height <= 720)
>> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> - else if (height <= 1080)
>> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
>> - else
>> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
>> + /* choosing between proper HD and SD mode */
>> + if (height <= 480)
>> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
>> + else if (height <= 576)
>> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
>> + else if (height <= 720)
>> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + else if (height <= 1080)
>> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
>> + else
>> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + }
>>
>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>> }
>> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
>> *ctx, int win)
>> /* setup geometry */
>> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>>
>> + /* setup display size */
>> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
>> + win == MIXER_DEFAULT_WIN) {
>> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
>> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
>> + mixer_reg_write(res, MXR_RESOLUTION, val);
>> + }
>> +
>> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
>> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
>> val |= MXR_GRP_WH_H_SCALE(x_ratio);
>> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context
>> *ctx, int win)
>> mixer_cfg_layer(ctx, win, true);
>>
>> /* layer update mandatory for mixer 16.0.33.0 */
>> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
>> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>> + ctx->mxr_ver == MXR_VER_128_0_0_184)
>> mixer_layer_update(ctx);
>>
>> mixer_run(ctx);
>> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>>
>> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
>> {
>> + struct mixer_context *mixer_ctx = ctx;
>> u32 w, h;
>>
>> w = mode->hdisplay;
>> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
>> drm_display_mode *mode)
>> mode->hdisplay, mode->vdisplay, mode->vrefresh,
>> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>>
>> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
>> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
>> + return 0;
>> +
>> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>> (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
>> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
>> exynos_drm_hdmi_context *ctx,
>> return 0;
>> }
>>
>> +static struct mixer_drv_data exynos5420_mxr_drv_data = {
>> + .version = MXR_VER_128_0_0_184,
>> + .is_vp_enab
[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem
On 06/18/13 14:09, Rahul Sharma wrote: > Hi Mr. Kukjin, > > Kindly consider the following patches for review and integration. > (+ Mike) Rahul, basically, looks good to me but I'm waiting for Mike's ack on this series... > regards, > Rahul Sharma. > > On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K > wrote: >> Hi, >> Tested this series on snow board and is working fine. >> >> Tested-by: Arun Kumar K >> Arun, thanks for your test. - Kukjin >> Regards >> Arun >> >> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma >> wrote: >>> Add clock changes for hdmi subsystem for exynos5250 SoC. These >>> include addition of new clocks like mout_hdmi and smmu_tv, associating >>> ID to clk_hdmiphy and some essential corrections. >>> >>> This set is based on kukjin's for-next branch at >>> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. >>> >>> Arun Kumar K (1): >>>clk/exynos5250: Fix HDMI clock number in documentation >>> >>> Rahul Sharma (4): >>>clk/exynos5250: add mout_hdmi mux clock for hdmi >>>clk/exynos5250: add sclk_hdmiphy in the list of special clocks >>>clk/exynos5250: add clock for tv sysmmu >>>clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem >>> >>> .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- >>> drivers/clk/samsung/clk-exynos5250.c | 18 >>> +- >>> 2 files changed, 24 insertions(+), 6 deletions(-)
[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420
Hi Rahul,
This patch looks good to me.
On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> Modified code for calculating hdmi IP register values from drm timing
> values. The modification is based on the inputs from hw team and specifically
> proposed for 1440x576i and 1440x480i. But same changes holds good for other
> interlaced resolutions also.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 8752171..2f807d5 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> (m->vsync_start - m->vdisplay) / 2);
> hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
> hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) / 2);
> - hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
> - ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
> + hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay / 2);
> hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
> hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) + 7);
> hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) + 2);
> @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> (m->htotal / 2) + (m->hsync_start - m->hdisplay));
> hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
> hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
> - hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
> + hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
> + hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
> + hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
> + hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
> hdmi_set_reg(tg->vact_st3, 2, 0x0);
> hdmi_set_reg(tg->vact_st4, 2, 0x0);
> } else {
> @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
> hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
> hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
> + hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> + hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> + hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> }
>
> /* Following values & calculations are same irrespective of mode type */
> @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
> hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
> hdmi_set_reg(tg->vsync, 2, 0x1);
> - hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
> - hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
> - hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->tg_3d, 1, 0x0);
> }
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi Rahul,
It looks good, at least, to me.
Best Regards,
- Seung-Woo Kim
On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
> Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
> Documentation/devicetree/bindings/video/exynos_mixer.txt |7 +--
> drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
> drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> drivers/gpu/drm/exynos/exynos_mixer.c | 12
> ++--
> 8 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required properties:
> Example:
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
> reg = <0x1445 0x1>;
> interrupts = <0 94 0>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
> b/drivers/gpu/drm/exynos/exynos_ddc.c
> index 4e9b5ba..1a0cca1 100644
> --- a/drivers/gpu/drm/exynos/exynos_ddc.c
> +++ b/drivers/gpu/drm/exynos/exynos_ddc.c
> @@ -51,7 +51,7 @@ static struct i2c_device_id ddc_idtable[] = {
> #ifdef CONFIG_OF
> static struct of_device_id hdmiddc_match_types[] = {
> {
> - .compatible = "samsung,exynos5-hdmiddc",
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Lucas Stach [mailto:l.stach at pengutronix.de] > Sent: Tuesday, June 18, 2013 6:47 PM > To: Inki Dae > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > kernel at lists.infradead.org; linux-media at vger.kernel.org > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > [...] > > > > > a display device driver. It shouldn't be used within a single driver > > > as a means of passing buffers between userspace and kernel space. > > > > What I try to do is not really such ugly thing. What I try to do is to > > notify that, when CPU tries to access a buffer , to kernel side through > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > Thanks, > > Inki Dae > > > The most basic question about why you are trying to implement this sort > of thing in the dma_buf framework still stands. > > Once you imported a dma_buf into your DRM driver it's a GEM object and > you can and should use the native DRM ioctls to prepare/end a CPU access > to this BO. Then internally to your driver you can use the dma_buf > reservation/fence stuff to provide the necessary cross-device sync. > I don't really want that is used only for DRM drivers. We really need it for all other DMA devices; i.e., v4l2 based drivers. That is what I try to do. And my approach uses reservation to use dma-buf resources but not dma fence stuff anymore. However, I'm looking into Radeon DRM driver for why we need dma fence stuff, and how we can use it if needed. Thanks, Inki Dae > Regards, > Lucas > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: ??? [mailto:sw0312.kim at samsung.com]
> Sent: Wednesday, June 19, 2013 2:34 PM
> To: Rahul Sharma
> Cc: linux-samsung-soc at vger.kernel.org; devicetree-
discuss at lists.ozlabs.org;
> dri-devel at lists.freedesktop.org; kgene.kim at samsung.com;
> inki.dae at samsung.com; joshi at samsung.com; r.sh.open at gmail.com;
> Seung-Woo
> Kim
> Subject: Re: [PATCH 3/4] drm/exynos: fix interlace resolutions for
> exynos5420
>
> Hi Rahul,
>
> This patch looks good to me.
>
> On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> > Modified code for calculating hdmi IP register values from drm timing
> > values. The modification is based on the inputs from hw team and
> specifically
> > proposed for 1440x576i and 1440x480i. But same changes holds good for
> other
> > interlaced resolutions also.
> >
> > Signed-off-by: Rahul Sharma
>
> Acked-by: Seung-Woo Kim
>
> > ---
> > drivers/gpu/drm/exynos/exynos_hdmi.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > index 8752171..2f807d5 100644
> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > (m->vsync_start - m->vdisplay) / 2);
> > hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
> > hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) /
> 2);
> > - hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
> > - ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
> > + hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay /
> 2);
> > hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
> > hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) +
> 7);
> > hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) +
> 2);
> > @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > (m->htotal / 2) + (m->hsync_start - m->hdisplay));
> > hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
> > hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
> > - hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
> > + hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
> > + hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
> > + hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
> > + hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
> > hdmi_set_reg(tg->vact_st3, 2, 0x0);
> > hdmi_set_reg(tg->vact_st4, 2, 0x0);
> > } else {
> > @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
> > hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
> > hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
> > + hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> > + hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value
> */
> > + hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value
> */
> > }
> >
> > /* Following values & calculations are same irrespective of mode
> type */
> > @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
> > hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
> > hdmi_set_reg(tg->vsync, 2, 0x1);
> > - hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
> > - hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
> > - hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->tg_3d, 1, 0x0);
> > }
> >
> >
>
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --
[PATCH] drm/prime: support to cache mapping
The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 54 +
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..ac48038 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,15 +62,29 @@ struct drm_prime_member {
struct dma_buf *dma_buf;
uint32_t handle;
};
+
+struct drm_prime_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+};
+
static int drm_prime_add_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
static int drm_gem_map_attach(struct dma_buf *dma_buf,
struct device *target_dev,
struct dma_buf_attachment *attach)
{
+ struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
+ prime_attach = kzalloc(sizeof(*prime_attach), GFP_KERNEL);
+ if (!prime_attach)
+ return -ENOMEM;
+
+ prime_attach->dir = DMA_NONE;
+ attach->priv = prime_attach;
+
if (!dev->driver->gem_prime_pin)
return 0;
@@ -80,25 +94,59 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
static void drm_gem_map_detach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
{
+ struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
+ struct sg_table *sgt;
if (dev->driver->gem_prime_unpin)
dev->driver->gem_prime_unpin(obj);
+
+ if (!prime_attach)
+ return;
+
+ sgt = prime_attach->sgt;
+
+ if (prime_attach->dir != DMA_NONE)
+ dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+ prime_attach->dir);
+
+ sg_free_table(sgt);
+ kfree(sgt);
+ kfree(prime_attach);
+ attach->priv = NULL;
}
static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
+ struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
struct sg_table *sgt;
+ if (WARN_ON(dir == DMA_NONE || !prime_attach))
+ return ERR_PTR(-EINVAL);
+
+ /* return the cached mapping when possible */
+ if (prime_attach->dir == dir)
+ return prime_attach->sgt;
+
+ /*
+* two mappings with different directions for the same attachment are
+* not allowed
+*/
+ if (WARN_ON(prime_attach->dir != DMA_NONE))
+ return ERR_PTR(-EBUSY);
+
mutex_lock(&obj->dev->struct_mutex);
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
- if (!IS_ERR_OR_NULL(sgt))
+ if (!IS_ERR_OR_NULL(sgt)) {
dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+ prime_attach->sgt = sgt;
+ prime_attach->dir = dir;
+ }
mutex_unlock(&obj->dev->struct_mutex);
return sgt;
@@ -107,9 +155,7 @@ static struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sgt, enum dma_data_direction dir)
{
- dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
- sg_free_table(sgt);
- kfree(sgt);
+ /* nothing to be done here */
}
static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
--
1.8.1.2
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
On 2013? 06? 19? 15:50, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
This patch can be merged after merging "[PATCH 1/4] drm/exynos: rename
compatible strings for hdmi subsystem".
Best Regards,
- Seung-Woo Kim
> ---
> .../devicetree/bindings/video/exynos_mixer.txt |1 +
> drivers/gpu/drm/exynos/exynos_mixer.c | 49
> +++-
> drivers/gpu/drm/exynos/regs-mixer.h|7 +++
> 3 files changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index a8b063f..c64ddc1 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: value should be:
> 1) "samsung,exynos4210-mixer"
> 2) "samsung,exynos5250-mixer"
> + 3) "samsung,exynos5420-mixer"
>
> - reg: physical base address of the mixer and length of memory mapped
> region.
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2fe6d33..d51ff36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
> enum mixer_version_id {
> MXR_VER_0_0_0_16,
> MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
> };
>
> struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> MXR_CFG_SCAN_PROGRASSIVE);
>
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>
> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
> }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
> *ctx, int win)
> /* setup geometry */
> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
> val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> mixer_cfg_layer(ctx, win, true);
>
> /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> mixer_layer_update(ctx);
>
> mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
> {
> + struct mixer_context *mixer_ctx = ctx;
> u32 w, h;
>
> w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
> drm_display_mode *mode)
> mode->hdisplay, mode->vdisplay, mode->vrefresh,
> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
> exynos_d
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
> -Original Message-
> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> Sent: Tuesday, June 18, 2013 9:50 PM
> To: linux-samsung-soc at vger.kernel.org;
devicetree-discuss at lists.ozlabs.org;
> dri-devel at lists.freedesktop.org
> Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at
> samsung.com;
> joshi at samsung.com; r.sh.open at gmail.com; Rahul Sharma
> Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
>
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
Hi Rahul,
Could you separate this patch into two patches, driver side and document
side, and the below patch also?
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
Thanks,
Inki Dae
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
> Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
> Documentation/devicetree/bindings/video/exynos_mixer.txt |7 +--
> drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
> drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> drivers/gpu/drm/exynos/exynos_mixer.c | 12
++--
> 8 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required properties:
> Example:
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compa
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
> -Original Message-
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Wednesday, June 19, 2013 4:06 PM
> To: 'Rahul Sharma'; 'linux-samsung-soc at vger.kernel.org'; 'devicetree-
> discuss at lists.ozlabs.org'; 'dri-devel at lists.freedesktop.org'
> Cc: 'kgene.kim at samsung.com'; 'sw0312.kim at samsung.com';
'joshi at samsung.com';
> 'r.sh.open at gmail.com'
> Subject: RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
>
>
>
> > -Original Message-
> > From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> > Sent: Tuesday, June 18, 2013 9:50 PM
> > To: linux-samsung-soc at vger.kernel.org; devicetree-
> discuss at lists.ozlabs.org;
> > dri-devel at lists.freedesktop.org
> > Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at
> > samsung.com;
> > joshi at samsung.com; r.sh.open at gmail.com; Rahul Sharma
> > Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> > subsystem
> >
> > This patch renames the combatible strings for hdmi, mixer, ddc
> > and hdmiphy. It follows the convention of using compatible string
> > which represent the SoC in which the IP was added for the first
> > time.
> >
>
> Hi Rahul,
>
> Could you separate this patch into two patches, driver side and document
> side, and the below patch also?
> [PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
>
Sorry, just will merge them.
To devicetree maintainers, please give me ACK.
Thanks,
Inki Dae
> Thanks,
> Inki Dae
>
> > Signed-off-by: Rahul Sharma
> > ---
> > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
--
> > Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> > Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6
--
> > Documentation/devicetree/bindings/video/exynos_mixer.txt |7
+--
> > drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> > drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
> > drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> > drivers/gpu/drm/exynos/exynos_mixer.c | 12
++-
> -
> > 8 files changed, 26 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > index 589edee..2ac01ca 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > @@ -1,7 +1,9 @@
> > Device-Tree bindings for drm hdmi driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmi".
> > +- compatible: value should be one among the following:
> > + 1) "samsung,exynos4210-hdmi"
> > + 2) "samsung,exynos4212-hdmi"
> > - reg: physical base address of the hdmi and length of memory mapped
> > region.
> > - interrupts: interrupt number to the cpu.
> > @@ -15,7 +17,7 @@ Required properties:
> > Example:
> >
> > hdmi {
> > - compatible = "samsung,exynos5-hdmi";
> > + compatible = "samsung,exynos4212-hdmi";
> > reg = <0x1453 0x10>;
> > interrupts = <0 95 0>;
> > hpd-gpio = <&gpx3 7 0xf 1 3>;
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > index fa166d9..c1bd2ea 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > @@ -1,12 +1,12 @@
> > Device-Tree bindings for hdmiddc driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmiddc".
> > +- compatible: value should be "samsung,exynos4210-hdmiddc".
> > - reg: I2C address of the hdmiddc device.
> >
> > Example:
> >
> > hdmiddc {
> > - compatible = "samsung,exynos5-hdmiddc";
> > + compatible = "samsung,exynos4210-hdmiddc";
> > reg = <0x50>;
> > };
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > index 858f4f9..e59d793 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > @@ -1,12 +1,14 @@
> > Device-Tree bindings for hdmiphy driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmiphy".
> > +- compatible: value should be
> > + 1) "samsung,exynos4210-hdmiphy".
> > + 2) "samsung,exynos4212-hdmiphy".
> > - reg: I2C address of the hdmiphy device.
> >
> > Example:
> >
> > hdmiphy {
> > - compatible = "samsung,exynos5-hdmiphy";
> > + compatible = "samsung,exynos4210-hdmiphy";
> > reg = <0x38>;
> > };
> > diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> > b/Documentation/devicetree
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #72 from Marc Dietrich --- yup, heaven works, kronos test suite reports doesn't crash anymore, but fail (misrenders) on sin/cos as expected. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/cc4c06e3/attachment.html>
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi Rahul,
On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
>2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
> ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
Sorry, but it's a NAK from me.
DeviceTree bindings are considered an ABI. This is to allow older dtbs to
work with new kernels.
If you just change the binding this way, you break all the existing users
of this compatible value.
In addition you are doing it in a way that breaks bisection:
- patch 1/4 breaks existing in-tree users of current compatible values,
- after patch 2 and 3 it is still broken,
- and eventually all in-tree users are fixed by patch 4 (but you can't
fix out-of-tree users).
Please do it without changing existing compatible values. Even if they are
misleading, this is all can be described in the documentation - just list
SoCs that can be used with each compatible value there.
Best regards,
Tomasz
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt index
> fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt index
> 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt index
> 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required proper
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> Hi Rahul,
>
> On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> > This patch renames the combatible strings for hdmi, mixer, ddc
> > and hdmiphy. It follows the convention of using compatible string
> > which represent the SoC in which the IP was added for the first
> > time.
> >
> > Signed-off-by: Rahul Sharma
> > ---
> > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
> >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> > +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
> > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> > 589edee..2ac01ca 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > @@ -1,7 +1,9 @@
> > Device-Tree bindings for drm hdmi driver
> >
> > Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmi".
> > +- compatible: value should be one among the following:
> > + 1) "samsung,exynos4210-hdmi"
> > + 2) "samsung,exynos4212-hdmi"
> > - reg: physical base address of the hdmi and length of memory mapped
> > region.
> > - interrupts: interrupt number to the cpu.
> > @@ -15,7 +17,7 @@ Required properties:
> > Example:
> >
> > hdmi {
> > - compatible = "samsung,exynos5-hdmi";
> > + compatible = "samsung,exynos4212-hdmi";
>
> Sorry, but it's a NAK from me.
>
> DeviceTree bindings are considered an ABI. This is to allow older dtbs to
> work with new kernels.
>
> If you just change the binding this way, you break all the existing users
> of this compatible value.
>
> In addition you are doing it in a way that breaks bisection:
> - patch 1/4 breaks existing in-tree users of current compatible values,
> - after patch 2 and 3 it is still broken,
> - and eventually all in-tree users are fixed by patch 4 (but you can't
> fix out-of-tree users).
>
> Please do it without changing existing compatible values. Even if they are
> misleading, this is all can be described in the documentation - just list
> SoCs that can be used with each compatible value there.
>
Or you could just introduce the new compatible value and make all
in-tree users use this, but keep the old values around and still accept
them in the drivers. This way you get the goodness of the cleaner new
symbols without breaking existing users. Just mark the old values as
deprecated in the documentation, so no new devicetree usees them.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Lucas Stach
> Sent: Wednesday, June 19, 2013 4:59 PM
> To: Tomasz Figa
> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
> sw0312.kim at samsung.com; joshi at samsung.com;
dri-devel at lists.freedesktop.org;
> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
>
> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> > Hi Rahul,
> >
> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> > > This patch renames the combatible strings for hdmi, mixer, ddc
> > > and hdmiphy. It follows the convention of using compatible string
> > > which represent the SoC in which the IP was added for the first
> > > time.
> > >
> > > Signed-off-by: Rahul Sharma
> > > ---
> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
|
> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> > > 589edee..2ac01ca 100644
> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > @@ -1,7 +1,9 @@
> > > Device-Tree bindings for drm hdmi driver
> > >
> > > Required properties:
> > > -- compatible: value should be "samsung,exynos5-hdmi".
> > > +- compatible: value should be one among the following:
> > > + 1) "samsung,exynos4210-hdmi"
> > > + 2) "samsung,exynos4212-hdmi"
> > > - reg: physical base address of the hdmi and length of memory mapped
> > > region.
> > > - interrupts: interrupt number to the cpu.
> > > @@ -15,7 +17,7 @@ Required properties:
> > > Example:
> > >
> > > hdmi {
> > > - compatible = "samsung,exynos5-hdmi";
> > > + compatible = "samsung,exynos4212-hdmi";
> >
> > Sorry, but it's a NAK from me.
> >
> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
> to
> > work with new kernels.
> >
> > If you just change the binding this way, you break all the existing
> users
> > of this compatible value.
> >
> > In addition you are doing it in a way that breaks bisection:
> > - patch 1/4 breaks existing in-tree users of current compatible values,
> > - after patch 2 and 3 it is still broken,
> > - and eventually all in-tree users are fixed by patch 4 (but you can't
> > fix out-of-tree users).
> >
> > Please do it without changing existing compatible values. Even if they
> are
> > misleading, this is all can be described in the documentation - just
> list
> > SoCs that can be used with each compatible value there.
> >
>
> Or you could just introduce the new compatible value and make all
> in-tree users use this, but keep the old values around and still accept
> them in the drivers. This way you get the goodness of the cleaner new
> symbols without breaking existing users. Just mark the old values as
> deprecated in the documentation, so no new devicetree usees them.
>
That's a good idea. We really need to mitigate such misleading somehow or
other.
Thanks,
Inki Dae
> Regards,
> Lucas
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v3] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v3: - remove cache operation relevant codes and update document file. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R); ... And the below can be used as access types: DMA_BUF_ACCESS_R - CPU will access a buffer for read. DMA_BUF_ACCESS_W - CPU will access a buffer for read or write. DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94 https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi All,
On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae wrote:
>
>
>> -Original Message-
>> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
>> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
>> Behalf Of Lucas Stach
>> Sent: Wednesday, June 19, 2013 4:59 PM
>> To: Tomasz Figa
>> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
>> sw0312.kim at samsung.com; joshi at samsung.com;
> dri-devel at lists.freedesktop.org;
>> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
>> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
>> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
>> subsystem
>>
>> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
>> > Hi Rahul,
>> >
>> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
>> > > This patch renames the combatible strings for hdmi, mixer, ddc
>> > > and hdmiphy. It follows the convention of using compatible string
>> > > which represent the SoC in which the IP was added for the first
>> > > time.
>> > >
>> > > Signed-off-by: Rahul Sharma
>> > > ---
>> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
>> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
>> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
>> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
>> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
> |
>> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
>> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
>> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c | 12
>> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
>> > > 589edee..2ac01ca 100644
>> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > @@ -1,7 +1,9 @@
>> > > Device-Tree bindings for drm hdmi driver
>> > >
>> > > Required properties:
>> > > -- compatible: value should be "samsung,exynos5-hdmi".
>> > > +- compatible: value should be one among the following:
>> > > + 1) "samsung,exynos4210-hdmi"
>> > > + 2) "samsung,exynos4212-hdmi"
>> > > - reg: physical base address of the hdmi and length of memory mapped
>> > > region.
>> > > - interrupts: interrupt number to the cpu.
>> > > @@ -15,7 +17,7 @@ Required properties:
>> > > Example:
>> > >
>> > > hdmi {
>> > > - compatible = "samsung,exynos5-hdmi";
>> > > + compatible = "samsung,exynos4212-hdmi";
>> >
>> > Sorry, but it's a NAK from me.
>> >
>> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
>> to
>> > work with new kernels.
>> >
>> > If you just change the binding this way, you break all the existing
>> users
>> > of this compatible value.
>> >
>> > In addition you are doing it in a way that breaks bisection:
>> > - patch 1/4 breaks existing in-tree users of current compatible values,
>> > - after patch 2 and 3 it is still broken,
>> > - and eventually all in-tree users are fixed by patch 4 (but you can't
>> > fix out-of-tree users).
>> >
@Tomasz, I understand your point but how is it possible to change
compatible types in driver as well as in dtbs by not breaking either of them
other then putting changes in a single patch. I ensured that hdmi stuff is
intact with whole series merged in either tree (drm or arch). Please suggest
a better way.
The Only existing user is Exynos5250, which is modified in the same patch
set.
>> > Please do it without changing existing compatible values. Even if they
>> are
>> > misleading, this is all can be described in the documentation - just
>> list
>> > SoCs that can be used with each compatible value there.
>> >
>>
>> Or you could just introduce the new compatible value and make all
>> in-tree users use this, but keep the old values around and still accept
>> them in the drivers. This way you get the goodness of the cleaner new
>> symbols without breaking existing users. Just mark the old values as
>> deprecated in the documentation, so no new devicetree usees them.
>>
I agree, above is a decent approach, but in this case we have only one
user for this compatible type including in flight patches which I have
modified along.
If it seems better to keep old compatible type (deprecated), it is fine
with me.
>
> That's a good idea. We really need to mitigate such misleading somehow or
> other.
Please sugggest me how to proceed.
regards,
Rahul Sharma.
>
> Thanks,
> Inki Dae
>
>> Regards,
>> Lucas
>> --
>> Pengutronix e.K. | Lucas Stach |
>> Industrial Linux Solutions | http://www.pengutronix.de/ |
>> Peiner Str. 6-8, 31137 Hildesheim, Germany
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi Rahul,
On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
> Hi All,
>
> On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae wrote:
> >> -Original Message-
> >> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> >> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> >> Behalf Of Lucas Stach
> >> Sent: Wednesday, June 19, 2013 4:59 PM
> >> To: Tomasz Figa
> >> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
> >> sw0312.kim at samsung.com; joshi at samsung.com;
> >
> > dri-devel at lists.freedesktop.org;
> >
> >> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
> >> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
> >> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> >> subsystem
> >>
> >> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> >> > Hi Rahul,
> >> >
> >> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> >> > > This patch renames the combatible strings for hdmi, mixer, ddc
> >> > > and hdmiphy. It follows the convention of using compatible string
> >> > > which represent the SoC in which the IP was added for the first
> >> > > time.
> >> > >
> >> > > Signed-off-by: Rahul Sharma
> >> > > ---
> >> > >
> >> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> >> > >
> >> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> >> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> >> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
> >> > >
> >> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
> >> > >
> >> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
> >> > >
> >> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|
> >> > > 4
> >> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c |
> >> > > 12
> >> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> >> > >
> >> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> >> > > 589edee..2ac01ca 100644
> >> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > @@ -1,7 +1,9 @@
> >> > >
> >> > > Device-Tree bindings for drm hdmi driver
> >> > >
> >> > > Required properties:
> >> > > -- compatible: value should be "samsung,exynos5-hdmi".
> >> > > +- compatible: value should be one among the following:
> >> > > + 1) "samsung,exynos4210-hdmi"
> >> > > + 2) "samsung,exynos4212-hdmi"
> >> > >
> >> > > - reg: physical base address of the hdmi and length of memory mapped
> >> > >
> >> > > region.
> >> > >
> >> > > - interrupts: interrupt number to the cpu.
> >> > >
> >> > > @@ -15,7 +17,7 @@ Required properties:
> >> > > Example:
> >> > > hdmi {
> >> > >
> >> > > - compatible = "samsung,exynos5-hdmi";
> >> > > + compatible = "samsung,exynos4212-hdmi";
> >> >
> >> > Sorry, but it's a NAK from me.
> >> >
> >> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
> >>
> >> to
> >>
> >> > work with new kernels.
> >> >
> >> > If you just change the binding this way, you break all the existing
> >>
> >> users
> >>
> >> > of this compatible value.
> >> >
> >> > In addition you are doing it in a way that breaks bisection:
> >> > - patch 1/4 breaks existing in-tree users of current compatible
> >> > values,
> >> > - after patch 2 and 3 it is still broken,
> >> > - and eventually all in-tree users are fixed by patch 4 (but you can't
> >> >
> >> > fix out-of-tree users).
>
> @Tomasz, I understand your point but how is it possible to change
> compatible types in driver as well as in dtbs by not breaking either of them
> other then putting changes in a single patch.
It's very easy. (Let's forget about the fact that DT bindings are an ABI
temporarily) You can simply add new compatible values to the driver in first
patch, then modify dts files in second one and then remove old compatibles
values from the driver in third patch. (Now we remember about DT being ABI
again.)
> I ensured that hdmi stuff is
> intact with whole series merged in either tree (drm or arch). Please
> suggest a better way.
>
> The Only existing user is Exynos5250, which is modified in the same patch
> set.
This is not true. You have modified only the existing _in_ _tree_ users.
Keep in mind that device tree is not a part of the kernel. It is currently
located in the same tree, but it is _not_ a part of the kernel.
Now think about existing boards (like exynos5250-snow) that have a dtb built
from older dts sources stored in their flash memory. You need to maintain
compatibilty with this old dtb in new kernels as well.
> >> > Please do it without changing existing compatible values. Even if they
> >>
> >> ar
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > -Original Message- > > From: Lucas Stach [mailto:l.stach at pengutronix.de] > > Sent: Tuesday, June 18, 2013 6:47 PM > > To: Inki Dae > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > kernel at lists.infradead.org; linux-media at vger.kernel.org > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > > framework > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > [...] > > > > > > > a display device driver. It shouldn't be used within a single driver > > > > as a means of passing buffers between userspace and kernel space. > > > > > > What I try to do is not really such ugly thing. What I try to do is to > > > notify that, when CPU tries to access a buffer , to kernel side through > > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > > > Thanks, > > > Inki Dae > > > > > The most basic question about why you are trying to implement this sort > > of thing in the dma_buf framework still stands. > > > > Once you imported a dma_buf into your DRM driver it's a GEM object and > > you can and should use the native DRM ioctls to prepare/end a CPU access > > to this BO. Then internally to your driver you can use the dma_buf > > reservation/fence stuff to provide the necessary cross-device sync. > > > > I don't really want that is used only for DRM drivers. We really need > it for all other DMA devices; i.e., v4l2 based drivers. That is what I > try to do. And my approach uses reservation to use dma-buf resources > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > driver for why we need dma fence stuff, and how we can use it if > needed. > Still I don't see the point why you need syncpoints above dma-buf. In both the DRM and the V4L2 world we have defined points in the API where a buffer is allowed to change domain from device to CPU and vice versa. In DRM if you want to access a buffer with the CPU you do a cpu_prepare. The buffer changes back to GPU domain once you do the execbuf validation, queue a pageflip to the buffer or similar things. In V4L2 the syncpoints for cache operations are the queue/dequeue API entry points. Those are also the exact points to synchronize with other hardware thus using dma-buf reserve/fence. In all this I can't see any need for a new syncpoint primitive slapped on top of dma-buf. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
On Wed, Jun 19, 2013 at 3:20 PM, Tomasz Figa wrote:
> Hi Rahul,
>
> On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
>> Hi All,
>>
>> On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae wrote:
>> >> -Original Message-
>> >> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
>> >> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org]
>> >> On
>> >> Behalf Of Lucas Stach
>> >> Sent: Wednesday, June 19, 2013 4:59 PM
>> >> To: Tomasz Figa
>> >> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
>> >> sw0312.kim at samsung.com; joshi at samsung.com;
>> >
>> > dri-devel at lists.freedesktop.org;
>> >
>> >> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
>> >> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
>> >> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
>> >> subsystem
>> >>
>> >> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
>> >> > Hi Rahul,
>> >> >
>> >> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
>> >> > > This patch renames the combatible strings for hdmi, mixer, ddc
>> >> > > and hdmiphy. It follows the convention of using compatible string
>> >> > > which represent the SoC in which the IP was added for the first
>> >> > > time.
>> >> > >
>> >> > > Signed-off-by: Rahul Sharma
>> >> > > ---
>> >> > >
>> >> > > Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
>> >> > >
>> >> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
>> >> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
>> >> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt |
>> >> > >
>> >> > > 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
>> >> > >
>> >> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c |
>> >> > >
>> >> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|
>> >> > > 4
>> >> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c |
>> >> > > 12
>> >> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>> >> > >
>> >> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
>> >> > > 589edee..2ac01ca 100644
>> >> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > @@ -1,7 +1,9 @@
>> >> > >
>> >> > > Device-Tree bindings for drm hdmi driver
>> >> > >
>> >> > > Required properties:
>> >> > > -- compatible: value should be "samsung,exynos5-hdmi".
>> >> > > +- compatible: value should be one among the following:
>> >> > > + 1) "samsung,exynos4210-hdmi"
>> >> > > + 2) "samsung,exynos4212-hdmi"
>> >> > >
>> >> > > - reg: physical base address of the hdmi and length of memory mapped
>> >> > >
>> >> > > region.
>> >> > >
>> >> > > - interrupts: interrupt number to the cpu.
>> >> > >
>> >> > > @@ -15,7 +17,7 @@ Required properties:
>> >> > > Example:
>> >> > > hdmi {
>> >> > >
>> >> > > - compatible = "samsung,exynos5-hdmi";
>> >> > > + compatible = "samsung,exynos4212-hdmi";
>> >> >
>> >> > Sorry, but it's a NAK from me.
>> >> >
>> >> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
>> >>
>> >> to
>> >>
>> >> > work with new kernels.
>> >> >
>> >> > If you just change the binding this way, you break all the existing
>> >>
>> >> users
>> >>
>> >> > of this compatible value.
>> >> >
>> >> > In addition you are doing it in a way that breaks bisection:
>> >> > - patch 1/4 breaks existing in-tree users of current compatible
>> >> > values,
>> >> > - after patch 2 and 3 it is still broken,
>> >> > - and eventually all in-tree users are fixed by patch 4 (but you can't
>> >> >
>> >> > fix out-of-tree users).
>>
>> @Tomasz, I understand your point but how is it possible to change
>> compatible types in driver as well as in dtbs by not breaking either of them
>> other then putting changes in a single patch.
>
> It's very easy. (Let's forget about the fact that DT bindings are an ABI
> temporarily) You can simply add new compatible values to the driver in first
> patch, then modify dts files in second one and then remove old compatibles
> values from the driver in third patch. (Now we remember about DT being ABI
> again.)
>
>> I ensured that hdmi stuff is
>> intact with whole series merged in either tree (drm or arch). Please
>> suggest a better way.
>>
>> The Only existing user is Exynos5250, which is modified in the same patch
>> set.
>
> This is not true. You have modified only the existing _in_ _tree_ users.
>
> Keep in mind that device tree is not a part of the kernel. It is currently
> located in the same tree, but it is _not_ a part of the kernel.
>
> Now think about existing boards (like exynos5250-snow) that have a dtb built
> from older dts sources stored in their flash memory. You need to maint
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Lucas Stach [mailto:l.stach at pengutronix.de] > Sent: Wednesday, June 19, 2013 7:22 PM > To: Inki Dae > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > kernel at lists.infradead.org; linux-media at vger.kernel.org > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > > > -Original Message- > > > From: Lucas Stach [mailto:l.stach at pengutronix.de] > > > Sent: Tuesday, June 18, 2013 6:47 PM > > > To: Inki Dae > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > > kernel at lists.infradead.org; linux-media at vger.kernel.org > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > synchronization > > > framework > > > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > > [...] > > > > > > > > > a display device driver. It shouldn't be used within a single > driver > > > > > as a means of passing buffers between userspace and kernel space. > > > > > > > > What I try to do is not really such ugly thing. What I try to do is > to > > > > notify that, when CPU tries to access a buffer , to kernel side > through > > > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > > > > > Thanks, > > > > Inki Dae > > > > > > > The most basic question about why you are trying to implement this > sort > > > of thing in the dma_buf framework still stands. > > > > > > Once you imported a dma_buf into your DRM driver it's a GEM object and > > > you can and should use the native DRM ioctls to prepare/end a CPU > access > > > to this BO. Then internally to your driver you can use the dma_buf > > > reservation/fence stuff to provide the necessary cross-device sync. > > > > > > > I don't really want that is used only for DRM drivers. We really need > > it for all other DMA devices; i.e., v4l2 based drivers. That is what I > > try to do. And my approach uses reservation to use dma-buf resources > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > > driver for why we need dma fence stuff, and how we can use it if > > needed. > > > > Still I don't see the point why you need syncpoints above dma-buf. In > both the DRM and the V4L2 world we have defined points in the API where > a buffer is allowed to change domain from device to CPU and vice versa. > > In DRM if you want to access a buffer with the CPU you do a cpu_prepare. > The buffer changes back to GPU domain once you do the execbuf > validation, queue a pageflip to the buffer or similar things. > > In V4L2 the syncpoints for cache operations are the queue/dequeue API > entry points. Those are also the exact points to synchronize with other > hardware thus using dma-buf reserve/fence. If so, what if we want to access a buffer with the CPU _in V4L2_? We should open a drm device node, and then do a cpu_prepare? Thanks, Inki Dae > > In all this I can't see any need for a new syncpoint primitive slapped > on top of dma-buf. > > Regards, > Lucas > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] drm/shmobile: Enable compilation on all ARM platforms
This is required to support multi-arch kernels. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/shmobile/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig index 7e7d52b..62905b4 100644 --- a/drivers/gpu/drm/shmobile/Kconfig +++ b/drivers/gpu/drm/shmobile/Kconfig @@ -1,6 +1,6 @@ config DRM_SHMOBILE tristate "DRM Support for SH Mobile" - depends on DRM && (SUPERH || ARCH_SHMOBILE) + depends on DRM && (ARM || SUPERH) select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER -- Regards, Laurent Pinchart
[PATCH v4] drm: Renesas R-Car Display Unit DRM driver
The R-Car Display Unit (DU) DRM driver supports both superposition processors and all eight planes in RGB and YUV formats with alpha blending. Only VGA and LVDS encoders and connectors are currently supported. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/rcar-du/Kconfig | 9 + drivers/gpu/drm/rcar-du/Makefile| 8 + drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 595 drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 50 +++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 325 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 66 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 245 + drivers/gpu/drm/rcar-du/rcar_du_kms.h | 59 drivers/gpu/drm/rcar-du/rcar_du_lvds.c | 216 drivers/gpu/drm/rcar-du/rcar_du_lvds.h | 24 ++ drivers/gpu/drm/rcar-du/rcar_du_plane.c | 507 +++ drivers/gpu/drm/rcar-du/rcar_du_plane.h | 67 drivers/gpu/drm/rcar-du/rcar_du_regs.h | 445 drivers/gpu/drm/rcar-du/rcar_du_vga.c | 149 drivers/gpu/drm/rcar-du/rcar_du_vga.h | 24 ++ include/linux/platform_data/rcar-du.h | 54 +++ 18 files changed, 2846 insertions(+) create mode 100644 drivers/gpu/drm/rcar-du/Kconfig create mode 100644 drivers/gpu/drm/rcar-du/Makefile create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_regs.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.h create mode 100644 include/linux/platform_data/rcar-du.h Changes since v3: - Use drm_send_vblank_event() - Enable compilation on all ARM platforms - Don't add default modes to VGA connector Changes since v2: - Enable the DE signal - Split hardware and KMS planes - Add support for the second CRTC - Name the encoder platform data union - Fix crash when disabling an already disabled plane - Prepare/unprepare clock - Centralize DU device core resource management - Reorganize CRTC start/stop and power management code - Create common encoder and connector structures - Add support for cloned mode on DU1 - Add XRGB1555 format support - Add plane property to set global alpha value - Don't modify mode active size in encoder fixup - Use the mode active size in mode set - Take offsets into account in the mode_set_base handler - Fix plane source position configuration - Don't clean up mode setting if it hasn't been initialized - Enable extended range for display timings Changes since v1: - Use drm_encoder_cleanup() directly as .destroy handlers - Enable alpha blending support - Don't re-reserve hardware plane at each update - Fix planes allocation for multiplanar formats - Add DRM PRIME support - Fix race condition between page flip request and handler - Add configurable z-order support for planes - Support configurable color keying for planes - Update plane format after releasing hardware planes - Fix register access for global registers - Fix plane index wrap-around for multi-planar overlays diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index b16c50e..71ca63b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -213,6 +213,8 @@ source "drivers/gpu/drm/mgag200/Kconfig" source "drivers/gpu/drm/cirrus/Kconfig" +source "drivers/gpu/drm/rcar-du/Kconfig" + source "drivers/gpu/drm/shmobile/Kconfig" source "drivers/gpu/drm/omapdrm/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1ecbe5b..801bcaf 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -49,6 +49,7 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/ obj-$(CONFIG_DRM_GMA500) += gma500/ obj-$(CONFIG_DRM_UDL) += udl/ obj-$(CONFIG_DRM_AST) += ast/ +obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-$(CONFIG_DRM_OMAP) += omapdrm/ obj-$(CONFIG_DRM_TILCDC) += tilcdc/ diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig new file mode 100644 index 000..72887df --- /dev/null +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -0,0 +1,9 @@ +config DRM_RCAR_DU + tristate "DRM Support for R-Car Display Unit" + depends on DRM && ARM + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + help + Choos
[PATCH] drm: Improve manual IRQ installation documentation
Signed-off-by: Laurent Pinchart --- Documentation/DocBook/drm.tmpl | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index f9df3b8..738b727 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -186,11 +186,12 @@ DRIVER_HAVE_IRQDRIVER_IRQ_SHARED - DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. The - DRM core will automatically register an interrupt handler when the - flag is set. DRIVER_IRQ_SHARED indicates whether the device & - handler support shared IRQs (note that this is required of PCI - drivers). + DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler + managed by the DRM Core. The core will support simple IRQ handler + installation when the flag is set. The installation process is + described in . + DRIVER_IRQ_SHARED indicates whether the device & handler + support shared IRQs (note that this is required of PCI drivers). @@ -344,7 +345,8 @@ char *date; The DRM core tries to facilitate IRQ handler registration and unregistration by providing drm_irq_install and drm_irq_uninstall functions. Those functions only - support a single interrupt per device. + support a single interrupt per device, devices that use more than one + IRQs need to be handled manually. -- Regards, Laurent Pinchart
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae: > > > -Original Message- > > From: Lucas Stach [mailto:l.stach at pengutronix.de] > > Sent: Wednesday, June 19, 2013 7:22 PM > > To: Inki Dae > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > kernel at lists.infradead.org; linux-media at vger.kernel.org > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > > framework > > > > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae: > > > > > > > -Original Message- > > > > From: Lucas Stach [mailto:l.stach at pengutronix.de] > > > > Sent: Tuesday, June 18, 2013 6:47 PM > > > > To: Inki Dae > > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > > > > kernel at lists.infradead.org; linux-media at vger.kernel.org > > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > > synchronization > > > > framework > > > > > > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > > > > [...] > > > > > > > > > > > a display device driver. It shouldn't be used within a single > > driver > > > > > > as a means of passing buffers between userspace and kernel space. > > > > > > > > > > What I try to do is not really such ugly thing. What I try to do is > > to > > > > > notify that, when CPU tries to access a buffer , to kernel side > > through > > > > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > > > > > > > Thanks, > > > > > Inki Dae > > > > > > > > > The most basic question about why you are trying to implement this > > sort > > > > of thing in the dma_buf framework still stands. > > > > > > > > Once you imported a dma_buf into your DRM driver it's a GEM object and > > > > you can and should use the native DRM ioctls to prepare/end a CPU > > access > > > > to this BO. Then internally to your driver you can use the dma_buf > > > > reservation/fence stuff to provide the necessary cross-device sync. > > > > > > > > > > I don't really want that is used only for DRM drivers. We really need > > > it for all other DMA devices; i.e., v4l2 based drivers. That is what I > > > try to do. And my approach uses reservation to use dma-buf resources > > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM > > > driver for why we need dma fence stuff, and how we can use it if > > > needed. > > > > > > > Still I don't see the point why you need syncpoints above dma-buf. In > > both the DRM and the V4L2 world we have defined points in the API where > > a buffer is allowed to change domain from device to CPU and vice versa. > > > > In DRM if you want to access a buffer with the CPU you do a cpu_prepare. > > The buffer changes back to GPU domain once you do the execbuf > > validation, queue a pageflip to the buffer or similar things. > > > > In V4L2 the syncpoints for cache operations are the queue/dequeue API > > entry points. Those are also the exact points to synchronize with other > > hardware thus using dma-buf reserve/fence. > > > If so, what if we want to access a buffer with the CPU _in V4L2_? We > should open a drm device node, and then do a cpu_prepare? > Not at all. As I said the syncpoints are the queue/dequeue operations. When dequeueing a buffer you are explicitly dragging the buffer domain back from device into userspace and thus CPU domain. If you are operating on an mmap of a V4L2 processed buffer it's either before or after it got processed by the hardware and therefore all DMA operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls. That is where cache operations and synchronization should happen. The V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it back into CPU domain while there is still DMA ongoing. Equally the queue ioctrl should make sure caches are properly written back to memory. The results of reading/writing to the mmap of a V4L2 buffer while it is enqueued to the hardware is simply undefined and there is nothing suggesting that this is a valid usecase. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] drm/radeon: update lockup tracking when scheduling in empty ring
From: Jerome Glisse
There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.
Signed-off-by: Jerome Glisse
Tested-by: Andy Lutomirski
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index e17faa7..82434018 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct
radeon_ring *ring, unsi
return -ENOMEM;
/* Align requested size with padding so unlock_commit can
* pad safely */
+ radeon_ring_free_size(rdev, ring);
+ if (ring->ring_free_dw == (ring->ring_size / 4)) {
+ /* This is an empty ring update lockup info to avoid
+* false positive.
+*/
+ radeon_ring_lockup_update(ring);
+ }
ndw = (ndw + ring->align_mask) & ~ring->align_mask;
while (ndw > (ring->ring_free_dw - 1)) {
radeon_ring_free_size(rdev, ring);
--
1.7.11.7
[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.
https://bugzilla.kernel.org/show_bug.cgi?id=59761 --- Comment #2 from t3st3r at mail.ru 2013-06-19 14:36:31 --- Quite hard/time consuming for me at this point. But if no other options left, I probably can try since this bug is quite annoying. Right now I know that MESA 9.0.x has been working perfectly with that HD5770. But MESA 9.1 and up (9.2 git, etc) are broken. This also seems to produce some visually visible artifacts on textured objects in mentioned "Ryzom" game. Say, "metallic" objects However as for kernel itself - the problem is that kernel detects lock-up but then EPIC FAILs when trying to reset GPU. I bet there should be no "BUG: unable to handle kernel paging request" at very least. Then, kernel never manages to recover from this condition. Neither old 3.8 kernel, nor recent changed GPU reset code from 3.9/3.10 would work. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] drm/shmobile: Drop usage of removed drm_plane enabled field
The enabled field has been removed from struct drm_plane. Don't use it
in the driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This fixes a compilation error in drm-next. I will send a pull request for the
shmob-drm patches by the end of the week.
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
index 6898f6f..060ae03 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
@@ -166,7 +166,7 @@ void shmob_drm_plane_setup(struct drm_plane *plane)
{
struct shmob_drm_plane *splane = to_shmob_plane(plane);
- if (plane->fb == NULL || !plane->enabled)
+ if (plane->fb == NULL)
return;
__shmob_drm_plane_setup(splane, plane->fb);
--
Regards,
Laurent Pinchart
[PATCH] drm/radeon: update lockup tracking when scheduling in empty ring
Am 19.06.2013 16:02, schrieb j.glisse at gmail.com:
> From: Jerome Glisse
>
> There might be issue with lockup detection when scheduling on an
> empty ring that have been sitting idle for a while. Thus update
> the lockup tracking data when scheduling new work in an empty ring.
>
> Signed-off-by: Jerome Glisse
> Tested-by: Andy Lutomirski
> Cc: stable at vger.kernel.org
Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index e17faa7..82434018 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct
> radeon_ring *ring, unsi
> return -ENOMEM;
> /* Align requested size with padding so unlock_commit can
>* pad safely */
> + radeon_ring_free_size(rdev, ring);
> + if (ring->ring_free_dw == (ring->ring_size / 4)) {
> + /* This is an empty ring update lockup info to avoid
> + * false positive.
> + */
> + radeon_ring_lockup_update(ring);
> + }
> ndw = (ndw + ring->align_mask) & ~ring->align_mask;
> while (ndw > (ring->ring_free_dw - 1)) {
> radeon_ring_free_size(rdev, ring);
[PATCH 1/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.
On 13-06-17 09:19 AM, Julia Lemire wrote:
> +static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode *
> mode,
> + int bits_per_pixel)
> +{
> + uint64_t active_area, total_area, pixels_per_second;
> + uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
> +
> + if(!mode->htotal || !mode->vtotal || !mode->clock)
> + return 0;
> +
> + active_area = mode->hdisplay * mode->vdisplay;
> + total_area = mode->htotal * mode->vtotal;
> + pixels_per_second = active_area * mode->clock * 1000 / total_area;
> + return (uint32_t)(pixels_per_second * bytes_per_pixel * 100 / (1024));
> +}
I found a bug while testing this on a 32-bit machine linked to the
64-bit division. Sorry.
--
Julia Lemire Jr. Eng./Ing.
Software Designer
Matrox Graphics Inc.
Phone : 514 822-6000 x7010
Email :julia.lemire at matrox.com
[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #10 from Jerome Glisse --- What is the motherboard and cpu reference ? AMD A4-3400 ? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/bff6148a/attachment.html>
[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)
https://bugs.freedesktop.org/show_bug.cgi?id=63599 --- Comment #11 from wojtek --- Motherboard: Gigabyte Technology Co., Ltd. GA-A75M-UD2H/GA-A75M-UD2H, BIOS F5 11/03/2011 CPU: AMD A4-3400 APU with Radeon(tm) HD Graphics (fam: 12, model: 01, stepping: 00) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/fffde289/attachment.html>
[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
Thanks Mr. Kim,
I will post v4 with aforesaid change.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim wrote:
> On 06/19/13 22:50, Kukjin Kim wrote:
>>
>> On 06/19/13 21:51, Rahul Sharma wrote:
>>>
>>> This patch renames the combatible strings for hdmi, mixer, ddc
>>> and hdmiphy. It follows the convention of using compatible string
>>> which represent the SoC in which the IP was added for the first
>>> time.
>>>
>>> Signed-off-by: Rahul Sharma
>>
>>
>> Acked-by: Kukjin Kim
>>
>
> Just one nit in subject:
>
> [PATCH] ARM: dts: . for exynos5250
>
> Thanks,
>
> - Kukjin
>
>>> ---
>>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>>> b/arch/arm/boot/dts/cros5250-common.dtsi
>>> index 3f0239e..dc259e8b 100644
>>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>>> @@ -190,7 +190,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc at 50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -224,7 +224,7 @@
>>> samsung,i2c-max-bus-freq =<378000>;
>>>
>>> hdmiphy at 38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> index 3e0c792..f320d7c 100644
>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> @@ -72,7 +72,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc at 50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -102,7 +102,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiphy at 38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 0673524..2f7763b 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -601,7 +601,7 @@
>>> };
>>>
>>> hdmi {
>>> - compatible = "samsung,exynos5-hdmi";
>>> + compatible = "samsung,exynos4212-hdmi";
>>> reg =<0x1453 0x7>;
>>> interrupts =<0 95 0>;
>>> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
>>> @@ -611,7 +611,7 @@
>>> };
>>>
>>> mixer {
>>> - compatible = "samsung,exynos5-mixer";
>>> + compatible = "samsung,exynos5250-mixer";
>>> reg =<0x1445 0x1>;
>>> interrupts =<0 94 0>;
>>> };
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #14 from Alex Deucher --- I'd suggest sending it to the mailing list (mesa-dev at lists.freedesktop.org). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/2c7d276c/attachment.html>
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #15 from Alex Deucher --- Please use git to format the patch and include a description of what the patch does and how it fixes the issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/7f3f3987/attachment.html>
[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 21:51, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma
Acked-by: Kukjin Kim
- Kukjin
> ---
> arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
> arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
> arch/arm/boot/dts/exynos5250.dtsi |4 ++--
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 3f0239e..dc259e8b 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -190,7 +190,7 @@
> samsung,i2c-max-bus-freq =<66000>;
>
> hdmiddc at 50 {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg =<0x50>;
> };
> };
> @@ -224,7 +224,7 @@
> samsung,i2c-max-bus-freq =<378000>;
>
> hdmiphy at 38 {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4212-hdmiphy";
> reg =<0x38>;
> };
> };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 3e0c792..f320d7c 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -72,7 +72,7 @@
> samsung,i2c-max-bus-freq =<66000>;
>
> hdmiddc at 50 {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg =<0x50>;
> };
> };
> @@ -102,7 +102,7 @@
> samsung,i2c-max-bus-freq =<66000>;
>
> hdmiphy at 38 {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4212-hdmiphy";
> reg =<0x38>;
> };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 0673524..2f7763b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -601,7 +601,7 @@
> };
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg =<0x1453 0x7>;
> interrupts =<0 95 0>;
> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
> @@ -611,7 +611,7 @@
> };
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
> reg =<0x1445 0x1>;
> interrupts =<0 94 0>;
> };
[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem
On 06/19/13 22:50, Kukjin Kim wrote:
> On 06/19/13 21:51, Rahul Sharma wrote:
>> This patch renames the combatible strings for hdmi, mixer, ddc
>> and hdmiphy. It follows the convention of using compatible string
>> which represent the SoC in which the IP was added for the first
>> time.
>>
>> Signed-off-by: Rahul Sharma
>
> Acked-by: Kukjin Kim
>
Just one nit in subject:
[PATCH] ARM: dts: . for exynos5250
Thanks,
- Kukjin
>> ---
>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>> b/arch/arm/boot/dts/cros5250-common.dtsi
>> index 3f0239e..dc259e8b 100644
>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>> @@ -190,7 +190,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiddc at 50 {
>> - compatible = "samsung,exynos5-hdmiddc";
>> + compatible = "samsung,exynos4210-hdmiddc";
>> reg =<0x50>;
>> };
>> };
>> @@ -224,7 +224,7 @@
>> samsung,i2c-max-bus-freq =<378000>;
>>
>> hdmiphy at 38 {
>> - compatible = "samsung,exynos5-hdmiphy";
>> + compatible = "samsung,exynos4212-hdmiphy";
>> reg =<0x38>;
>> };
>> };
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index 3e0c792..f320d7c 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -72,7 +72,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiddc at 50 {
>> - compatible = "samsung,exynos5-hdmiddc";
>> + compatible = "samsung,exynos4210-hdmiddc";
>> reg =<0x50>;
>> };
>> };
>> @@ -102,7 +102,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiphy at 38 {
>> - compatible = "samsung,exynos5-hdmiphy";
>> + compatible = "samsung,exynos4212-hdmiphy";
>> reg =<0x38>;
>> };
>> };
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 0673524..2f7763b 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -601,7 +601,7 @@
>> };
>>
>> hdmi {
>> - compatible = "samsung,exynos5-hdmi";
>> + compatible = "samsung,exynos4212-hdmi";
>> reg =<0x1453 0x7>;
>> interrupts =<0 95 0>;
>> clocks =<&clock 333>,<&clock 136>,<&clock 137>,
>> @@ -611,7 +611,7 @@
>> };
>>
>> mixer {
>> - compatible = "samsung,exynos5-mixer";
>> + compatible = "samsung,exynos5250-mixer";
>> reg =<0x1445 0x1>;
>> interrupts =<0 94 0>;
>> };
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
.../devicetree/bindings/video/exynos_mixer.txt |1 +
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +++-
drivers/gpu/drm/exynos/regs-mixer.h|7 +++
3 files changed, 45 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index a8b063f..c64ddc1 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsung,exynos5250-mixer"
+ 3) "samsung,exynos5420-mixer"
- reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+ MXR_VER_128_0_0_184,
};
struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
- /* choosing between porper HD and SD mode */
- if (height <= 480)
- val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
- else if (height <= 576)
- val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
- else if (height <= 720)
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
- else if (height <= 1080)
- val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
- else
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+ /* choosing between proper HD and SD mode */
+ if (height <= 480)
+ val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+ else if (height <= 576)
+ val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+ else if (height <= 720)
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ else if (height <= 1080)
+ val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+ else
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ }
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
}
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
+ /* setup display size */
+ if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+ win == MIXER_DEFAULT_WIN) {
+ val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+ val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+ mixer_reg_write(res, MXR_RESOLUTION, val);
+ }
+
val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
mixer_cfg_layer(ctx, win, true);
/* layer update mandatory for mixer 16.0.33.0 */
- if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+ ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
{
+ struct mixer_context *mixer_ctx = ctx;
u32 w, h;
w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
+ if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+ mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+ return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
exynos_drm_hdmi_context *ctx,
return 0;
}
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+ .version = MXR_VER_128_0_0_184,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @@ static st
[PATCH v3 0/3] exynos5420/hdmi: add support for hdmi subsystem
Add support for exynos5420 hdmi subsystem. It adds compatible strings for exynos5420 mixer and Changes the drivers as per IP modifications. This set doesn't have changes for hdmiphy, which will posted independently. This set is based on drm-next branch of Inki Dae's tree at http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git. v3: 1) instead of replacing with old compatible strings, new ones are added without removing the support for older ones. 2) removed patch "drm/exynos: fix interlace resolutions for exynos5420" as it is independently merged. v2: 1)update device mixer tree binding document with "samsung,exynos5420-mixer" Rahul Sharma (3): drm/exynos: add new compatible strings for hdmi subsystem drm/exynos: add support for exynos5420 mixer ARM/dts: change compatible strings for hdmi subsystem .../devicetree/bindings/video/exynos_hdmi.txt |7 ++- .../devicetree/bindings/video/exynos_hdmiddc.txt |7 ++- .../devicetree/bindings/video/exynos_hdmiphy.txt |7 ++- .../devicetree/bindings/video/exynos_mixer.txt |9 ++- arch/arm/boot/dts/cros5250-common.dtsi |4 +- arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +- arch/arm/boot/dts/exynos5250.dtsi |4 +- drivers/gpu/drm/exynos/exynos_ddc.c|2 + drivers/gpu/drm/exynos/exynos_hdmi.c |3 + drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 ++ drivers/gpu/drm/exynos/exynos_mixer.c | 62 ++-- drivers/gpu/drm/exynos/regs-mixer.h|7 +++ 12 files changed, 89 insertions(+), 31 deletions(-) -- 1.7.10.4
[PATCH v3 1/3] drm/exynos: add new compatible strings for hdmi subsystem
This patch adds new combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt |7 +--
.../devicetree/bindings/video/exynos_hdmiddc.txt |7 +--
.../devicetree/bindings/video/exynos_hdmiphy.txt |7 +--
Documentation/devicetree/bindings/video/exynos_mixer.txt |8 ++--
drivers/gpu/drm/exynos/exynos_ddc.c |2 ++
drivers/gpu/drm/exynos/exynos_hdmi.c |3 +++
drivers/gpu/drm/exynos/exynos_hdmiphy.c |4
drivers/gpu/drm/exynos/exynos_mixer.c | 13 -
8 files changed, 38 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..c71d0f0 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,10 @@
Device-Tree bindings for drm hdmi driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: value should be one among the following:
+ 1) "samsung,exynos5-hdmi"
+ 2) "samsung,exynos4210-hdmi"
+ 3) "samsung,exynos4212-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -15,7 +18,7 @@ Required properties:
Example:
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 0xf 1 3>;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..41eee97 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,15 @@
Device-Tree bindings for hdmiddc driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmiddc".
+- compatible: value should be one of the following
+ 1) "samsung,exynos5-hdmiddc"
+ 2) "samsung,exynos4210-hdmiddc"
+
- reg: I2C address of the hdmiddc device.
Example:
hdmiddc {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..162f641 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,15 @@
Device-Tree bindings for hdmiphy driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmiphy".
+- compatible: value should be one of the following:
+ 1) "samsung,exynos5-hdmiphy"
+ 2) "samsung,exynos4210-hdmiphy".
+ 3) "samsung,exynos4212-hdmiphy".
- reg: I2C address of the hdmiphy device.
Example:
hdmiphy {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..9131b99 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,11 @@
Device-Tree bindings for mixer driver
Required properties:
-- compatible: value should be "samsung,exynos5-mixer".
+- compatible: value should be one of the following:
+ 1) "samsung,exynos5-mixer"
+ 2) "samsung,exynos4210-mixer"
+ 3) "samsung,exynos5250-mixer"
+
- reg: physical base address of the mixer and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -9,7 +13,7 @@ Required properties:
Example:
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..95c75ed 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -53,6 +53,8 @@ static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiddc",
},
