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