[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Lucas Stach
> Sent: Monday, July 22, 2013 9:47 PM
> To: Inki Dae
> Cc: 'Mark Rutland'; 'Chanho Park'; linux-samsung-soc at vger.kernel.org;
> devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> rotator
>
> Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
> >
> > > -Original Message-
> > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > Sent: Monday, July 22, 2013 5:48 PM
> > > To: Chanho Park
> > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > > devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> > > rotator
> > >
> > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > > This patch adds a dt-binding document for exynos rotator. It
> describes
> > > which
> > > > nodes should be defined to use the rotator.
> > > >
> > > > Signed-off-by: Chanho Park
> > > > Signed-off-by: Kyungmin Park
> > > > ---
> > > > .../bindings/drm/exynos/samsung-rotator.txt| 35
> > >
> > > > 1 file changed, 35 insertions(+)
> > > > create mode 100644
> > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > rotator.txt
> > > > new file mode 100644
> > > > index 000..6b1d704
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-
> rotator.txt
> > > > @@ -0,0 +1,35 @@
> > > > +* Samsung Image Rotator
> > > > +
> > > > +Required properties:
> > > > + - compatible : value should be the "samsung,exynos4210".
> >
> > Please, add more compatible strings for other SoC.
> >
> > > > + - reg : Physical base address of the IP registers and length of
> > > memory
> > > > + mapped region.
> > > > + - interrupts : interrupt number to the CPU.
> > > > + - clocks : clock number of exynos4 rotator clock.
> > > > + - clocks : clock name of rotator
> > >
> > > clock-names?
> > >
> > > > + - status : "okay" or "disabled"
> > > > + - limit table for image formats : min_w/min_h/max_w/max_h for
> min/max
> > > of image
> > >
> > > Limit table? This doesn't seem to be a well-defined binding, and it
> > > seems like a relatively generic thing to describe.
> > >
> > > > +
> > > > +Example:
> > > > + rotator: rotator at 1281 {
> > > > + compatible = "samsung,exynos4210-rotator";
> > > > + reg = <0x1281 0x1000>;
> > > > + interrupts = <0 83 0>;
> > > > + clocks = < 278>;
> > > > + clock-names = "rotator";
> > > > + status = "disabled";
> > > > + ycbcr420_2p {
> > >
> > > Which names are allowed for these subnodes?
> > >
> > > > + min_w = <32>;
> > > > + min_h = <32>;
> > > > + max_w = <32768>;
> > > > + max_h = <32768>;
> > > > + align = <3>;
> > >
> > > min-width, min-height, max-width, max-height? What units are they in?
> > >
> > > What does alignment specify exactly?
> > >
> > > Are these a configurable part of the rotator hardware, or are these
> > > values always the same?
> >
> > Right, that seems like configurable part. At least, min_w/h and max_w/h
> can
> > be different values according to SoC and pixel formats so they should be
> > described enough in this dt-binding document file.
> >
> Is there really this much configurability? Could each of those values be
> a different on different SoCs
Not much but Yes. Rotator devices of Exynos SoC support various pixel formats;
RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane, and each of these
pixel formats could be different limitation to minimum and maximum sizes.
For example, the below shows the limitation to Rotator device of Exynos4412 SoC
according to pixel formats,
Image format Minimum size Maximum size
RGB8888x8 8kx8k
RGB56516x16 16kx16k
YUV42216x16 16kx16k
YUV420 2-Plane 32x32 32kx32k(in case of Y
components)
YUV420 3-Plane 64x32 32kx32k(in case of Y
components)
[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
> -Original Message-
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Monday, July 22, 2013 5:48 PM
> To: Chanho Park
> Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> rotator
>
> On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > This patch adds a dt-binding document for exynos rotator. It describes
> which
> > nodes should be defined to use the rotator.
> >
> > Signed-off-by: Chanho Park
> > Signed-off-by: Kyungmin Park
> > ---
> > .../bindings/drm/exynos/samsung-rotator.txt| 35
>
> > 1 file changed, 35 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> >
> > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> rotator.txt
> > new file mode 100644
> > index 000..6b1d704
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > @@ -0,0 +1,35 @@
> > +* Samsung Image Rotator
> > +
> > +Required properties:
> > + - compatible : value should be the "samsung,exynos4210".
Please, add more compatible strings for other SoC.
> > + - reg : Physical base address of the IP registers and length of
> memory
> > + mapped region.
> > + - interrupts : interrupt number to the CPU.
> > + - clocks : clock number of exynos4 rotator clock.
> > + - clocks : clock name of rotator
>
> clock-names?
>
> > + - status : "okay" or "disabled"
> > + - limit table for image formats : min_w/min_h/max_w/max_h for min/max
> of image
>
> Limit table? This doesn't seem to be a well-defined binding, and it
> seems like a relatively generic thing to describe.
>
> > +
> > +Example:
> > + rotator: rotator at 1281 {
> > + compatible = "samsung,exynos4210-rotator";
> > + reg = <0x1281 0x1000>;
> > + interrupts = <0 83 0>;
> > + clocks = < 278>;
> > + clock-names = "rotator";
> > + status = "disabled";
> > + ycbcr420_2p {
>
> Which names are allowed for these subnodes?
>
> > + min_w = <32>;
> > + min_h = <32>;
> > + max_w = <32768>;
> > + max_h = <32768>;
> > + align = <3>;
>
> min-width, min-height, max-width, max-height? What units are they in?
>
> What does alignment specify exactly?
>
> Are these a configurable part of the rotator hardware, or are these
> values always the same?
Right, that seems like configurable part. At least, min_w/h and max_w/h can
be different values according to SoC and pixel formats so they should be
described enough in this dt-binding document file.
Thanks,
Inki Dae
> If thery're always the same, there's no need to
> describe in in the devicetree.
>
> Thanks,
> Mark.
>
> > + };
> > + rgb888 {
> > + min_w = <8>;
> > + min_h = <8>;
> > + max_w = <8192>;
> > + max_h = <8192>;
> > + align = <2>;
> > + };
> > + };
> > --
> > 1.7.9.5
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
[PATCH 1/3] drm/exynos: add device tree support for rotator
On Monday 22 of July 2013 15:49:25 Chanho Park wrote:
> The exynos4 platform is only dt-based since 3.10, we should convert
> driver data and ids to dt-based parsing methods. The rotator driver has
> a limit table to get size limit. The minimum size of RGB888 format is 8
> x 8 and maximum size is 8K x 8K. The other format, YCbCr420 2-Plane has
> 32 x 32 min size and 32K x 32K max size. Each format should be multiple
> of 'align' value.
>
> Signed-off-by: Chanho Park
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 110
> +++ 1 file changed, 80 insertions(+), 30
> deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c index 427640a..b353a10
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -96,7 +96,7 @@ struct rot_context {
> struct resource *regs_res;
> void __iomem*regs;
> struct clk *clock;
> - struct rot_limit_table *limit_tbl;
> + struct rot_limit_table limit_tbl;
> int irq;
> int cur_buf_id[EXYNOS_DRM_OPS_MAX];
> boolsuspended;
> @@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void
> *arg) static void rotator_align_size(struct rot_context *rot, u32 fmt,
> u32 *hsize, u32 *vsize)
> {
> - struct rot_limit_table *limit_tbl = rot->limit_tbl;
> + struct rot_limit_table *limit_tbl = >limit_tbl;
> struct rot_limit *limit;
> u32 mask, val;
>
> @@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd) return 0;
> }
>
> +static const struct of_device_id exynos_rotator_match[] = {
> + {
> + .compatible = "samsung,exynos4210-rotator",
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_rotator_match);
> +
> +static int rotator_parse_dt_tbl(struct device_node *np, struct
> rot_limit *rlim) +{
> + int ret;
> +
> + ret = of_property_read_u32(np, "min_w", >min_w);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "min_h", >min_h);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "max_w", >max_w);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "max_h", >max_h);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "align", >align);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int rotator_parse_dt(struct device *dev, struct rot_context
> *rot) +{
> + struct device_node *ycbcr_node, *rgb888_node;
> + int ret;
> +
> + ycbcr_node = of_get_child_by_name(dev->of_node, "ycbcr420_2p");
> + if (!ycbcr_node) {
> + dev_err(dev, "can't find ycbcr420_2p node\n");
> + return -ENODEV;
> + }
> +
> + rgb888_node = of_get_child_by_name(dev->of_node, "rgb888");
> + if (!rgb888_node) {
> + dev_err(dev, "can't find rgb888 node\n");
> + return -ENODEV;
> + }
> +
> + ret = rotator_parse_dt_tbl(ycbcr_node,
>limit_tbl.ycbcr420_2p);
> + if (ret) {
> + dev_err(dev, "failed to parse ycbcr420 data\n");
> + return ret;
> + }
> + ret = rotator_parse_dt_tbl(rgb888_node, >limit_tbl.rgb888);
> + if (ret) {
> + dev_err(dev, "failed to parse rgb888 data\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int rotator_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device
> *pdev) struct exynos_drm_ippdrv *ippdrv;
> int ret;
>
> + if (!dev->of_node) {
> + dev_err(dev, "Cannot find device tree node\n");
> + return -ENODEV;
> + }
> +
> rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
> if (!rot) {
> dev_err(dev, "failed to allocate rot\n");
> return -ENOMEM;
> }
>
> - rot->limit_tbl = (struct rot_limit_table *)
> - platform_get_device_id(pdev)->driver_data;
> + ret = rotator_parse_dt(dev, rot);
> + if (ret) {
> + dev_err(dev, "failed parse dt info\n");
> + devm_kfree(dev, rot);
> + return ret;
> + }
>
> rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> rot->regs = devm_ioremap_resource(dev, rot->regs_res);
> @@ -718,31 +793,6 @@ static int rotator_remove(struct platform_device
> *pdev) return 0;
> }
>
> -static struct rot_limit_table rot_limit_tbl = {
> - .ycbcr420_2p = {
> - .min_w = 32,
> - .min_h = 32,
> - .max_w = SZ_32K,
> - .max_h = SZ_32K,
> - .align = 3,
> - },
> - .rgb888 = {
> - .min_w = 8,
> - .min_h = 8,
> -
[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
On Monday 22 of July 2013 16:00:22 Sylwester Nawrocki wrote:
> On 07/22/2013 03:31 PM, Inki Dae wrote:
> >> ---Original Message-
> >>
> >> > From: linux-samsung-soc-owner at vger.kernel.org
> >> > [mailto:linux-samsung-soc- owner at vger.kernel.org] On Behalf Of
> >> > Lucas Stach
> >> > Sent: Monday, July 22, 2013 9:47 PM
> >> > To: Inki Dae
> >> > Cc: 'Mark Rutland'; 'Chanho Park';
> >> > linux-samsung-soc at vger.kernel.org;
> >> > devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> >> > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> >> > kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
> >> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation
> >> > for
> >> > rotator
> >> >
> >> > Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
> > > > -Original Message-
> > > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > > Sent: Monday, July 22, 2013 5:48 PM
> > > > To: Chanho Park
> > > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com;
> > > > linux-samsung-
> > > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > > > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> > > > linux-arm-
> > > > kernel at lists.infradead.org
> > > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding
> > > > documentation for
> > > > rotator
> > > >
> > > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > > > > This patch adds a dt-binding document for exynos rotator.
> > > > > > It
> >> >
> >> > describes
> >> >
> > > > which
> > > >
> > > > > > nodes should be defined to use the rotator.
> > > > > >
> > > > > > Signed-off-by: Chanho Park
> > > > > > Signed-off-by: Kyungmin Park
> > > > > > ---
> > > > > >
> > > > > > .../bindings/drm/exynos/samsung-rotator.txt| 35
> > > >
> > > >
> > > >
> > > > > > 1 file changed, 35 insertions(+)
> > > > > > create mode 100644
> > > >
> > > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.
> > > > txt
> > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > >
> > > > rotator.txt
> > > > b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > > rotator.txt
> > > >
> > > > > > new file mode 100644
> > > > > > index 000..6b1d704
> > > > > > --- /dev/null
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/drm/exynos/samsung-
> >> >
> >> > rotator.txt
> >> >
> > > > > > @@ -0,0 +1,35 @@
> > > > > > +* Samsung Image Rotator
> > > > > > +
> > > > > > +Required properties:
> > > > > > + - compatible : value should be the
> > > > > > "samsung,exynos4210".
> >>> > >
> >>> > > Please, add more compatible strings for other SoC.
> >>> > >
> > > > > > + - reg : Physical base address of the IP registers and
> > > > > > length of
> > > >
> > > > memory
> > > >
> > > > > > + mapped region.
> > > > > > + - interrupts : interrupt number to the CPU.
> > > > > > + - clocks : clock number of exynos4 rotator clock.
> > > > > > + - clocks : clock name of rotator
> > > >
> > > > clock-names?
> > > >
> > > > > > + - status : "okay" or "disabled"
> > > > > > + - limit table for image formats :
> > > > > > min_w/min_h/max_w/max_h for
> >> >
> >> > min/max
> >> >
> > > > of image
> > > >
> > > > Limit table? This doesn't seem to be a well-defined binding,
> > > > and it
> > > > seems like a relatively generic thing to describe.
> > > >
> > > > > > +
> > > > > > +Example:
> > > > > > + rotator: rotator at 1281 {
> > > > > > + compatible = "samsung,exynos4210-rotator";
> > > > > > + reg = <0x1281 0x1000>;
> > > > > > + interrupts = <0 83 0>;
> > > > > > + clocks = < 278>;
> > > > > > + clock-names = "rotator";
> > > > > > + status = "disabled";
> > > > > > + ycbcr420_2p {
> > > >
> > > > Which names are allowed for these subnodes?
> > > >
> > > > > > + min_w = <32>;
> > > > > > + min_h = <32>;
> > > > > > + max_w = <32768>;
> > > > > > + max_h = <32768>;
> > > > > > + align = <3>;
> > > >
> > > > min-width, min-height, max-width, max-height? What units are
> > > > they in?
> > > >
> > > > What does alignment specify exactly?
> > > >
> > > > Are these a configurable part of
[PATCH 1/3] drm/exynos: add device tree support for rotator
> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Chanho Park
> Sent: Monday, July 22, 2013 3:49 PM
> To: inki.dae at samsung.com; kgene.kim at samsung.com
> Cc: jy0922.shim at samsung.com; sw0312.kim at samsung.com;
> kyungmin.park at samsung.com; dri-devel at lists.freedesktop.org;
> linux-samsung-
> soc at vger.kernel.org; linux-arm-kernel at lists.infradead.org; devicetree-
> discuss at lists.ozlabs.org; Chanho Park
> Subject: [PATCH 1/3] drm/exynos: add device tree support for rotator
>
> The exynos4 platform is only dt-based since 3.10, we should convert driver
> data
> and ids to dt-based parsing methods. The rotator driver has a limit table
> to get
> size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is
> 8K x
> 8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K
> max
> size. Each format should be multiple of 'align' value.
>
> Signed-off-by: Chanho Park
> Signed-off-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_rotator.c | 110 +++---
> -
> 1 file changed, 80 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> index 427640a..b353a10 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
> @@ -96,7 +96,7 @@ struct rot_context {
> struct resource *regs_res;
> void __iomem*regs;
> struct clk *clock;
> - struct rot_limit_table *limit_tbl;
> + struct rot_limit_table limit_tbl;
> int irq;
> int cur_buf_id[EXYNOS_DRM_OPS_MAX];
> boolsuspended;
> @@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void
> *arg)
> static void rotator_align_size(struct rot_context *rot, u32 fmt, u32
> *hsize,
> u32 *vsize)
> {
> - struct rot_limit_table *limit_tbl = rot->limit_tbl;
> + struct rot_limit_table *limit_tbl = >limit_tbl;
> struct rot_limit *limit;
> u32 mask, val;
>
> @@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev,
> enum drm_exynos_ipp_cmd cmd)
> return 0;
> }
>
> +static const struct of_device_id exynos_rotator_match[] = {
> + {
> + .compatible = "samsung,exynos4210-rotator",
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_rotator_match);
Rotator device cannot be plugged in. Please remove the above
MODULE_DEVICE_TABLE.
> +
> +static int rotator_parse_dt_tbl(struct device_node *np, struct rot_limit
> *rlim)
> +{
> + int ret;
> +
> + ret = of_property_read_u32(np, "min_w", >min_w);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "min_h", >min_h);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "max_w", >max_w);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "max_h", >max_h);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_u32(np, "align", >align);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int rotator_parse_dt(struct device *dev, struct rot_context *rot)
> +{
> + struct device_node *ycbcr_node, *rgb888_node;
> + int ret;
> +
> + ycbcr_node = of_get_child_by_name(dev->of_node, "ycbcr420_2p");
> + if (!ycbcr_node) {
> + dev_err(dev, "can't find ycbcr420_2p node\n");
> + return -ENODEV;
> + }
> +
> + rgb888_node = of_get_child_by_name(dev->of_node, "rgb888");
> + if (!rgb888_node) {
> + dev_err(dev, "can't find rgb888 node\n");
> + return -ENODEV;
> + }
> +
> + ret = rotator_parse_dt_tbl(ycbcr_node, >limit_tbl.ycbcr420_2p);
> + if (ret) {
> + dev_err(dev, "failed to parse ycbcr420 data\n");
> + return ret;
> + }
> + ret = rotator_parse_dt_tbl(rgb888_node, >limit_tbl.rgb888);
> + if (ret) {
> + dev_err(dev, "failed to parse rgb888 data\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int rotator_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> @@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device
> *pdev)
> struct exynos_drm_ippdrv *ippdrv;
> int ret;
>
> + if (!dev->of_node) {
> + dev_err(dev, "Cannot find device tree node\n");
> + return -ENODEV;
> + }
> +
> rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
> if (!rot) {
> dev_err(dev, "failed to allocate rot\n");
> return -ENOMEM;
> }
>
> - rot->limit_tbl = (struct rot_limit_table *)
> - platform_get_device_id(pdev)->driver_data;
> + ret = rotator_parse_dt(dev, rot);
> + if (ret) {
> + dev_err(dev,
[PATCH 05/20] drm/gem: remove drm_gem_object_handle_unreference
On Tue, Jul 16, 2013 at 3:11 AM, Daniel Vetter
wrote:
> It's unused, everyone is using the _unlocked variant only.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> include/drm/drmP.h | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index baf030c..f949cb2 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1671,24 +1671,6 @@ drm_gem_object_handle_reference(struct drm_gem_object
> *obj)
> }
>
> static inline void
> -drm_gem_object_handle_unreference(struct drm_gem_object *obj)
> -{
> - if (obj == NULL)
> - return;
> -
> - if (atomic_read(>handle_count) == 0)
> - return;
> - /*
> -* Must bump handle count first as this may be the last
> -* ref, in which case the object would disappear before we
> -* checked for a name
> -*/
> - if (atomic_dec_and_test(>handle_count))
> - drm_gem_object_handle_free(obj);
> - drm_gem_object_unreference(obj);
> -}
> -
> -static inline void
> drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
> {
> if (obj == NULL)
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66767] atombios stuck in loop for more than 5secs aborting after suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=66767 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Alex Deucher --- *** This bug has been marked as a duplicate of bug 67043 *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/e9e1a9e6/attachment.html>
[Bug 67043] Atombios stuck in a loop during resume
https://bugs.freedesktop.org/show_bug.cgi?id=67043 Alex Deucher changed: What|Removed |Added CC||johannes.hirte at fem.tu-ilmen ||au.de --- Comment #11 from Alex Deucher --- *** Bug 66767 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/f4c859e3/attachment.html>
[PATCH] drm/exynos: fix module build error
This patch removes all MODULE_DEVICE_TABLE declarations.
Exynos drm drivers don't need to create MODULE_DEVICE_TABLE
yet because all devices of Exynos drm include in one SoC so
they cannot be plugged in as of now.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 --
drivers/gpu/drm/exynos/exynos_drm_g2d.c |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3e106be..5dba79e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -130,7 +130,6 @@ static const struct of_device_id fimd_driver_dt_match[] = {
.data = _fimd_driver_data },
{},
};
-MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
#endif
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
@@ -1082,7 +1081,6 @@ static struct platform_device_id fimd_driver_ids[] = {
},
{},
};
-MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 42a5a54..4722662 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1521,7 +1521,6 @@ static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = "samsung,exynos5250-g2d" },
{},
};
-MODULE_DEVICE_TABLE(of, exynos_g2d_match);
#endif
struct platform_driver g2d_driver = {
--
1.7.5.4
[Bug 66767] atombios stuck in loop for more than 5secs aborting after suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=66767 --- Comment #3 from Martin Bednar --- Created attachment 82844 --> https://bugs.freedesktop.org/attachment.cgi?id=82844=edit dmesg after resume dmesg output after a resume from suspend to ram. UVD initialization fails. Output from 3.11-rc2. on a 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series]. Only happens if DPM is enabled. short dmesg version (mainly radeon output after resume) : [ 134.652348] [drm] PCIE GART of 512M enabled (table at 0x0025D000). [ 134.652517] radeon :01:00.0: WB enabled [ 134.652520] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88011160fc00 [ 134.652521] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x88011160fc0c [ 134.653452] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc9000639c418 [ 134.670153] [drm] ring test on 0 succeeded in 1 usecs [ 134.670213] [drm] ring test on 3 succeeded in 1 usecs [ 134.723748] dpm_run_callback(): pnp_bus_resume+0x0/0x80 returns -19 [ 134.723750] PM: Device 00:07 failed to resume: error -19 [ 134.962587] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 134.965908] ata6: SATA link down (SStatus 0 SControl 300) [ 134.966739] ata2.00: configured for UDMA/100 [ 135.142469] sdhci-pci :03:00.0: Will use DMA mode even though HW doesn't fully claim to support it. [ 135.142506] sdhci-pci :03:00.4: Will use DMA mode even though HW doesn't fully claim to support it. [ 135.862145] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 136.771646] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 136.781372] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 136.791321] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 136.791499] ata1.00: configured for UDMA/133 [ 136.804977] sd 0:0:0:0: [sda] Starting disk [ 136.887420] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 137.912701] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 138.937981] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 139.963255] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 140.988548] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 142.013843] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 143.039117] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 144.064413] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 145.089696] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 145.109806] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 145.109873] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). [ 145.109874] [drm] Enabling audio support [ 145.109933] [drm] ib test on ring 0 succeeded in 0 usecs [ 145.109978] [drm] ib test on ring 3 succeeded in 1 usecs [ 145.121521] switching from power state: [ 145.121522] ui class: none [ 145.121524] internal class: boot [ 145.121525] caps: video [ 145.121527] uvdvclk: 0 dclk: 0 [ 145.121529] power level 0sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121530] power level 1sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121531] power level 2sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121533] status: c b [ 145.121533] switching to power state: [ 145.121534] ui class: performance [ 145.121535] internal class: none [ 145.121536] caps: single_disp video [ 145.121537] uvdvclk: 0 dclk: 0 [ 145.121538] power level 0sclk: 15000 mclk: 15000 vddc: 900 vddci: 0 [ 145.121539] power level 1sclk: 3 mclk: 79000 vddc: 950 vddci: 0 [ 145.121540] power level 2sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121541] status: r [ 150.307980] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 150.307982] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBE6 (len 67, WS 0, PS 0) @ 0xCC15 [ 151.345217] PM: resume of devices complete after 16856.243 msecs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/2b6e1ea5/attachment.html>
[Bug 67178] discrete radeon HD 6400M/7400M intense heating even though it's "off"
https://bugs.freedesktop.org/show_bug.cgi?id=67178 --- Comment #2 from Tomas Pospisek --- So if I boot with "radeon.dpm=1" then, as allready described, the laptop uses "relatively little" power, and is faning off some heat continuously, even when I set: # echo "battery" > /sys/class/drm/card1/device/power_dpm_state Whether I do the following does *not* seem to matter: # echo IGD > /sys/kernel/debug/vgaswitcheroo/switch # echo OFF > /sys/kernel/debug/vgaswitcheroo/switch But if I boot *without* "radeon.dpm=1" then the laptop will stay cool without fans running out of the box using around 14W. The various settings will show this then: # cat /sys/class/drm/card1/device/power_method dpm # cat /sys/class/drm/card1/device/power_profile default # cat /sys/class/drm/card1/device/power_dpm_state balanced Weird that power_method would show "dpm" even though I have booted *without* "radeon.dpm=1" ?! When I then set: # echo "battery" > /sys/class/drm/card1/device/power_dpm_state Power consumption will drop even further to ~11W. The overal logic of all of this is evidently completely escaping me... 8-o -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/a864aba6/attachment.html>
[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon
https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #1 from Sebastien Fievet --- I did proofread my report, but missed a obvious mistake : cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Pwr::02:00.0 2:DIS-Audio: :Pwr::02:00.1 echo OFF > /sys/kernel/debug/vgaswitcheroo/switch cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Off::02:00.0 2:DIS-Audio: :Off::02:00.1 all apologies. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60606] New: vga_switcheroo / new Radeon DPM code mess up fbcon
https://bugzilla.kernel.org/show_bug.cgi?id=60606 Bug ID: 60606 Summary: vga_switcheroo / new Radeon DPM code mess up fbcon Product: Drivers Version: 2.5 Kernel Version: 3.11.0-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: sebastien.fievet at free.fr Regression: No Created attachment 106987 --> https://bugzilla.kernel.org/attachment.cgi?id=106987=edit radeon switch OFF / switch ON experiment I am the happy owner of an hybrid Intel core i5 480M / AMD Radeon 6550M latop. - IGP is Intel ironlake - DGD is AMD radeon 6550M I just installed kernel 3.11.0-rc2. switching the discrete GPU OFF via the vgaswticheroo works from within X or from the console : echo OFF > /sys/kernel/debug/vgaswitcheroo/switch cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Pwr::02:00.0 2:DIS-Audio: :Pwr::02:00.1 I then tried to switch the radeon back ON from the console with X down : echo ON > /sys/kernel/debug/vgaswitcheroo/switch It messed up the console display : screen turned to dominant grey scattered with coloured pixels making it unreadable, forcing me to reboot. The attachment is the excerpt of my kern.log file for my radeon switch OFF / switch ON experiment. switch off is at [ 76.634983] switch on is at [ 2167.936488] or [ 2167.936517] I also noticed : [5.457569] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) [5.457739] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) which seems to be related to vgaswitcheroo setup, but I don't know if it's relevant or not. Let me know if you need anything else. thanks for your help, Seb. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 67187] New: Radeon HD6950: UVD not responding, trying to reset the VCPU
https://bugs.freedesktop.org/show_bug.cgi?id=67187 Priority: medium Bug ID: 67187 Assignee: dri-devel at lists.freedesktop.org Summary: Radeon HD6950: UVD not responding, trying to reset the VCPU Severity: normal Classification: Unclassified OS: Linux (All) Reporter: h.judt at gmx.at Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 82837 --> https://bugs.freedesktop.org/attachment.cgi?id=82837=edit dmesg.out When I thought suspend/resume was finally working, I found these error messages in dmesg. See file attached, it's dmesg with multiple suspend/resume cycles. Note I'm using tuxonice patches, but that shouldn't matter. If retesting with vanilla is required, I can do this of course. Note: I have the fix from bug #66425 applied. Linux-3.10.1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/fc4774bd/attachment.html>
[PATCH 04/20] drm/prime: add a bit of documentation about gem_obj->import_attach
On Tue, Jul 16, 2013 at 3:11 AM, Daniel Vetter
wrote:
> Lifetime rules seem to be solid around ->import_attach. So this patch
> just properly documents them.
>
> Note that pointing directly at the attachment might have issues for
> devices that have multiple struct device *dev parts constituting the
> logical gpu and so might need multiple attachment points. Similarly
> for drm devices which don't need a dma attachment at all (like udl).
yeah, with msm drm driver, that might become (eventually) an issue.
(But not yet, because they seem to use iommu<->dev attachment in a..
slightly different way)
> But fixing that up is material for different patches.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> include/drm/drmP.h | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index cd57646..baf030c 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -681,7 +681,16 @@ struct drm_gem_object {
> /* dma buf exported from this GEM object */
> struct dma_buf *export_dma_buf;
>
> - /* dma buf attachment backing this object */
> + /**
> +* import_attach - dma buf attachment backing this object
> +*
> +* Any foreign dma_buf imported as a gem object has this set to the
> +* attachment point for the device. This is invariant over the
> lifetime
> +* of a gem object.
> +*
> +* The driver's ->gem_free_object callback is responsible for cleaning
> +* up the dma_buf attachment and references acquired at import time.
> +*/
> struct dma_buf_attachment *import_attach;
> };
>
> --
> 1.8.3.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
On Tue, Jul 16, 2013 at 3:12 AM, Daniel Vetter
wrote:
> All the gem based kms drivers really want the same function to
> destroy a dumb framebuffer backing storage object.
>
> So give it to them and roll it out in all drivers.
>
> This still leaves the option open for kms drivers which don't use GEM
> for backing storage, but it does decently simplify matters for gem
> drivers.
>
> Cc: Inki Dae
> Cc: Laurent Pinchart
> Cc: Intel Graphics Development
> Cc: Ben Skeggs
> Cc: Rob Clark
> Cc: Alex Deucher
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/ast/ast_drv.c | 2 +-
> drivers/gpu/drm/ast/ast_drv.h | 3 ---
> drivers/gpu/drm/ast/ast_main.c| 7 ---
> drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
> drivers/gpu/drm/cirrus/cirrus_drv.h | 3 ---
> drivers/gpu/drm/cirrus/cirrus_main.c | 7 ---
> drivers/gpu/drm/drm_gem.c | 14 ++
> drivers/gpu/drm/drm_gem_cma_helper.c | 10 --
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 20
> drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 -
> drivers/gpu/drm/gma500/gem.c | 17 -
> drivers/gpu/drm/gma500/psb_drv.c | 2 +-
> drivers/gpu/drm/gma500/psb_drv.h | 2 --
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 --
> drivers/gpu/drm/i915/i915_gem.c | 7 ---
> drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
> drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
> drivers/gpu/drm/mgag200/mgag200_main.c| 7 ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
> drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.h| 2 --
> drivers/gpu/drm/omapdrm/omap_gem.c| 15 ---
> drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
> drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
> drivers/gpu/drm/qxl/qxl_dumb.c| 7 ---
> drivers/gpu/drm/radeon/radeon.h | 3 ---
> drivers/gpu/drm/radeon/radeon_drv.c | 5 +
> drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_drv.c | 2 +-
> drivers/gpu/drm/udl/udl_drv.h | 2 --
> drivers/gpu/drm/udl/udl_gem.c | 6 --
> drivers/gpu/host1x/drm/drm.c | 2 +-
> drivers/gpu/host1x/drm/gem.c | 6 --
> drivers/gpu/host1x/drm/gem.h | 2 --
> drivers/staging/imx-drm/imx-drm-core.c| 2 +-
> include/drm/drmP.h| 3 +++
> include/drm/drm_gem_cma_helper.h | 8
> 44 files changed, 33 insertions(+), 186 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index df0d0a0..a144fb0 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -216,7 +216,7 @@ static struct drm_driver driver = {
> .gem_free_object = ast_gem_free_object,
> .dumb_create = ast_dumb_create,
> .dumb_map_offset = ast_dumb_mmap_offset,
> - .dumb_destroy = ast_dumb_destroy,
> + .dumb_destroy = drm_gem_dumb_destroy,
>
> };
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 622d4ae..796dbb2 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -322,9 +322,6 @@ ast_bo(struct ttm_buffer_object *bo)
> extern int ast_dumb_create(struct drm_file *file,
>struct drm_device *dev,
>struct drm_mode_create_dumb *args);
> -extern int ast_dumb_destroy(struct drm_file *file,
> - struct drm_device *dev,
> - uint32_t handle);
>
> extern int ast_gem_init_object(struct drm_gem_object *obj);
> extern void ast_gem_free_object(struct drm_gem_object *obj);
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index f60fd7b..0ef4228 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -449,13 +449,6 @@ int ast_dumb_create(struct drm_file *file,
> return 0;
> }
>
> -int ast_dumb_destroy(struct drm_file *file,
> -struct drm_device *dev,
> -uint32_t handle)
> -{
> - return drm_gem_handle_delete(file, handle);
> -}
> -
> int ast_gem_init_object(struct drm_gem_object *obj)
> {
> BUG();
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
> b/drivers/gpu/drm/cirrus/cirrus_drv.c
> index 8ecb601..d35d99c 100644
> ---
[PATCH 5/5] drm/i915: Add async page flip support for SNB
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 39
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1bcc6b4..9d7919b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7463,20 +7463,51 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = _priv->ring[RCS];
uint32_t pf, pipesrc;
+ uint32_t cmd;
+ uint32_t base;
int ret;
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
if (ret)
goto err;
+ cmd = MI_DISPLAY_FLIP | MI_DISPLAY_FLIP_PLANE(intel_crtc->plane);
+ base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
+
+ if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+
+ /* XXX check limitations for async flip here */
+
+ if (fb->pitches[0] != I915_READ(DSPSTRIDE(intel_crtc->plane))) {
+ WARN_ONCE(1, "mismatching stride in async plane flip
(%d != %d)\n",
+ fb->pitches[0],
I915_READ(DSPSTRIDE(intel_crtc->plane)));
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if (obj->tiling_mode != I915_TILING_X) {
+ WARN_ONCE(1, "async plane flip requires X tiling\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if ((I915_READ(DSPCNTR(intel_crtc->plane)) & DISPPLANE_TILED)
== 0) {
+ WARN_ONCE(1, "display not currently tiled in async
plane flip\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+ base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+ }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
- intel_ring_emit(ring, MI_DISPLAY_FLIP |
- MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
+ intel_ring_emit(ring, cmd);
intel_ring_emit(ring, fb->pitches[0] | obj->tiling_mode);
- intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) +
intel_crtc->dspaddr_offset);
+ intel_ring_emit(ring, base);
/* Contrary to the suggestions in the documentation,
* "Enable Panel Fitter" does not seem to be required when page
@@ -9738,7 +9769,7 @@ void intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_height = 8192;
}
- if (IS_GEN7(dev))
+ if (IS_GEN6(dev) || IS_GEN7(dev))
dev->mode_config.async_page_flip = true;
dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
--
1.8.3.2
[PATCH 4/5] drm/i915: Add async page flip support for IVB
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 40 ++--
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc3d6a7..029cfb0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -209,6 +209,7 @@
#define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
#define MI_DISPLAY_FLIPMI_INSTR(0x14, 2)
#define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
+#define MI_DISPLAY_FLIP_ASYNC_INDICATOR (1 << 22)
#define MI_DISPLAY_FLIP_PLANE(n) ((n) << 20)
/* IVB has funny definitions for which plane to flip. */
#define MI_DISPLAY_FLIP_IVB_PLANE_A (0 << 19)
@@ -217,6 +218,11 @@
#define MI_DISPLAY_FLIP_IVB_SPRITE_B (3 << 19)
#define MI_DISPLAY_FLIP_IVB_PLANE_C (4 << 19)
#define MI_DISPLAY_FLIP_IVB_SPRITE_C (5 << 19)
+/* These go in the bottom of the base address value */
+#define MI_DISPLAY_FLIP_TYPE_SYNC(0 << 0)
+#define MI_DISPLAY_FLIP_TYPE_ASYNC (1 << 0)
+#define MI_DISPLAY_FLIP_TYPE_STEREO (2 << 0)
+#define MI_DISPLAY_FLIP_TYPE_SYNCHRONOUS (0 << 0)
#define MI_ARB_ON_OFF MI_INSTR(0x08, 0)
#define MI_ARB_ENABLE(1<<0)
#define MI_ARB_DISABLE (0<<0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bdb8854..1bcc6b4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7514,6 +7514,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = _priv->ring[BCS];
uint32_t plane_bit = 0;
+ uint32_t cmd;
+ uint32_t base;
int ret;
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
@@ -7536,13 +7538,43 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
goto err_unpin;
}
+ cmd = MI_DISPLAY_FLIP_I915 | plane_bit;
+ base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
+
+ if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+
+ /* XXX check limitations for async flip here */
+
+ if (fb->pitches[0] != I915_READ(DSPSTRIDE(intel_crtc->plane))) {
+ WARN_ONCE(1, "mismatching stride in async plane flip
(%d != %d)\n",
+ fb->pitches[0],
I915_READ(DSPSTRIDE(intel_crtc->plane)));
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if (obj->tiling_mode != I915_TILING_X) {
+ WARN_ONCE(1, "async plane flip requires X tiling\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if ((I915_READ(DSPCNTR(intel_crtc->plane)) & DISPPLANE_TILED)
== 0) {
+ WARN_ONCE(1, "display not currently tiled in async
plane flip\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+ base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+ }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
- intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
+ intel_ring_emit(ring, cmd);
intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
- intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) +
intel_crtc->dspaddr_offset);
+ intel_ring_emit(ring, base);
intel_ring_emit(ring, (MI_NOOP));
intel_mark_page_flip_active(intel_crtc);
@@ -9705,6 +9737,10 @@ void intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_width = 8192;
dev->mode_config.max_height = 8192;
}
+
+ if (IS_GEN7(dev))
+ dev->mode_config.async_page_flip = true;
+
dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
DRM_DEBUG_KMS("%d display pipe%s available.\n",
--
1.8.3.2
[PATCH 3/5] drm: Advertise async page flip ability through GETCAP ioctl
Let applications know whether the kernel supports asynchronous page
flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c | 3 +++
drivers/gpu/drm/drm_ioctl.c | 3 +++
include/drm/drm_crtc.h | 3 +++
include/uapi/drm/drm.h | 1 +
4 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 989072c..0909af6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3514,6 +3514,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
page_flip->reserved != 0)
return -EINVAL;
+ if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
!dev->mode_config.async_page_flip)
+ return -EINVAL;
+
obj = drm_mode_object_find(dev, page_flip->crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj)
return -EINVAL;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index ffd7a7b..7602177 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -303,6 +303,9 @@ int drm_getcap(struct drm_device *dev, void *data, struct
drm_file *file_priv)
case DRM_CAP_TIMESTAMP_MONOTONIC:
req->value = drm_timestamp_monotonic;
break;
+ case DRM_CAP_ASYNC_PAGE_FLIP:
+ req->value = dev->mode_config.async_page_flip;
+ break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0820ab6..13d215f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -845,6 +845,9 @@ struct drm_mode_config {
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
+
+ /* whether async page flip is supported or not */
+ bool async_page_flip;
};
#define obj_to_crtc(x) container_of(x, struct drm_crtc, base)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 238a166..2adfaa5 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -780,6 +780,7 @@ struct drm_event_vblank {
#define DRM_CAP_DUMB_PREFER_SHADOW 0x4
#define DRM_CAP_PRIME 0x5
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
+#define DRM_CAP_ASYNC_PAGE_FLIP 0x7
#define DRM_PRIME_CAP_IMPORT 0x1
#define DRM_PRIME_CAP_EXPORT 0x2
--
1.8.3.2
[PATCH 2/5] drm: Add DRM_MODE_PAGE_FLIP_ASYNC flag definition
This requests that the driver perform the page flip as soon as
possible, not necessarily waiting for vblank.
Signed-off-by: Keith Packard
---
include/uapi/drm/drm_mode.h | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..5508117 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -412,7 +412,8 @@ struct drm_mode_crtc_lut {
};
#define DRM_MODE_PAGE_FLIP_EVENT 0x01
-#define DRM_MODE_PAGE_FLIP_FLAGS DRM_MODE_PAGE_FLIP_EVENT
+#define DRM_MODE_PAGE_FLIP_ASYNC 0x02
+#define DRM_MODE_PAGE_FLIP_FLAGS
(DRM_MODE_PAGE_FLIP_EVENT|DRM_MODE_PAGE_FLIP_ASYNC)
/*
* Request a page flip on the specified crtc.
@@ -426,11 +427,14 @@ struct drm_mode_crtc_lut {
* flip is already pending as the ioctl is called, EBUSY will be
* returned.
*
- * The ioctl supports one flag, DRM_MODE_PAGE_FLIP_EVENT, which will
- * request that drm sends back a vblank event (see drm.h: struct
- * drm_event_vblank) when the page flip is done. The user_data field
- * passed in with this ioctl will be returned as the user_data field
- * in the vblank event struct.
+ * Flag DRM_MODE_PAGE_FLIP_EVENT requests that drm sends back a vblank
+ * event (see drm.h: struct drm_event_vblank) when the page flip is
+ * done. The user_data field passed in with this ioctl will be
+ * returned as the user_data field in the vblank event struct.
+ *
+ * Flag DRM_MODE_PAGE_FLIP_ASYNC requests that the flip happen
+ * 'as soon as possible', meaning that it not delay waiting for vblank.
+ * This may cause tearing on the screen.
*
* The reserved field must be zero until we figure out something
* clever to use it for.
--
1.8.3.2
[PATCH 1/5] drm: Pass page flip ioctl flags to driver
This lets drivers see the flags requested by the application
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 23 +++
drivers/gpu/drm/nouveau/nouveau_display.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_display.h | 3 ++-
drivers/gpu/drm/omapdrm/omap_crtc.c | 3 ++-
drivers/gpu/drm/radeon/radeon_display.c | 3 ++-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 ++-
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 ++-
include/drm/drm_crtc.h| 3 ++-
13 files changed, 39 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..989072c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3587,7 +3587,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
old_fb = crtc->fb;
- ret = crtc->funcs->page_flip(crtc, fb, e);
+ ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags);
if (ret) {
if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
spin_lock_irqsave(>event_lock, flags);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 9a35d17..14f5c1d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -184,8 +184,9 @@ static struct drm_crtc_helper_funcs
exynos_crtc_helper_funcs = {
};
static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event)
+struct drm_framebuffer *fb,
+struct drm_pending_vblank_event *event,
+uint32_t page_flip_flags)
{
struct drm_device *dev = crtc->dev;
struct exynos_drm_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cef35d3..c7cb2de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -380,7 +380,8 @@ struct drm_i915_display_funcs {
void (*init_clock_gating)(struct drm_device *dev);
int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- struct drm_i915_gem_object *obj);
+ struct drm_i915_gem_object *obj,
+ uint32_t flags);
int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
int x, int y);
void (*hpd_irq_setup)(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ae3dc5d..bdb8854 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7320,7 +7320,8 @@ inline static void intel_mark_page_flip_active(struct
intel_crtc *intel_crtc)
static int intel_gen2_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+uint32_t flags)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -7364,7 +7365,8 @@ err:
static int intel_gen3_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+uint32_t flags)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -7405,7 +7407,8 @@ err:
static int intel_gen4_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
-struct drm_i915_gem_object *obj)
+struct drm_i915_gem_object *obj,
+uint32_t flags)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
@@ -7453,7 +7456,8 @@ err:
static int intel_gen6_queue_flip(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
drm: Asynchronouse page flipping interface and Intel implementation
Here's a sequence of five patches that exposes an interface to request of the driver that the page flipping request be executed without waiting for vblank. It's optional, and drivers can expose whether it is supported through the existing GETCAP ioctl. This supports only Ivybridge and Sandybridge Intel graphics chips as that's what I've got to test on; of course all of the other drivers have been modified so that they still compile cleanly. -- keith.packard at intel.com
[Bug 59322] r300g MSAA breaks Half-Life 2 in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=59322 --- Comment #11 from Marek Ol??k --- It's okay to render to an sRGB texture, but FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING should return LINEAR on r300g. That doesn't affect texturing though. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/d2ded6c1/attachment.html>
[PATCH 4/5] drm/i915: Add async page flip support for IVB
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 +
drivers/gpu/drm/i915/intel_display.c | 46
2 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc3d6a7..029cfb0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -209,6 +209,7 @@
#define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
#define MI_DISPLAY_FLIPMI_INSTR(0x14, 2)
#define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
+#define MI_DISPLAY_FLIP_ASYNC_INDICATOR (1 << 22)
#define MI_DISPLAY_FLIP_PLANE(n) ((n) << 20)
/* IVB has funny definitions for which plane to flip. */
#define MI_DISPLAY_FLIP_IVB_PLANE_A (0 << 19)
@@ -217,6 +218,11 @@
#define MI_DISPLAY_FLIP_IVB_SPRITE_B (3 << 19)
#define MI_DISPLAY_FLIP_IVB_PLANE_C (4 << 19)
#define MI_DISPLAY_FLIP_IVB_SPRITE_C (5 << 19)
+/* These go in the bottom of the base address value */
+#define MI_DISPLAY_FLIP_TYPE_SYNC(0 << 0)
+#define MI_DISPLAY_FLIP_TYPE_ASYNC (1 << 0)
+#define MI_DISPLAY_FLIP_TYPE_STEREO (2 << 0)
+#define MI_DISPLAY_FLIP_TYPE_SYNCHRONOUS (0 << 0)
#define MI_ARB_ON_OFF MI_INSTR(0x08, 0)
#define MI_ARB_ENABLE(1<<0)
#define MI_ARB_DISABLE (0<<0)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bdb8854..f2624a4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1833,8 +1833,10 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
alignment = 64 * 1024;
break;
case I915_TILING_X:
- /* pin() will align the object as required by fence */
- alignment = 0;
+ /* Async page flipping requires X tiling and 32kB alignment, so
just
+* make all X tiled frame buffers aligned for that
+*/
+ alignment = 32 * 1024;
break;
case I915_TILING_Y:
/* Despite that we check this in framebuffer_init userspace can
@@ -7514,6 +7516,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_ring_buffer *ring = _priv->ring[BCS];
uint32_t plane_bit = 0;
+ uint32_t cmd;
+ uint32_t base;
int ret;
ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
@@ -7536,13 +7540,43 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
goto err_unpin;
}
+ cmd = MI_DISPLAY_FLIP_I915 | plane_bit;
+ base = i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
+
+ if (flags & DRM_MODE_PAGE_FLIP_ASYNC) {
+
+ /* XXX check limitations for async flip here */
+
+ if (fb->pitches[0] != I915_READ(DSPSTRIDE(intel_crtc->plane))) {
+ WARN_ONCE(1, "mismatching stride in async plane flip
(%d != %d)\n",
+ fb->pitches[0],
I915_READ(DSPSTRIDE(intel_crtc->plane)));
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if (obj->tiling_mode != I915_TILING_X) {
+ WARN_ONCE(1, "async plane flip requires X tiling\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ if ((I915_READ(DSPCNTR(intel_crtc->plane)) & DISPPLANE_TILED)
== 0) {
+ WARN_ONCE(1, "display not currently tiled in async
plane flip\n");
+ ret = -EINVAL;
+ goto err_unpin;
+ }
+
+ cmd |= MI_DISPLAY_FLIP_ASYNC_INDICATOR;
+ base |= MI_DISPLAY_FLIP_TYPE_ASYNC;
+ }
+
ret = intel_ring_begin(ring, 4);
if (ret)
goto err_unpin;
- intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
+ intel_ring_emit(ring, cmd);
intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
- intel_ring_emit(ring, i915_gem_obj_ggtt_offset(obj) +
intel_crtc->dspaddr_offset);
+ intel_ring_emit(ring, base);
intel_ring_emit(ring, (MI_NOOP));
intel_mark_page_flip_active(intel_crtc);
@@ -9705,6 +9739,10 @@ void intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_width = 8192;
dev->mode_config.max_height = 8192;
}
+
+ if (IS_GEN7(dev))
+ dev->mode_config.async_page_flip = true;
+
dev->mode_config.fb_base = dev_priv->gtt.mappable_base;
DRM_DEBUG_KMS("%d display pipe%s available.\n",
--
1.8.3.2
--
keith.packard at intel.com
[Bug 66963] r600: linux 3.11RC1 isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #6 from Scias --- Same situation here on a RV635/HD3650 and on a RC-2 kernel. The new radeon.aspm=0 parameter doesn't help either. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/f886edf4/attachment.html>
[Bug 67178] discrete radeon HD 6400M/7400M intense heating even though it's "off"
https://bugs.freedesktop.org/show_bug.cgi?id=67178 --- Comment #1 from Tomas Pospisek --- Created attachment 82828 --> https://bugs.freedesktop.org/attachment.cgi?id=82828=edit dmesg dmesg with wlan stuff edited out -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/0094d83a/attachment-0001.html>
[Bug 59322] r300g MSAA breaks Half-Life 2 in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=59322 --- Comment #10 from Stefan D?singer --- Fwiw, there's probably a bug in Wine as well. We shouldn't try to render to sRGB formats if framebuffer_sRGB is not supported, but giving textures an sRGB format is the only way to make use of sRGB_decode. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/ddc71fda/attachment.html>
[Bug 59322] r300g MSAA breaks Half-Life 2 in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=59322 --- Comment #9 from Stefan D?singer --- (In reply to comment #8) > Is it a big deal that ARB_framebuffer_sRGB is unsupported? In such a case, > the renderbuffer format GL_SRGB8_ALPHA8 is equivalent to GL_RGBA8. Not really. In this case we generate code in the pixel shader that performs sRGB color conversion as specified in the framebuffer_sRGB spec. Do r300-r500 GPUs have some dedicated silicon to handle sRGB conversion? If so, it'd be nice to use it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/5d1faa9b/attachment.html>
[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
On 07/22/2013 03:31 PM, Inki Dae wrote:
>> ---Original Message-
>> > From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
>> > owner at vger.kernel.org] On Behalf Of Lucas Stach
>> > Sent: Monday, July 22, 2013 9:47 PM
>> > To: Inki Dae
>> > Cc: 'Mark Rutland'; 'Chanho Park'; linux-samsung-soc at vger.kernel.org;
>> > devicetree-discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
>> > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
>> > kgene.kim at samsung.com; linux-arm-kernel at lists.infradead.org
>> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
>> > rotator
>> >
>> > Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
>>> > >
> > > -Original Message-
> > > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > > Sent: Monday, July 22, 2013 5:48 PM
> > > To: Chanho Park
> > > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> > > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > > devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> > > linux-arm-
> > > kernel at lists.infradead.org
> > > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> > > rotator
> > >
> > > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > > > This patch adds a dt-binding document for exynos rotator. It
>> > describes
> > > which
> > > > > nodes should be defined to use the rotator.
> > > > >
> > > > > Signed-off-by: Chanho Park
> > > > > Signed-off-by: Kyungmin Park
> > > > > ---
> > > > > .../bindings/drm/exynos/samsung-rotator.txt| 35
> > >
> > > > > 1 file changed, 35 insertions(+)
> > > > > create mode 100644
> > > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > > rotator.txt
> > > > > new file mode 100644
> > > > > index 000..6b1d704
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-
>> > rotator.txt
> > > > > @@ -0,0 +1,35 @@
> > > > > +* Samsung Image Rotator
> > > > > +
> > > > > +Required properties:
> > > > > + - compatible : value should be the "samsung,exynos4210".
>>> > >
>>> > > Please, add more compatible strings for other SoC.
>>> > >
> > > > > + - reg : Physical base address of the IP registers and length of
> > > memory
> > > > > + mapped region.
> > > > > + - interrupts : interrupt number to the CPU.
> > > > > + - clocks : clock number of exynos4 rotator clock.
> > > > > + - clocks : clock name of rotator
> > >
> > > clock-names?
> > >
> > > > > + - status : "okay" or "disabled"
> > > > > + - limit table for image formats : min_w/min_h/max_w/max_h for
>> > min/max
> > > of image
> > >
> > > Limit table? This doesn't seem to be a well-defined binding, and it
> > > seems like a relatively generic thing to describe.
> > >
> > > > > +
> > > > > +Example:
> > > > > + rotator: rotator at 1281 {
> > > > > + compatible = "samsung,exynos4210-rotator";
> > > > > + reg = <0x1281 0x1000>;
> > > > > + interrupts = <0 83 0>;
> > > > > + clocks = < 278>;
> > > > > + clock-names = "rotator";
> > > > > + status = "disabled";
> > > > > + ycbcr420_2p {
> > >
> > > Which names are allowed for these subnodes?
> > >
> > > > > + min_w = <32>;
> > > > > + min_h = <32>;
> > > > > + max_w = <32768>;
> > > > > + max_h = <32768>;
> > > > > + align = <3>;
> > >
> > > min-width, min-height, max-width, max-height? What units are they in?
> > >
> > > What does alignment specify exactly?
> > >
> > > Are these a configurable part of the rotator hardware, or are these
> > > values always the same?
>>> > >
>>> > > Right, that seems like configurable part. At least, min_w/h and max_w/h
>> > can
>>> > > be different values according to SoC and pixel formats so they should be
>>> > > described enough in this dt-binding document file.
>>> > >
>> > Is there really this much configurability? Could each of those values be
>> > a different on different SoCs
> Not much but Yes. Rotator devices of Exynos SoC support various pixel
> formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane, and each
> of these pixel formats could be different limitation to minimum and maximum
> sizes.
> For example, the below shows the limitation to Rotator
[PATCH 3/3] dts: ARM: add a rotator node for exynos4
This patch adds a device node of rotator for exynos4 platform. It has proper
register and clock information. It also has limit table to get restrictions of
the image size.
Signed-off-by: Chanho Park
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 3f94fe8..7d7dcef 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -398,4 +398,27 @@
samsung,power-domain = <_lcd0>;
status = "disabled";
};
+
+ rotator: rotator at 1281 {
+ compatible = "samsung,exynos4210-rotator";
+ reg = <0x1281 0x1000>;
+ interrupts = <0 83 0>;
+ clocks = < 278>;
+ clock-names = "rotator";
+ status = "disabled";
+ ycbcr420_2p {
+ min_w = <32>;
+ min_h = <32>;
+ max_w = <32768>;
+ max_h = <32768>;
+ align = <3>;
+ };
+ rgb888 {
+ min_w = <8>;
+ min_h = <8>;
+ max_w = <8192>;
+ max_h = <8192>;
+ align = <2>;
+ };
+ };
};
--
1.7.9.5
[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
This patch adds a dt-binding document for exynos rotator. It describes which
nodes should be defined to use the rotator.
Signed-off-by: Chanho Park
Signed-off-by: Kyungmin Park
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the "samsung,exynos4210".
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
+ - status : "okay" or "disabled"
+ - limit table for image formats : min_w/min_h/max_w/max_h for min/max of
image
+
+Example:
+ rotator: rotator at 1281 {
+ compatible = "samsung,exynos4210-rotator";
+ reg = <0x1281 0x1000>;
+ interrupts = <0 83 0>;
+ clocks = < 278>;
+ clock-names = "rotator";
+ status = "disabled";
+ ycbcr420_2p {
+ min_w = <32>;
+ min_h = <32>;
+ max_w = <32768>;
+ max_h = <32768>;
+ align = <3>;
+ };
+ rgb888 {
+ min_w = <8>;
+ min_h = <8>;
+ max_w = <8192>;
+ max_h = <8192>;
+ align = <2>;
+ };
+ };
--
1.7.9.5
[PATCH 1/3] drm/exynos: add device tree support for rotator
The exynos4 platform is only dt-based since 3.10, we should convert driver data
and ids to dt-based parsing methods. The rotator driver has a limit table to get
size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is 8K x
8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K max
size. Each format should be multiple of 'align' value.
Signed-off-by: Chanho Park
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 110 +++
1 file changed, 80 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 427640a..b353a10 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -96,7 +96,7 @@ struct rot_context {
struct resource *regs_res;
void __iomem*regs;
struct clk *clock;
- struct rot_limit_table *limit_tbl;
+ struct rot_limit_table limit_tbl;
int irq;
int cur_buf_id[EXYNOS_DRM_OPS_MAX];
boolsuspended;
@@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void *arg)
static void rotator_align_size(struct rot_context *rot, u32 fmt, u32 *hsize,
u32 *vsize)
{
- struct rot_limit_table *limit_tbl = rot->limit_tbl;
+ struct rot_limit_table *limit_tbl = >limit_tbl;
struct rot_limit *limit;
u32 mask, val;
@@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
return 0;
}
+static const struct of_device_id exynos_rotator_match[] = {
+ {
+ .compatible = "samsung,exynos4210-rotator",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_rotator_match);
+
+static int rotator_parse_dt_tbl(struct device_node *np, struct rot_limit *rlim)
+{
+ int ret;
+
+ ret = of_property_read_u32(np, "min_w", >min_w);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, "min_h", >min_h);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, "max_w", >max_w);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, "max_h", >max_h);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, "align", >align);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int rotator_parse_dt(struct device *dev, struct rot_context *rot)
+{
+ struct device_node *ycbcr_node, *rgb888_node;
+ int ret;
+
+ ycbcr_node = of_get_child_by_name(dev->of_node, "ycbcr420_2p");
+ if (!ycbcr_node) {
+ dev_err(dev, "can't find ycbcr420_2p node\n");
+ return -ENODEV;
+ }
+
+ rgb888_node = of_get_child_by_name(dev->of_node, "rgb888");
+ if (!rgb888_node) {
+ dev_err(dev, "can't find rgb888 node\n");
+ return -ENODEV;
+ }
+
+ ret = rotator_parse_dt_tbl(ycbcr_node, >limit_tbl.ycbcr420_2p);
+ if (ret) {
+ dev_err(dev, "failed to parse ycbcr420 data\n");
+ return ret;
+ }
+ ret = rotator_parse_dt_tbl(rgb888_node, >limit_tbl.rgb888);
+ if (ret) {
+ dev_err(dev, "failed to parse rgb888 data\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static int rotator_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device *pdev)
struct exynos_drm_ippdrv *ippdrv;
int ret;
+ if (!dev->of_node) {
+ dev_err(dev, "Cannot find device tree node\n");
+ return -ENODEV;
+ }
+
rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
if (!rot) {
dev_err(dev, "failed to allocate rot\n");
return -ENOMEM;
}
- rot->limit_tbl = (struct rot_limit_table *)
- platform_get_device_id(pdev)->driver_data;
+ ret = rotator_parse_dt(dev, rot);
+ if (ret) {
+ dev_err(dev, "failed parse dt info\n");
+ devm_kfree(dev, rot);
+ return ret;
+ }
rot->regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
rot->regs = devm_ioremap_resource(dev, rot->regs_res);
@@ -718,31 +793,6 @@ static int rotator_remove(struct platform_device *pdev)
return 0;
}
-static struct rot_limit_table rot_limit_tbl = {
- .ycbcr420_2p = {
- .min_w = 32,
- .min_h = 32,
- .max_w = SZ_32K,
- .max_h = SZ_32K,
- .align = 3,
- },
- .rgb888 = {
- .min_w = 8,
- .min_h = 8,
- .max_w = SZ_8K,
- .max_h = SZ_8K,
- .align = 2,
- },
-};
-
-static struct platform_device_id
[PATCH 0/3] device tree support for exynos rotator
This patchset includes dt support for exynos rotator. The exynos4 platform is only dt-based since 3.10, we should convert driver data and ids to dt-based parsing methods. The rotator driver has a limit table to get size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is 8K x 8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K max size. Each format should be multiple of 'align' value. Chanho Park (3): drm/exynos: add device tree support for rotator drm/exynos: add dt-binding documentation for rotator dts: ARM: add a rotator node for exynos4 .../bindings/drm/exynos/samsung-rotator.txt| 35 +++ arch/arm/boot/dts/exynos4.dtsi | 23 drivers/gpu/drm/exynos/exynos_drm_rotator.c| 110 ++-- 3 files changed, 138 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt -- 1.7.9.5
[Bug 67178] New: discrete radeon HD 6400M/7400M intense heating even though it's "off"
https://bugs.freedesktop.org/show_bug.cgi?id=67178 Priority: medium Bug ID: 67178 Assignee: dri-devel at lists.freedesktop.org Summary: discrete radeon HD 6400M/7400M intense heating even though it's "off" Severity: normal Classification: Unclassified OS: Linux (All) Reporter: tpo_deb at sourcepole.ch Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI kernel 3.11-rc1 (also tested with 3.10 from Debian, 3.7, 3,2) # lspci -vnnn | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] [1002:6760] (rev ff) (prog-if ff) This is a HP Pavillon dv7 6130ez Sometimes, at random, the radeon card goes into full heat production mode. This seems to occur a while (a few minutes?) after wakeup from resume, however I'm not sure about that. Suspending and resuming the laptop a few times (1 <= x <= ~4) seems to calm the card down again. Power consumption according to powertop goes from ~14W up to ~50W. This happens even though the card should be in theory switched off. Aka: # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Off::01:00.0 # echo IGD > /sys/kernel/debug/vgaswitcheroo/switch # echo OFF > /sys/kernel/debug/vgaswitcheroo/switch doesn't seem to have no effect whatsoever. It *seems* that setting "radeon.dpm=1" kernel boot options and then: # echo "battery" > /sys/class/drm/card$no/device/power_dpm_state puts the card in an "active" but "relatively low" power consumption mode. It is then using about 20W (instead of the "normal" ~14W) so it's continuously faning out slightly warm air. And it "seems that when the card is running in this mode, then it won't get so often, or ever (I'm not very sure) into the berserk heating mode. The lowest observed power consumption of the laptop is ~7W. It'd be very nice if it'd be possible to shut the card down electrically via software and stay in this 7W mode. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/11a58852/attachment.html>
[Bug 38954] Add an option to switch from low to mid/high power states
https://bugs.freedesktop.org/show_bug.cgi?id=38954 --- Comment #2 from muziofg at email.it --- This new feature is a good work, seems to be a solution who goes in the right direction, but I think to close this bug after a test. Thanks for your work -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/0fcefa6a/attachment.html>
[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
>
> > -Original Message-
> > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > Sent: Monday, July 22, 2013 5:48 PM
> > To: Chanho Park
> > Cc: inki.dae at samsung.com; kgene.kim at samsung.com; linux-samsung-
> > soc at vger.kernel.org; jy0922.shim at samsung.com; devicetree-
> > discuss at lists.ozlabs.org; sw0312.kim at samsung.com; dri-
> > devel at lists.freedesktop.org; kyungmin.park at samsung.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
> > rotator
> >
> > On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> > > This patch adds a dt-binding document for exynos rotator. It describes
> > which
> > > nodes should be defined to use the rotator.
> > >
> > > Signed-off-by: Chanho Park
> > > Signed-off-by: Kyungmin Park
> > > ---
> > > .../bindings/drm/exynos/samsung-rotator.txt| 35
> >
> > > 1 file changed, 35 insertions(+)
> > > create mode 100644
> > Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
> > rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
> > rotator.txt
> > > new file mode 100644
> > > index 000..6b1d704
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> > > @@ -0,0 +1,35 @@
> > > +* Samsung Image Rotator
> > > +
> > > +Required properties:
> > > + - compatible : value should be the "samsung,exynos4210".
>
> Please, add more compatible strings for other SoC.
>
> > > + - reg : Physical base address of the IP registers and length of
> > memory
> > > + mapped region.
> > > + - interrupts : interrupt number to the CPU.
> > > + - clocks : clock number of exynos4 rotator clock.
> > > + - clocks : clock name of rotator
> >
> > clock-names?
> >
> > > + - status : "okay" or "disabled"
> > > + - limit table for image formats : min_w/min_h/max_w/max_h for min/max
> > of image
> >
> > Limit table? This doesn't seem to be a well-defined binding, and it
> > seems like a relatively generic thing to describe.
> >
> > > +
> > > +Example:
> > > + rotator: rotator at 1281 {
> > > + compatible = "samsung,exynos4210-rotator";
> > > + reg = <0x1281 0x1000>;
> > > + interrupts = <0 83 0>;
> > > + clocks = < 278>;
> > > + clock-names = "rotator";
> > > + status = "disabled";
> > > + ycbcr420_2p {
> >
> > Which names are allowed for these subnodes?
> >
> > > + min_w = <32>;
> > > + min_h = <32>;
> > > + max_w = <32768>;
> > > + max_h = <32768>;
> > > + align = <3>;
> >
> > min-width, min-height, max-width, max-height? What units are they in?
> >
> > What does alignment specify exactly?
> >
> > Are these a configurable part of the rotator hardware, or are these
> > values always the same?
>
> Right, that seems like configurable part. At least, min_w/h and max_w/h can
> be different values according to SoC and pixel formats so they should be
> described enough in this dt-binding document file.
>
Is there really this much configurability? Could each of those values be
a different on different SoCs, or could you just extract those values
from the SoC/rotator hardware version and thus the DT compatible string?
>
> > If thery're always the same, there's no need to
> > describe in in the devicetree.
> >
> > Thanks,
> > Mark.
> >
> > > + };
> > > + rgb888 {
> > > + min_w = <8>;
> > > + min_h = <8>;
> > > + max_w = <8192>;
> > > + max_h = <8192>;
> > > + align = <2>;
> > > + };
> > > + };
> > > --
> > > 1.7.9.5
> > >
> > >
> > > ___
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > >
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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- |
[Bug 41420] [UPSTREAM REPOST] radeon driver power management is very bad: GPU always runs at maximum clock speed
https://bugs.freedesktop.org/show_bug.cgi?id=41420 --- Comment #1 from Tomas Pospisek --- Does this change anything?: http://www.botchco.com/agd5f/?p=57 Available in kernel 3.11 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/5e0d2e62/attachment.html>
[Bug 39267] Dynamic power management does not work on HD5870
https://bugs.freedesktop.org/show_bug.cgi?id=39267 --- Comment #1 from Tomas Pospisek --- Does anything change if you use kernel >= 3.11? See http://www.botchco.com/agd5f/?p=57 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/b7f49bc7/attachment.html>
[Bug 39063] RV630: Sapphire HD 2600 XT power management doesnt work.
https://bugs.freedesktop.org/show_bug.cgi?id=39063 --- Comment #8 from Tomas Pospisek --- radeon has got some new power management infrastructure: http://www.botchco.com/agd5f/?p=57 Does that change anything wrt this bug? Btw. here: # uname -a Linux hier 3.11.0-rc1 #2 SMP Sun Jul 21 12:29:18 CEST 2013 x86_64 GNU/Linux (booted with radeon.dpm=1) # lspci | grep Radeon 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] (rev ff) # cat rom cat: rom: Invalid argument # echo 1 > rom # cat rom cat: rom: input/output error # translated from german -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/64dae0c8/attachment-0001.html>
[Bug 38954] Add an option to switch from low to mid/high power states
https://bugs.freedesktop.org/show_bug.cgi?id=38954 --- Comment #1 from Tomas Pospisek --- See http://www.botchco.com/agd5f/?p=57 Is this what you need (and this bug can be closed?)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/9f40e961/attachment.html>
[Bug 38917] [patch] Radeon clocks should not be limited to defaults
https://bugs.freedesktop.org/show_bug.cgi?id=38917 --- Comment #4 from Tomas Pospisek --- As of linux 3.11 there is additional power management infrastructure for radeons: http://www.botchco.com/agd5f/?p=57 Does that change anything wrt the here required functionality respectively this bug report? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/e650dca8/attachment.html>
[PATCH v3 3/4] drm/ttm: convert to unified vma offset manager
On 07/22/2013 12:55 PM, David Herrmann wrote: > Sorry, I forgot to CC correctly. > > On Mon, Jul 22, 2013 at 12:53 PM, David Herrmann > wrote: >> Hi >> >> On Fri, Jul 19, 2013 at 11:13 AM, Thomas Hellstrom >> wrote: >>> On 07/18/2013 10:54 PM, David Herrmann wrote: Hi On Thu, Jul 18, 2013 at 1:24 PM, Thomas Hellstrom >>> vmware.com> wrote: >>> >>> ... >>> >>> > I think that if there are good reasons to keep locking internal, I'm fine > with that, (And also, of course, with > Daniel's proposal). Currently the add / remove / lookup paths are mostly > used by TTM during object creation and > destruction. > > However, if the lookup path is ever used by pread / pwrite, that > situation > might change and we would then like to > minimize the locking. I tried to keep the change as minimal as I could. Follow-up patches are welcome. I just thought pushing the lock into drm_vma_* would simplify things. If there are benchmarks that prove me wrong, I'll gladly spend some time optimizing that. >>> >>> In the general case, one reason for designing the locking outside of a >>> utilities like this, is that different callers may have >>> different requirements. For example, the call path is known not to be >>> multithreaded at all, or >>> the caller may prefer a mutex over a spinlock for various reasons. It might >>> also be that some callers will want to use >>> RCU locking in the future if the lookup path becomes busy, and that would >>> require *all* users to adapt to RCU object destruction... >>> >>> I haven't looked at the code closely enough to say that any of this applies >>> in this particular case, though. >> Some notes why I went with local locking: >> - mmap offset creation is done once and is independent of any other >> operations you might do on the BO in parallel >> - mmap lookup is also only done once in most cases. User-space rarely >> maps a buffer twice (setup/teardown of mmaps is expensive, but keeping >> them around is very cheap). And for shared buffers only the writer >> maps it as the reader normally passes it to the kernel without >> mapping/touching it. Only for software-rendering we have two or more >> mappings of the same object. >> - creating/mapping/destroying buffer objects is expensive in its >> current form and buffers tend to stay around for a long time >> >> I couldn't find a situation were the vma-manager was part of a >> performance critical path. But on the other hand, the paths were it is >> used are quite heavy. That's why I don't want to lock the whole buffer >> or even device. Instead, we need some "management lock" which is used >> for mmap-setup or similar things that don't affect other operations on >> the buffer or device. We don't have such a lock, so I introduced local >> locking. If we end up with more use-cases, I volunteer to refactor >> this. But I am no big fan of overgeneralizing it before more uses are >> known. I think we are discussing two different things here: 1) Having a separate lock for vma management vs 2) building that lock into the vma manager utility. You're arguing for 1) and I completely agree with you, and although I still think one generally should avoid building locks into utilities like this (avoid 2), I'm fine with the current approach. Thanks, Thomas
[Bug 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #12 from Alexandre Demers --- (In reply to comment #11) > Does it boot correctly if you build radeon as a module, then disable radeon > (add radeon.modeset=0 to your kernel command line in grub) and boot to a > non-X runlevel, then load radeon manually? > > modprobe -r radeon > modprobe radeon modeset=1 No, sadly, it still hangs at the same place. Problem is, I can't tell if it hangs when loading the initramfs or when it tries to initialize the display beyond that... Any other suggestion? By the way, I built an 3.11.0-rc2 kernel this morning with as few drivers as possible for my system, just in case, but without any luck. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/164ce284/attachment.html>
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #13 from hadack at gmx.de --- It is described in the building from source section here: http://www.opentk.com/doc/chapter/1/linux I did this in the opentk folder: xbuild OpenTK.sln /p:Configuration=Debug cd Binaries/OpenTK/Debug mono Examples.exe Some OpenGL examples show similar symptoms, they just stop at some point, others are quitting with a timelimit exceeded message. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/a5b23090/attachment.html>
[PATCH v3 3/4] drm/ttm: convert to unified vma offset manager
Sorry, I forgot to CC correctly. On Mon, Jul 22, 2013 at 12:53 PM, David Herrmann wrote: > Hi > > On Fri, Jul 19, 2013 at 11:13 AM, Thomas Hellstrom > wrote: >> On 07/18/2013 10:54 PM, David Herrmann wrote: >>> >>> Hi >>> >>> On Thu, Jul 18, 2013 at 1:24 PM, Thomas Hellstrom >>> wrote: >> >> >> ... >> >> I think that if there are good reasons to keep locking internal, I'm fine with that, (And also, of course, with Daniel's proposal). Currently the add / remove / lookup paths are mostly used by TTM during object creation and destruction. However, if the lookup path is ever used by pread / pwrite, that situation might change and we would then like to minimize the locking. >>> >>> I tried to keep the change as minimal as I could. Follow-up patches >>> are welcome. I just thought pushing the lock into drm_vma_* would >>> simplify things. If there are benchmarks that prove me wrong, I'll >>> gladly spend some time optimizing that. >> >> >> In the general case, one reason for designing the locking outside of a >> utilities like this, is that different callers may have >> different requirements. For example, the call path is known not to be >> multithreaded at all, or >> the caller may prefer a mutex over a spinlock for various reasons. It might >> also be that some callers will want to use >> RCU locking in the future if the lookup path becomes busy, and that would >> require *all* users to adapt to RCU object destruction... >> >> I haven't looked at the code closely enough to say that any of this applies >> in this particular case, though. > > Some notes why I went with local locking: > - mmap offset creation is done once and is independent of any other > operations you might do on the BO in parallel > - mmap lookup is also only done once in most cases. User-space rarely > maps a buffer twice (setup/teardown of mmaps is expensive, but keeping > them around is very cheap). And for shared buffers only the writer > maps it as the reader normally passes it to the kernel without > mapping/touching it. Only for software-rendering we have two or more > mappings of the same object. > - creating/mapping/destroying buffer objects is expensive in its > current form and buffers tend to stay around for a long time > > I couldn't find a situation were the vma-manager was part of a > performance critical path. But on the other hand, the paths were it is > used are quite heavy. That's why I don't want to lock the whole buffer > or even device. Instead, we need some "management lock" which is used > for mmap-setup or similar things that don't affect other operations on > the buffer or device. We don't have such a lock, so I introduced local > locking. If we end up with more use-cases, I volunteer to refactor > this. But I am no big fan of overgeneralizing it before more uses are > known. > > Anyway, I will resend with vm_lock removed (+_unlocked() helpers) so > we keep the status-quo regarding locks. Thanks for the comments on TTM > buffer transfer. > > Thanks > David
[Bug 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #5 from Marco Scannadinari --- Created attachment 82816 --> https://bugs.freedesktop.org/attachment.cgi?id=82816=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/8facc2a7/attachment.html>
[Bug 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #4 from Marco Scannadinari --- Created attachment 82815 --> https://bugs.freedesktop.org/attachment.cgi?id=82815=edit journalctl -b -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/d96bd81d/attachment-0001.html>
[Bug 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #3 from Marco Scannadinari --- Created attachment 82814 --> https://bugs.freedesktop.org/attachment.cgi?id=82814=edit uname -a -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/99b6d74d/attachment.html>
[Bug 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #2 from Alex Deucher --- What kernel are you using? Please attach your dmesg output. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/2ac93e3c/attachment.html>
[Bug 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 Marco Scannadinari changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=61463 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/6df7b010/attachment.html>
[Bug 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 Marco Scannadinari changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Severity|normal |major Priority|medium |high CC||marco at scannadinari.co.uk --- Comment #1 from Marco Scannadinari --- Possibly related to Bug 61463? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/f9a19c7e/attachment.html>
[Bug 67169] New: Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 Priority: medium Bug ID: 67169 Assignee: dri-devel at lists.freedesktop.org Summary: Black screen after waking from sleep Severity: normal Classification: Unclassified OS: All Reporter: marco at scannadinari.co.uk Hardware: Other Status: NEW Version: 9.1 Component: Drivers/DRI/Radeon Product: Mesa Created attachment 82813 --> https://bugs.freedesktop.org/attachment.cgi?id=82813=edit xorg log Waking the screen from sleep wakes it but all i get is a black screen. I am able to type and change ttys, etc, but after `systemctl restart gdm` as root the screen gets 'No signal'. The setting that causes this is GNOME's 'Blank screen' option in Settings>Power>Blank Screen I can confirm that AMD's proprietary drivers fix this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130722/d4d36176/attachment.html>
[PATCH] drm: don't call ->firstopen for KMS drivers
Hi Daniel,
Thank you for the patch.
On Saturday 13 July 2013 16:45:10 Daniel Vetter wrote:
> It has way too much potential for driver writers to do stupid things
> like delayed hw setup because the load sequence is somehow racy (e.g.
> the imx driver in staging). So don't call it for modesetting drivers,
> which reduces the complexity of the drm core -> driver interface a
> notch.
>
> v2: Don't forget to update DocBook.
>
> v3: Go with Laurent's slightly more elaborate proposal for the DocBook
> update. Add a few words on top of his diff to elaborate a bit on what
> KMS drivers should and shouldn't do in lastclose. There was already a
> paragraph present talking about restoring properties, I've simply
> extended that one.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
Acked-by: Laurent Pinchart
> ---
> Documentation/DocBook/drm.tmpl | 27 ---
> drivers/gpu/drm/drm_fops.c | 3 ++-
> 2 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 4d54ac8..52d5eda 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
>
> The firstopen method is called by the DRM
> core -when an application opens a device that has no other opened file
> handle. - Similarly the lastclose method is
called
> when -the last application holding a file handle opened on the device
> closes - it. Both methods are mostly used for UMS (User Mode Setting)
> drivers to - acquire and release device resources which should be done in
> the - load and unload
> - methods for KMS drivers.
> + for legacy UMS (User Mode Setting) drivers only when an application
> + opens a device that has no other opened file handle. UMS drivers can
> + implement it to acquire device resources. KMS drivers can't use the
> + method and must acquire resources in the load
> + method instead.
>
>
> -Note that the lastclose method is also
> called - at module unload time or, for hot-pluggable devices, when the
> device is - unplugged. The firstopen and
> + Similarly the lastclose method is called when
> + the last application holding a file handle opened on the device closes
> + it, for both UMS and KMS drivers. Additionally, the method is also
> + called at module unload time or, for hot-pluggable devices, when the
> + device is unplugged. The firstopen and
> lastclose calls can thus be unbalanced.
>
>
> @@ -2462,7 +2462,12 @@ void (*postclose) (struct drm_device *, struct
> drm_file *);
> The lastclose method should restore CRTC
> and plane properties to default value, so that a subsequent open of the
> - device will not inherit state from the previous user.
> + device will not inherit state from the previous user. It can also be
> + used to execute delayed power switching state changes, e.g. in
> + conjunction with the vga-switcheroo infrastructure. Beyond that KMS
> + drivers should not do any further cleanup. Only legacy UMS drivers might
> + need to clean up device state so that the vga console or an independent
> + fbdev driver could take over.
>
>
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 57e3014..fcde7d4 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
> int i;
> int ret;
>
> - if (dev->driver->firstopen) {
> + if (dev->driver->firstopen &&
> + !drm_core_check_feature(dev, DRIVER_MODESET)) {
> ret = dev->driver->firstopen(dev);
> if (ret != 0)
> return ret;
--
Regards,
Laurent Pinchart
[PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> This patch adds a dt-binding document for exynos rotator. It describes which
> nodes should be defined to use the rotator.
>
> Signed-off-by: Chanho Park
> Signed-off-by: Kyungmin Park
> ---
> .../bindings/drm/exynos/samsung-rotator.txt| 35
>
> 1 file changed, 35 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> new file mode 100644
> index 000..6b1d704
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
> @@ -0,0 +1,35 @@
> +* Samsung Image Rotator
> +
> +Required properties:
> + - compatible : value should be the "samsung,exynos4210".
> + - reg : Physical base address of the IP registers and length of memory
> + mapped region.
> + - interrupts : interrupt number to the CPU.
> + - clocks : clock number of exynos4 rotator clock.
> + - clocks : clock name of rotator
clock-names?
> + - status : "okay" or "disabled"
> + - limit table for image formats : min_w/min_h/max_w/max_h for min/max of
> image
Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.
> +
> +Example:
> + rotator: rotator at 1281 {
> + compatible = "samsung,exynos4210-rotator";
> + reg = <0x1281 0x1000>;
> + interrupts = <0 83 0>;
> + clocks = < 278>;
> + clock-names = "rotator";
> + status = "disabled";
> + ycbcr420_2p {
Which names are allowed for these subnodes?
> + min_w = <32>;
> + min_h = <32>;
> + max_w = <32768>;
> + max_h = <32768>;
> + align = <3>;
min-width, min-height, max-width, max-height? What units are they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are these
values always the same? If thery're always the same, there's no need to
describe in in the devicetree.
Thanks,
Mark.
> + };
> + rgb888 {
> + min_w = <8>;
> + min_h = <8>;
> + max_w = <8192>;
> + max_h = <8192>;
> + align = <2>;
> + };
> + };
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
[PULL] drm-intel-fixes
Hi Dave, Like I've said yesterday I've originally wanted to include a hdmi regression fix for modes with dotclocks > 165MHz, but this morning (after reading the test result from QA) I've noticed that I've fumbled something. So that patch has to take another round. So that regression is still open, but otherwise this pull request here resolves everything else outstanding: - fixup panel fitter readout for gen2/3 (just quitens dmesg noise) - fix pft computations for non-autoscaled resolutions (i.e. letter/pillar boxing on gen2/3) - preserve the DDI A/E lane sharing bit (St?phane Marchesin) - fix the "rc6 fails to work after resume" regression, big thanks to Konstantin Khlebnikov for the patch and debug insight about what actually might be going on here - fix Oops in is_crtc_connector_off (Chris) - sanitize shared dpll state - our new paranoid state checker tripped up over dirt left behind by the BIOS - correctly restore fences, fixes the "my screen is all messed up after resume" regression introduced in the final 3.10 pull request - quirk backlights harder, this time for Dell XPS13 machines to fix a regression (patch from Kamal Mostafa) - 90% fix for some haswell hangs when accessing registers concurrently, the 100% solution is simply too invasive for -fixes and what we have here seems to be good enough (Chris) Cheers, Daniel The following changes since commit 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" (2013-07-10 15:31:12 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-22 for you to fetch changes up to 181d1b9e31c668259d3798c521672afb8edd355c: drm/i915: fix up gt init sequence fallout (2013-07-21 15:37:02 +0200) Chris Wilson (2): drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() drm/i915: Serialize almost all register access Daniel Vetter (6): drm/i915: fix up readout of the lvds dither bit on gen2/3 drm/i915: fix pfit regression for non-autoscaled resolutions drm/i915: Sanitize shared dpll state Merge tag 'v3.10' into drm-intel-fixes drm/i915: correctly restore fences with objects attached drm/i915: fix up gt init sequence fallout Kamal Mostafa (1): drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight Konstantin Khlebnikov (1): drm/i915: fix long-standing SNB regression in power consumption after resume v2 St?phane Marchesin (1): drm/i915: Preserve the DDI_A_4_LANES bit from the bios Documentation/networking/ip-sysctl.txt |4 +- MAINTAINERS|2 +- Makefile |2 +- arch/arm/Kconfig | 14 + arch/arm/include/asm/cputype.h |2 + arch/arm/include/asm/glue-proc.h |9 + arch/arm/include/asm/smp_plat.h|2 +- arch/arm/kernel/devtree.c | 10 +- arch/arm/kernel/setup.c|2 +- arch/arm/mm/nommu.c|6 + arch/arm/mm/proc-fa526.S |1 - arch/arm/mm/proc-macros.S |5 + arch/arm/mm/proc-v7.S | 34 +- arch/mn10300/include/asm/uaccess.h |2 +- arch/mn10300/kernel/setup.c| 54 +- arch/powerpc/kernel/pci-common.c | 17 +- arch/powerpc/platforms/pseries/eeh_cache.c |4 +- arch/powerpc/platforms/pseries/eeh_pe.c|3 +- arch/x86/kernel/kprobes/core.c | 14 +- crypto/algboss.c | 15 +- crypto/api.c |6 - crypto/internal.h |6 + drivers/acpi/dock.c| 179 ++- drivers/acpi/internal.h|5 + drivers/acpi/scan.c|1 + drivers/ata/libata-acpi.c | 37 +- drivers/ata/libata-core.c |2 + drivers/ata/libata.h |2 + drivers/block/rbd.c| 14 +- drivers/bluetooth/btmrvl_main.c|9 +- drivers/cpufreq/cpufreq_ondemand.c | 17 +- drivers/gpio/gpio-omap.c | 22 +- drivers/gpu/drm/i915/i915_dma.c| 18 +- drivers/gpu/drm/i915/i915_drv.c| 13 +- drivers/gpu/drm/i915/i915_drv.h|5 +- drivers/gpu/drm/i915/i915_gem.c| 36 +- drivers/gpu/drm/i915/i915_suspend.c|1 +
PATCH - RADEON patch update for 3.10.1 urgency low
> did some re-design of the patch for detecting power modes in PowerPlayTable, > I > hope this version looks a little bit smarter. Quality check with my muxless > HD 6490M > succesful, integrity/sanity checks for other asics like si/r600 which use > the > radeon_atombios_parse_power_table_4_5 are to be done. > ? > Best wishes and regards, > ? > Michael Schuster Hi, I've cc'ed the lists, and Alex the radeon maintainer. Dave.
[PULL] drm-intel-fixes
Hi Dave, Like I've said yesterday I've originally wanted to include a hdmi regression fix for modes with dotclocks 165MHz, but this morning (after reading the test result from QA) I've noticed that I've fumbled something. So that patch has to take another round. So that regression is still open, but otherwise this pull request here resolves everything else outstanding: - fixup panel fitter readout for gen2/3 (just quitens dmesg noise) - fix pft computations for non-autoscaled resolutions (i.e. letter/pillar boxing on gen2/3) - preserve the DDI A/E lane sharing bit (Stéphane Marchesin) - fix the rc6 fails to work after resume regression, big thanks to Konstantin Khlebnikov for the patch and debug insight about what actually might be going on here - fix Oops in is_crtc_connector_off (Chris) - sanitize shared dpll state - our new paranoid state checker tripped up over dirt left behind by the BIOS - correctly restore fences, fixes the my screen is all messed up after resume regression introduced in the final 3.10 pull request - quirk backlights harder, this time for Dell XPS13 machines to fix a regression (patch from Kamal Mostafa) - 90% fix for some haswell hangs when accessing registers concurrently, the 100% solution is simply too invasive for -fixes and what we have here seems to be good enough (Chris) Cheers, Daniel The following changes since commit 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: Revert drm/i915: Workaround incoherence between fences and LLC across multiple CPUs (2013-07-10 15:31:12 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-22 for you to fetch changes up to 181d1b9e31c668259d3798c521672afb8edd355c: drm/i915: fix up gt init sequence fallout (2013-07-21 15:37:02 +0200) Chris Wilson (2): drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() drm/i915: Serialize almost all register access Daniel Vetter (6): drm/i915: fix up readout of the lvds dither bit on gen2/3 drm/i915: fix pfit regression for non-autoscaled resolutions drm/i915: Sanitize shared dpll state Merge tag 'v3.10' into drm-intel-fixes drm/i915: correctly restore fences with objects attached drm/i915: fix up gt init sequence fallout Kamal Mostafa (1): drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight Konstantin Khlebnikov (1): drm/i915: fix long-standing SNB regression in power consumption after resume v2 Stéphane Marchesin (1): drm/i915: Preserve the DDI_A_4_LANES bit from the bios Documentation/networking/ip-sysctl.txt |4 +- MAINTAINERS|2 +- Makefile |2 +- arch/arm/Kconfig | 14 + arch/arm/include/asm/cputype.h |2 + arch/arm/include/asm/glue-proc.h |9 + arch/arm/include/asm/smp_plat.h|2 +- arch/arm/kernel/devtree.c | 10 +- arch/arm/kernel/setup.c|2 +- arch/arm/mm/nommu.c|6 + arch/arm/mm/proc-fa526.S |1 - arch/arm/mm/proc-macros.S |5 + arch/arm/mm/proc-v7.S | 34 +- arch/mn10300/include/asm/uaccess.h |2 +- arch/mn10300/kernel/setup.c| 54 +- arch/powerpc/kernel/pci-common.c | 17 +- arch/powerpc/platforms/pseries/eeh_cache.c |4 +- arch/powerpc/platforms/pseries/eeh_pe.c|3 +- arch/x86/kernel/kprobes/core.c | 14 +- crypto/algboss.c | 15 +- crypto/api.c |6 - crypto/internal.h |6 + drivers/acpi/dock.c| 179 ++- drivers/acpi/internal.h|5 + drivers/acpi/scan.c|1 + drivers/ata/libata-acpi.c | 37 +- drivers/ata/libata-core.c |2 + drivers/ata/libata.h |2 + drivers/block/rbd.c| 14 +- drivers/bluetooth/btmrvl_main.c|9 +- drivers/cpufreq/cpufreq_ondemand.c | 17 +- drivers/gpio/gpio-omap.c | 22 +- drivers/gpu/drm/i915/i915_dma.c| 18 +- drivers/gpu/drm/i915/i915_drv.c| 13 +- drivers/gpu/drm/i915/i915_drv.h|5 +- drivers/gpu/drm/i915/i915_gem.c| 36 +- drivers/gpu/drm/i915/i915_suspend.c|1 + drivers/gpu/drm/i915/intel_ddi.c
Re: PATCH - RADEON patch update for 3.10.1 urgency low
did some re-design of the patch for detecting power modes in PowerPlayTable, I hope this version looks a little bit smarter. Quality check with my muxless HD 6490M succesful, integrity/sanity checks for other asics like si/r600 which use the radeon_atombios_parse_power_table_4_5 are to be done. Best wishes and regards, Michael Schuster Hi, I've cc'ed the lists, and Alex the radeon maintainer. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: don't call -firstopen for KMS drivers
Hi Daniel,
Thank you for the patch.
On Saturday 13 July 2013 16:45:10 Daniel Vetter wrote:
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core - driver interface a
notch.
v2: Don't forget to update DocBook.
v3: Go with Laurent's slightly more elaborate proposal for the DocBook
update. Add a few words on top of his diff to elaborate a bit on what
KMS drivers should and shouldn't do in lastclose. There was already a
paragraph present talking about restoring properties, I've simply
extended that one.
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/drm.tmpl | 27 ---
drivers/gpu/drm/drm_fops.c | 3 ++-
2 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 4d54ac8..52d5eda 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2422,18 +2422,18 @@ void (*postclose) (struct drm_device *, struct
drm_file *);/synopsis /abstract
para
The methodnamefirstopen/methodname method is called by the DRM
core -when an application opens a device that has no other opened file
handle. - Similarly the methodnamelastclose/methodname method is
called
when -the last application holding a file handle opened on the device
closes - it. Both methods are mostly used for UMS (User Mode Setting)
drivers to - acquire and release device resources which should be done in
the - methodnameload/methodname and methodnameunload/methodname
- methods for KMS drivers.
+ for legacy UMS (User Mode Setting) drivers only when an application
+ opens a device that has no other opened file handle. UMS drivers can
+ implement it to acquire device resources. KMS drivers can't use the
+ method and must acquire resources in the methodnameload/methodname
+ method instead.
/para
para
-Note that the methodnamelastclose/methodname method is also
called - at module unload time or, for hot-pluggable devices, when the
device is - unplugged. The methodnamefirstopen/methodname and
+ Similarly the methodnamelastclose/methodname method is called when
+ the last application holding a file handle opened on the device closes
+ it, for both UMS and KMS drivers. Additionally, the method is also
+ called at module unload time or, for hot-pluggable devices, when the
+ device is unplugged. The methodnamefirstopen/methodname and
methodnamelastclose/methodname calls can thus be unbalanced.
/para
para
@@ -2462,7 +2462,12 @@ void (*postclose) (struct drm_device *, struct
drm_file *);/synopsis para
The methodnamelastclose/methodname method should restore CRTC
and plane properties to default value, so that a subsequent open of the
- device will not inherit state from the previous user.
+ device will not inherit state from the previous user. It can also be
+ used to execute delayed power switching state changes, e.g. in
+ conjunction with the vga-switcheroo infrastructure. Beyond that KMS
+ drivers should not do any further cleanup. Only legacy UMS drivers might
+ need to clean up device state so that the vga console or an independent
+ fbdev driver could take over.
/para
/sect2
sect2
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 57e3014..fcde7d4 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -51,7 +51,8 @@ static int drm_setup(struct drm_device * dev)
int i;
int ret;
- if (dev-driver-firstopen) {
+ if (dev-driver-firstopen
+ !drm_core_check_feature(dev, DRIVER_MODESET)) {
ret = dev-driver-firstopen(dev);
if (ret != 0)
return ret;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/ttm: convert to unified vma offset manager
Sorry, I forgot to CC correctly. On Mon, Jul 22, 2013 at 12:53 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Fri, Jul 19, 2013 at 11:13 AM, Thomas Hellstrom thellst...@vmware.com wrote: On 07/18/2013 10:54 PM, David Herrmann wrote: Hi On Thu, Jul 18, 2013 at 1:24 PM, Thomas Hellstrom thellst...@vmware.com wrote: ... I think that if there are good reasons to keep locking internal, I'm fine with that, (And also, of course, with Daniel's proposal). Currently the add / remove / lookup paths are mostly used by TTM during object creation and destruction. However, if the lookup path is ever used by pread / pwrite, that situation might change and we would then like to minimize the locking. I tried to keep the change as minimal as I could. Follow-up patches are welcome. I just thought pushing the lock into drm_vma_* would simplify things. If there are benchmarks that prove me wrong, I'll gladly spend some time optimizing that. In the general case, one reason for designing the locking outside of a utilities like this, is that different callers may have different requirements. For example, the call path is known not to be multithreaded at all, or the caller may prefer a mutex over a spinlock for various reasons. It might also be that some callers will want to use RCU locking in the future if the lookup path becomes busy, and that would require *all* users to adapt to RCU object destruction... I haven't looked at the code closely enough to say that any of this applies in this particular case, though. Some notes why I went with local locking: - mmap offset creation is done once and is independent of any other operations you might do on the BO in parallel - mmap lookup is also only done once in most cases. User-space rarely maps a buffer twice (setup/teardown of mmaps is expensive, but keeping them around is very cheap). And for shared buffers only the writer maps it as the reader normally passes it to the kernel without mapping/touching it. Only for software-rendering we have two or more mappings of the same object. - creating/mapping/destroying buffer objects is expensive in its current form and buffers tend to stay around for a long time I couldn't find a situation were the vma-manager was part of a performance critical path. But on the other hand, the paths were it is used are quite heavy. That's why I don't want to lock the whole buffer or even device. Instead, we need some management lock which is used for mmap-setup or similar things that don't affect other operations on the buffer or device. We don't have such a lock, so I introduced local locking. If we end up with more use-cases, I volunteer to refactor this. But I am no big fan of overgeneralizing it before more uses are known. Anyway, I will resend with vm_lock removed (+_unlocked() helpers) so we keep the status-quo regarding locks. Thanks for the comments on TTM buffer transfer. Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/4] drm/ttm: convert to unified vma offset manager
On 07/22/2013 12:55 PM, David Herrmann wrote: Sorry, I forgot to CC correctly. On Mon, Jul 22, 2013 at 12:53 PM, David Herrmann dh.herrm...@gmail.com wrote: Hi On Fri, Jul 19, 2013 at 11:13 AM, Thomas Hellstrom thellst...@vmware.com wrote: On 07/18/2013 10:54 PM, David Herrmann wrote: Hi On Thu, Jul 18, 2013 at 1:24 PM, Thomas Hellstrom thellst...@vmware.com wrote: ... I think that if there are good reasons to keep locking internal, I'm fine with that, (And also, of course, with Daniel's proposal). Currently the add / remove / lookup paths are mostly used by TTM during object creation and destruction. However, if the lookup path is ever used by pread / pwrite, that situation might change and we would then like to minimize the locking. I tried to keep the change as minimal as I could. Follow-up patches are welcome. I just thought pushing the lock into drm_vma_* would simplify things. If there are benchmarks that prove me wrong, I'll gladly spend some time optimizing that. In the general case, one reason for designing the locking outside of a utilities like this, is that different callers may have different requirements. For example, the call path is known not to be multithreaded at all, or the caller may prefer a mutex over a spinlock for various reasons. It might also be that some callers will want to use RCU locking in the future if the lookup path becomes busy, and that would require *all* users to adapt to RCU object destruction... I haven't looked at the code closely enough to say that any of this applies in this particular case, though. Some notes why I went with local locking: - mmap offset creation is done once and is independent of any other operations you might do on the BO in parallel - mmap lookup is also only done once in most cases. User-space rarely maps a buffer twice (setup/teardown of mmaps is expensive, but keeping them around is very cheap). And for shared buffers only the writer maps it as the reader normally passes it to the kernel without mapping/touching it. Only for software-rendering we have two or more mappings of the same object. - creating/mapping/destroying buffer objects is expensive in its current form and buffers tend to stay around for a long time I couldn't find a situation were the vma-manager was part of a performance critical path. But on the other hand, the paths were it is used are quite heavy. That's why I don't want to lock the whole buffer or even device. Instead, we need some management lock which is used for mmap-setup or similar things that don't affect other operations on the buffer or device. We don't have such a lock, so I introduced local locking. If we end up with more use-cases, I volunteer to refactor this. But I am no big fan of overgeneralizing it before more uses are known. I think we are discussing two different things here: 1) Having a separate lock for vma management vs 2) building that lock into the vma manager utility. You're arguing for 1) and I completely agree with you, and although I still think one generally should avoid building locks into utilities like this (avoid 2), I'm fine with the current approach. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: fix module build error
This patch removes all MODULE_DEVICE_TABLE declarations.
Exynos drm drivers don't need to create MODULE_DEVICE_TABLE
yet because all devices of Exynos drm include in one SoC so
they cannot be plugged in as of now.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 --
drivers/gpu/drm/exynos/exynos_drm_g2d.c |1 -
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 3e106be..5dba79e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -130,7 +130,6 @@ static const struct of_device_id fimd_driver_dt_match[] = {
.data = exynos5_fimd_driver_data },
{},
};
-MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
#endif
static inline struct fimd_driver_data *drm_fimd_get_driver_data(
@@ -1082,7 +1081,6 @@ static struct platform_device_id fimd_driver_ids[] = {
},
{},
};
-MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 42a5a54..4722662 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1521,7 +1521,6 @@ static const struct of_device_id exynos_g2d_match[] = {
{ .compatible = samsung,exynos5250-g2d },
{},
};
-MODULE_DEVICE_TABLE(of, exynos_g2d_match);
#endif
struct platform_driver g2d_driver = {
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67169] New: Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 Priority: medium Bug ID: 67169 Assignee: dri-devel@lists.freedesktop.org Summary: Black screen after waking from sleep Severity: normal Classification: Unclassified OS: All Reporter: ma...@scannadinari.co.uk Hardware: Other Status: NEW Version: 9.1 Component: Drivers/DRI/Radeon Product: Mesa Created attachment 82813 -- https://bugs.freedesktop.org/attachment.cgi?id=82813action=edit xorg log Waking the screen from sleep wakes it but all i get is a black screen. I am able to type and change ttys, etc, but after `systemctl restart gdm` as root the screen gets 'No signal'. The setting that causes this is GNOME's 'Blank screen' option in SettingsPowerBlank Screen I can confirm that AMD's proprietary drivers fix this. -- 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 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 Marco Scannadinari ma...@scannadinari.co.uk changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Severity|normal |major Priority|medium |high CC||ma...@scannadinari.co.uk --- Comment #1 from Marco Scannadinari ma...@scannadinari.co.uk --- Possibly related to Bug 61463? -- 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 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 Marco Scannadinari ma...@scannadinari.co.uk changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=61463 -- 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 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #2 from Alex Deucher ag...@yahoo.com --- What kernel are you using? Please attach your dmesg output. -- 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 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #3 from Marco Scannadinari ma...@scannadinari.co.uk --- Created attachment 82814 -- https://bugs.freedesktop.org/attachment.cgi?id=82814action=edit uname -a -- 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 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #4 from Marco Scannadinari ma...@scannadinari.co.uk --- Created attachment 82815 -- https://bugs.freedesktop.org/attachment.cgi?id=82815action=edit journalctl -b -- 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 67169] Black screen after waking from sleep
https://bugs.freedesktop.org/show_bug.cgi?id=67169 --- Comment #5 from Marco Scannadinari ma...@scannadinari.co.uk --- Created attachment 82816 -- https://bugs.freedesktop.org/attachment.cgi?id=82816action=edit dmesg -- 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/3] drm/exynos: add device tree support for rotator
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Chanho Park
Sent: Monday, July 22, 2013 3:49 PM
To: inki@samsung.com; kgene@samsung.com
Cc: jy0922.s...@samsung.com; sw0312@samsung.com;
kyungmin.p...@samsung.com; dri-devel@lists.freedesktop.org; linux-samsung-
s...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree-
disc...@lists.ozlabs.org; Chanho Park
Subject: [PATCH 1/3] drm/exynos: add device tree support for rotator
The exynos4 platform is only dt-based since 3.10, we should convert driver
data
and ids to dt-based parsing methods. The rotator driver has a limit table
to get
size limit. The minimum size of RGB888 format is 8 x 8 and maximum size is
8K x
8K. The other format, YCbCr420 2-Plane has 32 x 32 min size and 32K x 32K
max
size. Each format should be multiple of 'align' value.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 110 +++---
-
1 file changed, 80 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 427640a..b353a10 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -96,7 +96,7 @@ struct rot_context {
struct resource *regs_res;
void __iomem*regs;
struct clk *clock;
- struct rot_limit_table *limit_tbl;
+ struct rot_limit_table limit_tbl;
int irq;
int cur_buf_id[EXYNOS_DRM_OPS_MAX];
boolsuspended;
@@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void
*arg)
static void rotator_align_size(struct rot_context *rot, u32 fmt, u32
*hsize,
u32 *vsize)
{
- struct rot_limit_table *limit_tbl = rot-limit_tbl;
+ struct rot_limit_table *limit_tbl = rot-limit_tbl;
struct rot_limit *limit;
u32 mask, val;
@@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev,
enum drm_exynos_ipp_cmd cmd)
return 0;
}
+static const struct of_device_id exynos_rotator_match[] = {
+ {
+ .compatible = samsung,exynos4210-rotator,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_rotator_match);
Rotator device cannot be plugged in. Please remove the above
MODULE_DEVICE_TABLE.
+
+static int rotator_parse_dt_tbl(struct device_node *np, struct rot_limit
*rlim)
+{
+ int ret;
+
+ ret = of_property_read_u32(np, min_w, rlim-min_w);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, min_h, rlim-min_h);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, max_w, rlim-max_w);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, max_h, rlim-max_h);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, align, rlim-align);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int rotator_parse_dt(struct device *dev, struct rot_context *rot)
+{
+ struct device_node *ycbcr_node, *rgb888_node;
+ int ret;
+
+ ycbcr_node = of_get_child_by_name(dev-of_node, ycbcr420_2p);
+ if (!ycbcr_node) {
+ dev_err(dev, can't find ycbcr420_2p node\n);
+ return -ENODEV;
+ }
+
+ rgb888_node = of_get_child_by_name(dev-of_node, rgb888);
+ if (!rgb888_node) {
+ dev_err(dev, can't find rgb888 node\n);
+ return -ENODEV;
+ }
+
+ ret = rotator_parse_dt_tbl(ycbcr_node, rot-limit_tbl.ycbcr420_2p);
+ if (ret) {
+ dev_err(dev, failed to parse ycbcr420 data\n);
+ return ret;
+ }
+ ret = rotator_parse_dt_tbl(rgb888_node, rot-limit_tbl.rgb888);
+ if (ret) {
+ dev_err(dev, failed to parse rgb888 data\n);
+ return ret;
+ }
+
+ return 0;
+}
+
static int rotator_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device
*pdev)
struct exynos_drm_ippdrv *ippdrv;
int ret;
+ if (!dev-of_node) {
+ dev_err(dev, Cannot find device tree node\n);
+ return -ENODEV;
+ }
+
rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
if (!rot) {
dev_err(dev, failed to allocate rot\n);
return -ENOMEM;
}
- rot-limit_tbl = (struct rot_limit_table *)
- platform_get_device_id(pdev)-driver_data;
+ ret = rotator_parse_dt(dev, rot);
+ if (ret) {
+ dev_err(dev, failed parse dt info\n);
+ devm_kfree(dev, rot);
+ return ret;
+ }
rot-regs_res =
RE: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Monday, July 22, 2013 5:48 PM
To: Chanho Park
Cc: inki@samsung.com; kgene@samsung.com; linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; devicetree-
disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
This patch adds a dt-binding document for exynos rotator. It describes
which
nodes should be defined to use the rotator.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the samsung,exynos4210.
Please, add more compatible strings for other SoC.
+ - reg : Physical base address of the IP registers and length of
memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
clock-names?
+ - status : okay or disabled
+ - limit table for image formats : min_w/min_h/max_w/max_h for min/max
of image
Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.
+
+Example:
+ rotator: rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg = 0x1281 0x1000;
+ interrupts = 0 83 0;
+ clocks = clock 278;
+ clock-names = rotator;
+ status = disabled;
+ ycbcr420_2p {
Which names are allowed for these subnodes?
+ min_w = 32;
+ min_h = 32;
+ max_w = 32768;
+ max_h = 32768;
+ align = 3;
min-width, min-height, max-width, max-height? What units are they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are these
values always the same?
Right, that seems like configurable part. At least, min_w/h and max_w/h can
be different values according to SoC and pixel formats so they should be
described enough in this dt-binding document file.
Thanks,
Inki Dae
If thery're always the same, there's no need to
describe in in the devicetree.
Thanks,
Mark.
+ };
+ rgb888 {
+ min_w = 8;
+ min_h = 8;
+ max_w = 8192;
+ max_h = 8192;
+ align = 2;
+ };
+ };
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Monday, July 22, 2013 5:48 PM
To: Chanho Park
Cc: inki@samsung.com; kgene@samsung.com; linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; devicetree-
disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
This patch adds a dt-binding document for exynos rotator. It describes
which
nodes should be defined to use the rotator.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the samsung,exynos4210.
Please, add more compatible strings for other SoC.
+ - reg : Physical base address of the IP registers and length of
memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
clock-names?
+ - status : okay or disabled
+ - limit table for image formats : min_w/min_h/max_w/max_h for min/max
of image
Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.
+
+Example:
+ rotator: rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg = 0x1281 0x1000;
+ interrupts = 0 83 0;
+ clocks = clock 278;
+ clock-names = rotator;
+ status = disabled;
+ ycbcr420_2p {
Which names are allowed for these subnodes?
+ min_w = 32;
+ min_h = 32;
+ max_w = 32768;
+ max_h = 32768;
+ align = 3;
min-width, min-height, max-width, max-height? What units are they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are these
values always the same?
Right, that seems like configurable part. At least, min_w/h and max_w/h can
be different values according to SoC and pixel formats so they should be
described enough in this dt-binding document file.
Is there really this much configurability? Could each of those values be
a different on different SoCs, or could you just extract those values
from the SoC/rotator hardware version and thus the DT compatible string?
If thery're always the same, there's no need to
describe in in the devicetree.
Thanks,
Mark.
+ };
+ rgb888 {
+ min_w = 8;
+ min_h = 8;
+ max_w = 8192;
+ max_h = 8192;
+ align = 2;
+ };
+ };
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 2/3] drm/exynos: add dt-binding documentation for rotator
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Lucas Stach
Sent: Monday, July 22, 2013 9:47 PM
To: Inki Dae
Cc: 'Mark Rutland'; 'Chanho Park'; linux-samsung-...@vger.kernel.org;
devicetree-disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com;
kgene@samsung.com; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Monday, July 22, 2013 5:48 PM
To: Chanho Park
Cc: inki@samsung.com; kgene@samsung.com; linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; devicetree-
disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
This patch adds a dt-binding document for exynos rotator. It
describes
which
nodes should be defined to use the rotator.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the samsung,exynos4210.
Please, add more compatible strings for other SoC.
+ - reg : Physical base address of the IP registers and length of
memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
clock-names?
+ - status : okay or disabled
+ - limit table for image formats : min_w/min_h/max_w/max_h for
min/max
of image
Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.
+
+Example:
+ rotator: rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg = 0x1281 0x1000;
+ interrupts = 0 83 0;
+ clocks = clock 278;
+ clock-names = rotator;
+ status = disabled;
+ ycbcr420_2p {
Which names are allowed for these subnodes?
+ min_w = 32;
+ min_h = 32;
+ max_w = 32768;
+ max_h = 32768;
+ align = 3;
min-width, min-height, max-width, max-height? What units are they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are these
values always the same?
Right, that seems like configurable part. At least, min_w/h and max_w/h
can
be different values according to SoC and pixel formats so they should be
described enough in this dt-binding document file.
Is there really this much configurability? Could each of those values be
a different on different SoCs
Not much but Yes. Rotator devices of Exynos SoC support various pixel formats;
RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane, and each of these
pixel formats could be different limitation to minimum and maximum sizes.
For example, the below shows the limitation to Rotator device of Exynos4412 SoC
according to pixel formats,
Image format Minimum size Maximum size
RGB8888x8 8kx8k
RGB56516x16 16kx16k
YUV42216x16 16kx16k
YUV420 2-Plane 32x32 32kx32k(in case of Y
components)
YUV420 3-Plane 64x32 32kx32k(in case of Y
components)
And, I guess those limitations are slightly different according to Exynos SoC
versions as long as I know.
Thanks,
Inki Dae
, or could you just extract those values
from the SoC/rotator hardware version and thus the DT compatible string?
If thery're always the same, there's no need to
describe in in the devicetree.
Thanks,
[Bug 60929] [r600-llvm] mono games with opengl are blocking on start
https://bugs.freedesktop.org/show_bug.cgi?id=60929 --- Comment #13 from had...@gmx.de --- It is described in the building from source section here: http://www.opentk.com/doc/chapter/1/linux I did this in the opentk folder: xbuild OpenTK.sln /p:Configuration=Debug cd Binaries/OpenTK/Debug mono Examples.exe Some OpenGL examples show similar symptoms, they just stop at some point, others are quitting with a timelimit exceeded message. -- 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 66942] Cayman HD 6950 hangs at start when loading kernel 3.11.0-rc1 or drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=66942 --- Comment #12 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #11) Does it boot correctly if you build radeon as a module, then disable radeon (add radeon.modeset=0 to your kernel command line in grub) and boot to a non-X runlevel, then load radeon manually? modprobe -r radeon modprobe radeon modeset=1 No, sadly, it still hangs at the same place. Problem is, I can't tell if it hangs when loading the initramfs or when it tries to initialize the display beyond that... Any other suggestion? By the way, I built an 3.11.0-rc2 kernel this morning with as few drivers as possible for my system, just in case, but without any luck. -- 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 38917] [patch] Radeon clocks should not be limited to defaults
https://bugs.freedesktop.org/show_bug.cgi?id=38917 --- Comment #4 from Tomas Pospisek tpo_...@sourcepole.ch --- As of linux 3.11 there is additional power management infrastructure for radeons: http://www.botchco.com/agd5f/?p=57 Does that change anything wrt the here required functionality respectively this bug report? -- 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 38954] Add an option to switch from low to mid/high power states
https://bugs.freedesktop.org/show_bug.cgi?id=38954 --- Comment #1 from Tomas Pospisek tpo_...@sourcepole.ch --- See http://www.botchco.com/agd5f/?p=57 Is this what you need (and this bug can be closed?)? -- 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 2/3] drm/exynos: add dt-binding documentation for rotator
On 07/22/2013 03:31 PM, Inki Dae wrote:
---Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Lucas Stach
Sent: Monday, July 22, 2013 9:47 PM
To: Inki Dae
Cc: 'Mark Rutland'; 'Chanho Park'; linux-samsung-...@vger.kernel.org;
devicetree-disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com;
kgene@samsung.com; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Monday, July 22, 2013 5:48 PM
To: Chanho Park
Cc: inki@samsung.com; kgene@samsung.com; linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; devicetree-
disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
This patch adds a dt-binding document for exynos rotator. It
describes
which
nodes should be defined to use the rotator.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
diff --git a/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the samsung,exynos4210.
Please, add more compatible strings for other SoC.
+ - reg : Physical base address of the IP registers and length of
memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
clock-names?
+ - status : okay or disabled
+ - limit table for image formats : min_w/min_h/max_w/max_h for
min/max
of image
Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.
+
+Example:
+ rotator: rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg = 0x1281 0x1000;
+ interrupts = 0 83 0;
+ clocks = clock 278;
+ clock-names = rotator;
+ status = disabled;
+ ycbcr420_2p {
Which names are allowed for these subnodes?
+ min_w = 32;
+ min_h = 32;
+ max_w = 32768;
+ max_h = 32768;
+ align = 3;
min-width, min-height, max-width, max-height? What units are they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are these
values always the same?
Right, that seems like configurable part. At least, min_w/h and max_w/h
can
be different values according to SoC and pixel formats so they should be
described enough in this dt-binding document file.
Is there really this much configurability? Could each of those values be
a different on different SoCs
Not much but Yes. Rotator devices of Exynos SoC support various pixel
formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane, and each
of these pixel formats could be different limitation to minimum and maximum
sizes.
For example, the below shows the limitation to Rotator device of Exynos4412
SoC according to pixel formats,
Image format Minimum size Maximum size
RGB8888x8 8kx8k
RGB56516x16 16kx16k
YUV42216x16 16kx16k
YUV420 2-Plane 32x32 32kx32k(in case of Y
components)
YUV420 3-Plane 64x32 32kx32k(in case of Y
components)
And, I guess those limitations are slightly different according to Exynos SoC
versions as long as I know.
Thanks,
Inki Dae
, or could you just extract those values
from the SoC/rotator hardware version and thus the DT compatible string?
My gut feeling is that
[Bug 39063] RV630: Sapphire HD 2600 XT power management doesnt work.
https://bugs.freedesktop.org/show_bug.cgi?id=39063 --- Comment #8 from Tomas Pospisek tpo_...@sourcepole.ch --- radeon has got some new power management infrastructure: http://www.botchco.com/agd5f/?p=57 Does that change anything wrt this bug? Btw. here: # uname -a Linux hier 3.11.0-rc1 #2 SMP Sun Jul 21 12:29:18 CEST 2013 x86_64 GNU/Linux (booted with radeon.dpm=1) # lspci | grep Radeon 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] (rev ff) # cat rom cat: rom: Invalid argument # echo 1 rom # cat rom cat: rom: input/output error # translated from german -- 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 41420] [UPSTREAM REPOST] radeon driver power management is very bad: GPU always runs at maximum clock speed
https://bugs.freedesktop.org/show_bug.cgi?id=41420 --- Comment #1 from Tomas Pospisek tpo_...@sourcepole.ch --- Does this change anything?: http://www.botchco.com/agd5f/?p=57 Available in kernel 3.11 -- 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 59322] r300g MSAA breaks Half-Life 2 in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=59322 --- Comment #9 from Stefan Dösinger stefandoesin...@gmx.at --- (In reply to comment #8) Is it a big deal that ARB_framebuffer_sRGB is unsupported? In such a case, the renderbuffer format GL_SRGB8_ALPHA8 is equivalent to GL_RGBA8. Not really. In this case we generate code in the pixel shader that performs sRGB color conversion as specified in the framebuffer_sRGB spec. Do r300-r500 GPUs have some dedicated silicon to handle sRGB conversion? If so, it'd be nice to use it. -- 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 67178] New: discrete radeon HD 6400M/7400M intense heating even though it's off
https://bugs.freedesktop.org/show_bug.cgi?id=67178 Priority: medium Bug ID: 67178 Assignee: dri-devel@lists.freedesktop.org Summary: discrete radeon HD 6400M/7400M intense heating even though it's off Severity: normal Classification: Unclassified OS: Linux (All) Reporter: tpo_...@sourcepole.ch Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI kernel 3.11-rc1 (also tested with 3.10 from Debian, 3.7, 3,2) # lspci -vnnn | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller]) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] [1002:6760] (rev ff) (prog-if ff) This is a HP Pavillon dv7 6130ez Sometimes, at random, the radeon card goes into full heat production mode. This seems to occur a while (a few minutes?) after wakeup from resume, however I'm not sure about that. Suspending and resuming the laptop a few times (1 = x = ~4) seems to calm the card down again. Power consumption according to powertop goes from ~14W up to ~50W. This happens even though the card should be in theory switched off. Aka: # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Off::01:00.0 # echo IGD /sys/kernel/debug/vgaswitcheroo/switch # echo OFF /sys/kernel/debug/vgaswitcheroo/switch doesn't seem to have no effect whatsoever. It *seems* that setting radeon.dpm=1 kernel boot options and then: # echo battery /sys/class/drm/card$no/device/power_dpm_state puts the card in an active but relatively low power consumption mode. It is then using about 20W (instead of the normal ~14W) so it's continuously faning out slightly warm air. And it seems that when the card is running in this mode, then it won't get so often, or ever (I'm not very sure) into the berserk heating mode. The lowest observed power consumption of the laptop is ~7W. It'd be very nice if it'd be possible to shut the card down electrically via software and stay in this 7W mode. -- 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 67178] discrete radeon HD 6400M/7400M intense heating even though it's off
https://bugs.freedesktop.org/show_bug.cgi?id=67178 --- Comment #1 from Tomas Pospisek tpo_...@sourcepole.ch --- Created attachment 82828 -- https://bugs.freedesktop.org/attachment.cgi?id=82828action=edit dmesg dmesg with wlan stuff edited out -- 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 39267] Dynamic power management does not work on HD5870
https://bugs.freedesktop.org/show_bug.cgi?id=39267 --- Comment #1 from Tomas Pospisek tpo_...@sourcepole.ch --- Does anything change if you use kernel = 3.11? See http://www.botchco.com/agd5f/?p=57 -- 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 59322] r300g MSAA breaks Half-Life 2 in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=59322 --- Comment #10 from Stefan Dösinger stefandoesin...@gmx.at --- Fwiw, there's probably a bug in Wine as well. We shouldn't try to render to sRGB formats if framebuffer_sRGB is not supported, but giving textures an sRGB format is the only way to make use of sRGB_decode. -- 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 38954] Add an option to switch from low to mid/high power states
https://bugs.freedesktop.org/show_bug.cgi?id=38954 --- Comment #2 from muzi...@email.it --- This new feature is a good work, seems to be a solution who goes in the right direction, but I think to close this bug after a test. Thanks for your work -- 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 2/3] drm/exynos: add dt-binding documentation for rotator
On Monday 22 of July 2013 16:00:22 Sylwester Nawrocki wrote:
On 07/22/2013 03:31 PM, Inki Dae wrote:
---Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org
[mailto:linux-samsung-soc- ow...@vger.kernel.org] On Behalf Of
Lucas Stach
Sent: Monday, July 22, 2013 9:47 PM
To: Inki Dae
Cc: 'Mark Rutland'; 'Chanho Park';
linux-samsung-...@vger.kernel.org;
devicetree-disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com;
kgene@samsung.com; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation
for
rotator
Am Montag, den 22.07.2013, 21:37 +0900 schrieb Inki Dae:
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Monday, July 22, 2013 5:48 PM
To: Chanho Park
Cc: inki@samsung.com; kgene@samsung.com;
linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; devicetree-
disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com;
linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding
documentation for
rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
This patch adds a dt-binding document for exynos rotator.
It
describes
which
nodes should be defined to use the rotator.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.
txt
diff --git
a/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++
b/Documentation/devicetree/bindings/drm/exynos/samsung-
rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the
samsung,exynos4210.
Please, add more compatible strings for other SoC.
+ - reg : Physical base address of the IP registers and
length of
memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
clock-names?
+ - status : okay or disabled
+ - limit table for image formats :
min_w/min_h/max_w/max_h for
min/max
of image
Limit table? This doesn't seem to be a well-defined binding,
and it
seems like a relatively generic thing to describe.
+
+Example:
+ rotator: rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg = 0x1281 0x1000;
+ interrupts = 0 83 0;
+ clocks = clock 278;
+ clock-names = rotator;
+ status = disabled;
+ ycbcr420_2p {
Which names are allowed for these subnodes?
+ min_w = 32;
+ min_h = 32;
+ max_w = 32768;
+ max_h = 32768;
+ align = 3;
min-width, min-height, max-width, max-height? What units are
they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are
these
values always the same?
Right, that seems like configurable part. At least, min_w/h and
max_w/h
can
be different values according to SoC and pixel formats so they
should be described enough in this dt-binding document file.
Is there really this much configurability? Could each of those
values be a different on different SoCs
Not much but Yes. Rotator devices of Exynos SoC support various pixel
formats; RGB888, RGB565, YUV422, YUV420-2Plane, and YUV420-3Plane,
and each of these pixel formats could be different limitation to
minimum and maximum sizes. For example, the below shows the
limitation to Rotator device of Exynos4412 SoC according to pixel
formats,
Image format Minimum size Maximum size
RGB8888x8 8kx8k
RGB56516x16 16kx16k
YUV42216x16
Re: [PATCH 1/3] drm/exynos: add device tree support for rotator
On Monday 22 of July 2013 15:49:25 Chanho Park wrote:
The exynos4 platform is only dt-based since 3.10, we should convert
driver data and ids to dt-based parsing methods. The rotator driver has
a limit table to get size limit. The minimum size of RGB888 format is 8
x 8 and maximum size is 8K x 8K. The other format, YCbCr420 2-Plane has
32 x 32 min size and 32K x 32K max size. Each format should be multiple
of 'align' value.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 110
+++ 1 file changed, 80 insertions(+), 30
deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c index 427640a..b353a10
100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -96,7 +96,7 @@ struct rot_context {
struct resource *regs_res;
void __iomem*regs;
struct clk *clock;
- struct rot_limit_table *limit_tbl;
+ struct rot_limit_table limit_tbl;
int irq;
int cur_buf_id[EXYNOS_DRM_OPS_MAX];
boolsuspended;
@@ -167,7 +167,7 @@ static irqreturn_t rotator_irq_handler(int irq, void
*arg) static void rotator_align_size(struct rot_context *rot, u32 fmt,
u32 *hsize, u32 *vsize)
{
- struct rot_limit_table *limit_tbl = rot-limit_tbl;
+ struct rot_limit_table *limit_tbl = rot-limit_tbl;
struct rot_limit *limit;
u32 mask, val;
@@ -632,6 +632,72 @@ static int rotator_ippdrv_start(struct device *dev,
enum drm_exynos_ipp_cmd cmd) return 0;
}
+static const struct of_device_id exynos_rotator_match[] = {
+ {
+ .compatible = samsung,exynos4210-rotator,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, exynos_rotator_match);
+
+static int rotator_parse_dt_tbl(struct device_node *np, struct
rot_limit *rlim) +{
+ int ret;
+
+ ret = of_property_read_u32(np, min_w, rlim-min_w);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, min_h, rlim-min_h);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, max_w, rlim-max_w);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, max_h, rlim-max_h);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(np, align, rlim-align);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int rotator_parse_dt(struct device *dev, struct rot_context
*rot) +{
+ struct device_node *ycbcr_node, *rgb888_node;
+ int ret;
+
+ ycbcr_node = of_get_child_by_name(dev-of_node, ycbcr420_2p);
+ if (!ycbcr_node) {
+ dev_err(dev, can't find ycbcr420_2p node\n);
+ return -ENODEV;
+ }
+
+ rgb888_node = of_get_child_by_name(dev-of_node, rgb888);
+ if (!rgb888_node) {
+ dev_err(dev, can't find rgb888 node\n);
+ return -ENODEV;
+ }
+
+ ret = rotator_parse_dt_tbl(ycbcr_node, rot-
limit_tbl.ycbcr420_2p);
+ if (ret) {
+ dev_err(dev, failed to parse ycbcr420 data\n);
+ return ret;
+ }
+ ret = rotator_parse_dt_tbl(rgb888_node, rot-limit_tbl.rgb888);
+ if (ret) {
+ dev_err(dev, failed to parse rgb888 data\n);
+ return ret;
+ }
+
+ return 0;
+}
+
static int rotator_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -639,14 +705,23 @@ static int rotator_probe(struct platform_device
*pdev) struct exynos_drm_ippdrv *ippdrv;
int ret;
+ if (!dev-of_node) {
+ dev_err(dev, Cannot find device tree node\n);
+ return -ENODEV;
+ }
+
rot = devm_kzalloc(dev, sizeof(*rot), GFP_KERNEL);
if (!rot) {
dev_err(dev, failed to allocate rot\n);
return -ENOMEM;
}
- rot-limit_tbl = (struct rot_limit_table *)
- platform_get_device_id(pdev)-driver_data;
+ ret = rotator_parse_dt(dev, rot);
+ if (ret) {
+ dev_err(dev, failed parse dt info\n);
+ devm_kfree(dev, rot);
+ return ret;
+ }
rot-regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
rot-regs = devm_ioremap_resource(dev, rot-regs_res);
@@ -718,31 +793,6 @@ static int rotator_remove(struct platform_device
*pdev) return 0;
}
-static struct rot_limit_table rot_limit_tbl = {
- .ycbcr420_2p = {
- .min_w = 32,
- .min_h = 32,
- .max_w = SZ_32K,
- .max_h = SZ_32K,
- .align = 3,
- },
- .rgb888 = {
- .min_w = 8,
- .min_h = 8,
- .max_w = SZ_8K,
- .max_h = SZ_8K,
- .align = 2,
- },
-};
-
-static struct
[Bug 60606] New: vga_switcheroo / new Radeon DPM code mess up fbcon
https://bugzilla.kernel.org/show_bug.cgi?id=60606 Bug ID: 60606 Summary: vga_switcheroo / new Radeon DPM code mess up fbcon Product: Drivers Version: 2.5 Kernel Version: 3.11.0-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: sebastien.fie...@free.fr Regression: No Created attachment 106987 -- https://bugzilla.kernel.org/attachment.cgi?id=106987action=edit radeon switch OFF / switch ON experiment I am the happy owner of an hybrid Intel core i5 480M / AMD Radeon 6550M latop. - IGP is Intel ironlake - DGD is AMD radeon 6550M I just installed kernel 3.11.0-rc2. switching the discrete GPU OFF via the vgaswticheroo works from within X or from the console : echo OFF /sys/kernel/debug/vgaswitcheroo/switch cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Pwr::02:00.0 2:DIS-Audio: :Pwr::02:00.1 I then tried to switch the radeon back ON from the console with X down : echo ON /sys/kernel/debug/vgaswitcheroo/switch It messed up the console display : screen turned to dominant grey scattered with coloured pixels making it unreadable, forcing me to reboot. The attachment is the excerpt of my kern.log file for my radeon switch OFF / switch ON experiment. switch off is at [ 76.634983] switch on is at [ 2167.936488] or [ 2167.936517] I also noticed : [5.457569] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) [5.457739] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20130517/nsarguments-95) which seems to be related to vgaswitcheroo setup, but I don't know if it's relevant or not. Let me know if you need anything else. thanks for your help, Seb. -- 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
[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon
https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #1 from Sebastien Fievet sebastien.fie...@free.fr --- I did proofread my report, but missed a obvious mistake : cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Pwr::02:00.0 2:DIS-Audio: :Pwr::02:00.1 echo OFF /sys/kernel/debug/vgaswitcheroo/switch cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD:+:Pwr::00:02.0 1:DIS: :Off::02:00.0 2:DIS-Audio: :Off::02:00.1 all apologies. -- 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
[Bug 67178] discrete radeon HD 6400M/7400M intense heating even though it's off
https://bugs.freedesktop.org/show_bug.cgi?id=67178 --- Comment #2 from Tomas Pospisek tpo_...@sourcepole.ch --- So if I boot with radeon.dpm=1 then, as allready described, the laptop uses relatively little power, and is faning off some heat continuously, even when I set: # echo battery /sys/class/drm/card1/device/power_dpm_state Whether I do the following does *not* seem to matter: # echo IGD /sys/kernel/debug/vgaswitcheroo/switch # echo OFF /sys/kernel/debug/vgaswitcheroo/switch But if I boot *without* radeon.dpm=1 then the laptop will stay cool without fans running out of the box using around 14W. The various settings will show this then: # cat /sys/class/drm/card1/device/power_method dpm # cat /sys/class/drm/card1/device/power_profile default # cat /sys/class/drm/card1/device/power_dpm_state balanced Weird that power_method would show dpm even though I have booted *without* radeon.dpm=1 ?! When I then set: # echo battery /sys/class/drm/card1/device/power_dpm_state Power consumption will drop even further to ~11W. The overal logic of all of this is evidently completely escaping me... 8-o -- 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 66767] atombios stuck in loop for more than 5secs aborting after suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=66767 --- Comment #3 from Martin Bednar seraf...@gmail.com --- Created attachment 82844 -- https://bugs.freedesktop.org/attachment.cgi?id=82844action=edit dmesg after resume dmesg output after a resume from suspend to ram. UVD initialization fails. Output from 3.11-rc2. on a 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Madison [Radeon HD 5000M Series]. Only happens if DPM is enabled. short dmesg version (mainly radeon output after resume) : [ 134.652348] [drm] PCIE GART of 512M enabled (table at 0x0025D000). [ 134.652517] radeon :01:00.0: WB enabled [ 134.652520] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88011160fc00 [ 134.652521] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x88011160fc0c [ 134.653452] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc9000639c418 [ 134.670153] [drm] ring test on 0 succeeded in 1 usecs [ 134.670213] [drm] ring test on 3 succeeded in 1 usecs [ 134.723748] dpm_run_callback(): pnp_bus_resume+0x0/0x80 returns -19 [ 134.723750] PM: Device 00:07 failed to resume: error -19 [ 134.962587] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 134.965908] ata6: SATA link down (SStatus 0 SControl 300) [ 134.966739] ata2.00: configured for UDMA/100 [ 135.142469] sdhci-pci :03:00.0: Will use DMA mode even though HW doesn't fully claim to support it. [ 135.142506] sdhci-pci :03:00.4: Will use DMA mode even though HW doesn't fully claim to support it. [ 135.862145] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 136.771646] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 136.781372] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 136.791321] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 136.791499] ata1.00: configured for UDMA/133 [ 136.804977] sd 0:0:0:0: [sda] Starting disk [ 136.887420] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 137.912701] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 138.937981] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 139.963255] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 140.988548] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 142.013843] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 143.039117] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 144.064413] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 145.089696] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 145.109806] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 145.109873] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). [ 145.109874] [drm] Enabling audio support [ 145.109933] [drm] ib test on ring 0 succeeded in 0 usecs [ 145.109978] [drm] ib test on ring 3 succeeded in 1 usecs [ 145.121521] switching from power state: [ 145.121522] ui class: none [ 145.121524] internal class: boot [ 145.121525] caps: video [ 145.121527] uvdvclk: 0 dclk: 0 [ 145.121529] power level 0sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121530] power level 1sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121531] power level 2sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121533] status: c b [ 145.121533] switching to power state: [ 145.121534] ui class: performance [ 145.121535] internal class: none [ 145.121536] caps: single_disp video [ 145.121537] uvdvclk: 0 dclk: 0 [ 145.121538] power level 0sclk: 15000 mclk: 15000 vddc: 900 vddci: 0 [ 145.121539] power level 1sclk: 3 mclk: 79000 vddc: 950 vddci: 0 [ 145.121540] power level 2sclk: 45000 mclk: 79000 vddc: 950 vddci: 0 [ 145.121541] status: r [ 150.307980] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [ 150.307982] [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CBE6 (len 67, WS 0, PS 0) @ 0xCC15 [ 151.345217] PM: resume of devices complete after 16856.243 msecs -- 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 66767] atombios stuck in loop for more than 5secs aborting after suspend to ram
https://bugs.freedesktop.org/show_bug.cgi?id=66767 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Alex Deucher ag...@yahoo.com --- *** This bug has been marked as a duplicate of bug 67043 *** -- 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 67043] Atombios stuck in a loop during resume
https://bugs.freedesktop.org/show_bug.cgi?id=67043 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||johannes.hi...@fem.tu-ilmen ||au.de --- Comment #11 from Alex Deucher ag...@yahoo.com --- *** Bug 66767 has been marked as a duplicate of this bug. *** -- 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 13/20] drm/gem: create drm_gem_dumb_destroy
On Tue, Jul 16, 2013 at 3:12 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Cc: Inki Dae inki@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Intel Graphics Development intel-...@lists.freedesktop.org
Cc: Ben Skeggs skeg...@gmail.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
drivers/gpu/drm/ast/ast_drv.h | 3 ---
drivers/gpu/drm/ast/ast_main.c| 7 ---
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_drv.h | 3 ---
drivers/gpu/drm/cirrus/cirrus_main.c | 7 ---
drivers/gpu/drm/drm_gem.c | 14 ++
drivers/gpu/drm/drm_gem_cma_helper.c | 10 --
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 20
drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 -
drivers/gpu/drm/gma500/gem.c | 17 -
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 2 --
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_gem.c | 7 ---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
drivers/gpu/drm/mgag200/mgag200_main.c| 7 ---
drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
drivers/gpu/drm/omapdrm/omap_drv.h| 2 --
drivers/gpu/drm/omapdrm/omap_gem.c| 15 ---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_dumb.c| 7 ---
drivers/gpu/drm/radeon/radeon.h | 3 ---
drivers/gpu/drm/radeon/radeon_drv.c | 5 +
drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 2 --
drivers/gpu/drm/udl/udl_gem.c | 6 --
drivers/gpu/host1x/drm/drm.c | 2 +-
drivers/gpu/host1x/drm/gem.c | 6 --
drivers/gpu/host1x/drm/gem.h | 2 --
drivers/staging/imx-drm/imx-drm-core.c| 2 +-
include/drm/drmP.h| 3 +++
include/drm/drm_gem_cma_helper.h | 8
44 files changed, 33 insertions(+), 186 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index df0d0a0..a144fb0 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -216,7 +216,7 @@ static struct drm_driver driver = {
.gem_free_object = ast_gem_free_object,
.dumb_create = ast_dumb_create,
.dumb_map_offset = ast_dumb_mmap_offset,
- .dumb_destroy = ast_dumb_destroy,
+ .dumb_destroy = drm_gem_dumb_destroy,
};
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 622d4ae..796dbb2 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -322,9 +322,6 @@ ast_bo(struct ttm_buffer_object *bo)
extern int ast_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-extern int ast_dumb_destroy(struct drm_file *file,
- struct drm_device *dev,
- uint32_t handle);
extern int ast_gem_init_object(struct drm_gem_object *obj);
extern void ast_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f60fd7b..0ef4228 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -449,13 +449,6 @@ int ast_dumb_create(struct drm_file *file,
return 0;
}
-int ast_dumb_destroy(struct drm_file *file,
-struct drm_device *dev,
-uint32_t handle)
-{
- return drm_gem_handle_delete(file, handle);
-}
-
int ast_gem_init_object(struct drm_gem_object *obj)
{
BUG();
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
Re: [PATCH 04/20] drm/prime: add a bit of documentation about gem_obj-import_attach
On Tue, Jul 16, 2013 at 3:11 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Lifetime rules seem to be solid around -import_attach. So this patch
just properly documents them.
Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Similarly
for drm devices which don't need a dma attachment at all (like udl).
yeah, with msm drm driver, that might become (eventually) an issue.
(But not yet, because they seem to use iommu-dev attachment in a..
slightly different way)
But fixing that up is material for different patches.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rob Clark robdcl...@gmail.com
---
include/drm/drmP.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cd57646..baf030c 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -681,7 +681,16 @@ struct drm_gem_object {
/* dma buf exported from this GEM object */
struct dma_buf *export_dma_buf;
- /* dma buf attachment backing this object */
+ /**
+* import_attach - dma buf attachment backing this object
+*
+* Any foreign dma_buf imported as a gem object has this set to the
+* attachment point for the device. This is invariant over the
lifetime
+* of a gem object.
+*
+* The driver's -gem_free_object callback is responsible for cleaning
+* up the dma_buf attachment and references acquired at import time.
+*/
struct dma_buf_attachment *import_attach;
};
--
1.8.3.2
___
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
[Bug 59477] libdrm 2.4.41 build failure
https://bugs.freedesktop.org/show_bug.cgi?id=59477 Matt Turner matts...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Matt Turner matts...@gmail.com --- Use a newer version :) -- 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 05/20] drm/gem: remove drm_gem_object_handle_unreference
On Tue, Jul 16, 2013 at 3:11 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
It's unused, everyone is using the _unlocked variant only.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rob Clark robdcl...@gmail.com
---
include/drm/drmP.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index baf030c..f949cb2 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1671,24 +1671,6 @@ drm_gem_object_handle_reference(struct drm_gem_object
*obj)
}
static inline void
-drm_gem_object_handle_unreference(struct drm_gem_object *obj)
-{
- if (obj == NULL)
- return;
-
- if (atomic_read(obj-handle_count) == 0)
- return;
- /*
-* Must bump handle count first as this may be the last
-* ref, in which case the object would disappear before we
-* checked for a name
-*/
- if (atomic_dec_and_test(obj-handle_count))
- drm_gem_object_handle_free(obj);
- drm_gem_object_unreference(obj);
-}
-
-static inline void
drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
{
if (obj == NULL)
--
1.8.3.2
___
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
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #29 from rafael castillo jrch2...@gmail.com --- posted updated crash dmesg with kernel 3.11-rc2 in case it helps -- 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
RE: [PATCH 2/3] drm/exynos: add dt-binding documentation for rotator
-Original Message-
From: Chanho Park [mailto:chanho61.p...@samsusng.com]
Sent: Tuesday, July 23, 2013 10:22 AM
To: 'Mark Rutland'; 'Chanho Park'
Cc: inki@samsung.com; kgene@samsung.com; linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com; linux-arm-
ker...@lists.infradead.org
Subject: RE: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
Hi Mark,
Thank you for your review.
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: Monday, July 22, 2013 5:48 PM
To: Chanho Park
Cc: inki@samsung.com; kgene@samsung.com; linux-samsung-
s...@vger.kernel.org; jy0922.s...@samsung.com; devicetree-
disc...@lists.ozlabs.org; sw0312@samsung.com; dri-
de...@lists.freedesktop.org; kyungmin.p...@samsung.com; linux-arm-
ker...@lists.infradead.org
Subject: Re: [PATCH 2/3] drm/exynos: add dt-binding documentation for
rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
This patch adds a dt-binding document for exynos rotator. It describes
which nodes should be defined to use the rotator.
Signed-off-by: Chanho Park chanho61.p...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../bindings/drm/exynos/samsung-rotator.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
diff --git
a/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
new file mode 100644
index 000..6b1d704
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-rotator.txt
@@ -0,0 +1,35 @@
+* Samsung Image Rotator
+
+Required properties:
+ - compatible : value should be the samsung,exynos4210.
+ - reg : Physical base address of the IP registers and length of
memory
+ mapped region.
+ - interrupts : interrupt number to the CPU.
+ - clocks : clock number of exynos4 rotator clock.
+ - clocks : clock name of rotator
clock-names?
Yes. It seems to have a mistake during copy and paste.
I'll modify it next patch.
+ - status : okay or disabled
+ - limit table for image formats : min_w/min_h/max_w/max_h for
+ min/max of image
Limit table? This doesn't seem to be a well-defined binding, and it
seems like a relatively generic thing to describe.
+
+Example:
+ rotator: rotator@1281 {
+ compatible = samsung,exynos4210-rotator;
+ reg = 0x1281 0x1000;
+ interrupts = 0 83 0;
+ clocks = clock 278;
+ clock-names = rotator;
+ status = disabled;
+ ycbcr420_2p {
Which names are allowed for these subnodes?
+ min_w = 32;
+ min_h = 32;
+ max_w = 32768;
+ max_h = 32768;
+ align = 3;
min-width, min-height, max-width, max-height? What units are they in?
What does alignment specify exactly?
Are these a configurable part of the rotator hardware, or are these
values always the same? If thery're always the same, there's no need to
describe in in the devicetree.
I've checked the rotator limitation for all of exynos4 chipsets and
exynos5250.
As a result, these have same value.
Not true. See the Exynos4210 user manual again. At least, the manual says
maximum size is 64k x 64k in case of Y components.
I think it seems to be better leave on static value.
I'll prepare next patches including your suggestion.
So, you should consider such a little bit difference.
Thanks
Best Regards,
Chanho Park
Thanks,
Mark.
+ };
+ rgb888 {
+ min_w = 8;
+ min_h = 8;
+ max_w = 8192;
+ max_h = 8192;
+ align = 2;
+ };
+ };
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
