[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Kukjin Kim]

On 06/19/13 22:50, Kukjin Kim wrote:
> On 06/19/13 21:51, Rahul Sharma wrote:
>> This patch renames the combatible strings for hdmi, mixer, ddc
>> and hdmiphy. It follows the convention of using compatible string
>> which represent the SoC in which the IP was added for the first
>> time.
>>
>> Signed-off-by: Rahul Sharma
>
> Acked-by: Kukjin Kim 
>

Just one nit in subject:

[PATCH] ARM: dts: . for exynos5250

Thanks,
- Kukjin

>> ---
>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>> b/arch/arm/boot/dts/cros5250-common.dtsi
>> index 3f0239e..dc259e8b 100644
>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>> @@ -190,7 +190,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiddc at 50 {
>> - compatible = "samsung,exynos5-hdmiddc";
>> + compatible = "samsung,exynos4210-hdmiddc";
>> reg =<0x50>;
>> };
>> };
>> @@ -224,7 +224,7 @@
>> samsung,i2c-max-bus-freq =<378000>;
>>
>> hdmiphy at 38 {
>> - compatible = "samsung,exynos5-hdmiphy";
>> + compatible = "samsung,exynos4212-hdmiphy";
>> reg =<0x38>;
>> };
>> };
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index 3e0c792..f320d7c 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -72,7 +72,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiddc at 50 {
>> - compatible = "samsung,exynos5-hdmiddc";
>> + compatible = "samsung,exynos4210-hdmiddc";
>> reg =<0x50>;
>> };
>> };
>> @@ -102,7 +102,7 @@
>> samsung,i2c-max-bus-freq =<66000>;
>>
>> hdmiphy at 38 {
>> - compatible = "samsung,exynos5-hdmiphy";
>> + compatible = "samsung,exynos4212-hdmiphy";
>> reg =<0x38>;
>> };
>> };
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 0673524..2f7763b 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -601,7 +601,7 @@
>> };
>>
>> hdmi {
>> - compatible = "samsung,exynos5-hdmi";
>> + compatible = "samsung,exynos4212-hdmi";
>> reg =<0x1453 0x7>;
>> interrupts =<0 95 0>;
>> clocks =< 333>,< 136>,< 137>,
>> @@ -611,7 +611,7 @@
>> };
>>
>> mixer {
>> - compatible = "samsung,exynos5-mixer";
>> + compatible = "samsung,exynos5250-mixer";
>> reg =<0x1445 0x1>;
>> interrupts =<0 94 0>;
>> };

[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Kukjin Kim]

On 06/19/13 21:51, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma

Acked-by: Kukjin Kim 

- Kukjin

> ---
>   arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
>   arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
>   arch/arm/boot/dts/exynos5250.dtsi |4 ++--
>   3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
> b/arch/arm/boot/dts/cros5250-common.dtsi
> index 3f0239e..dc259e8b 100644
> --- a/arch/arm/boot/dts/cros5250-common.dtsi
> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
> @@ -190,7 +190,7 @@
>   samsung,i2c-max-bus-freq =<66000>;
>
>   hdmiddc at 50 {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
>   reg =<0x50>;
>   };
>   };
> @@ -224,7 +224,7 @@
>   samsung,i2c-max-bus-freq =<378000>;
>
>   hdmiphy at 38 {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4212-hdmiphy";
>   reg =<0x38>;
>   };
>   };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 3e0c792..f320d7c 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -72,7 +72,7 @@
>   samsung,i2c-max-bus-freq =<66000>;
>
>   hdmiddc at 50 {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
>   reg =<0x50>;
>   };
>   };
> @@ -102,7 +102,7 @@
>   samsung,i2c-max-bus-freq =<66000>;
>
>   hdmiphy at 38 {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4212-hdmiphy";
>   reg =<0x38>;
>   };
>   };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 0673524..2f7763b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -601,7 +601,7 @@
>   };
>
>   hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
>   reg =<0x1453 0x7>;
>   interrupts =<0 95 0>;
>   clocks =< 333>,< 136>,< 137>,
> @@ -611,7 +611,7 @@
>   };
>
>   mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
>   reg =<0x1445 0x1>;
>   interrupts =<0 94 0>;
>   };

[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

Thanks Mr. Kim,

I will post v4 with aforesaid change.

regards,
Rahul Sharma.

On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim  wrote:
> On 06/19/13 22:50, Kukjin Kim wrote:
>>
>> On 06/19/13 21:51, Rahul Sharma wrote:
>>>
>>> This patch renames the combatible strings for hdmi, mixer, ddc
>>> and hdmiphy. It follows the convention of using compatible string
>>> which represent the SoC in which the IP was added for the first
>>> time.
>>>
>>> Signed-off-by: Rahul Sharma
>>
>>
>> Acked-by: Kukjin Kim 
>>
>
> Just one nit in subject:
>
> [PATCH] ARM: dts: . for exynos5250
>
> Thanks,
>
> - Kukjin
>
>>> ---
>>> arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
>>> arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
>>> arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
>>> 3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
>>> b/arch/arm/boot/dts/cros5250-common.dtsi
>>> index 3f0239e..dc259e8b 100644
>>> --- a/arch/arm/boot/dts/cros5250-common.dtsi
>>> +++ b/arch/arm/boot/dts/cros5250-common.dtsi
>>> @@ -190,7 +190,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc at 50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -224,7 +224,7 @@
>>> samsung,i2c-max-bus-freq =<378000>;
>>>
>>> hdmiphy at 38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> index 3e0c792..f320d7c 100644
>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> @@ -72,7 +72,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiddc at 50 {
>>> - compatible = "samsung,exynos5-hdmiddc";
>>> + compatible = "samsung,exynos4210-hdmiddc";
>>> reg =<0x50>;
>>> };
>>> };
>>> @@ -102,7 +102,7 @@
>>> samsung,i2c-max-bus-freq =<66000>;
>>>
>>> hdmiphy at 38 {
>>> - compatible = "samsung,exynos5-hdmiphy";
>>> + compatible = "samsung,exynos4212-hdmiphy";
>>> reg =<0x38>;
>>> };
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>> b/arch/arm/boot/dts/exynos5250.dtsi
>>> index 0673524..2f7763b 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -601,7 +601,7 @@
>>> };
>>>
>>> hdmi {
>>> - compatible = "samsung,exynos5-hdmi";
>>> + compatible = "samsung,exynos4212-hdmi";
>>> reg =<0x1453 0x7>;
>>> interrupts =<0 95 0>;
>>> clocks =< 333>,< 136>,< 137>,
>>> @@ -611,7 +611,7 @@
>>> };
>>>
>>> mixer {
>>> - compatible = "samsung,exynos5-mixer";
>>> + compatible = "samsung,exynos5250-mixer";
>>> reg =<0x1445 0x1>;
>>> interrupts =<0 94 0>;
>>> };

[PATCH -next] gpu: fix printk format warning in i915_gem.c

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix printk format warning in i915_gem.c:

drivers/gpu/drm/i915/i915_gem.c:3113:3: warning: format '%ld' expects argument 
of type 'long int', but argument 5 has type 'size_t' [-Wformat]

Signed-off-by: Randy Dunlap 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20130619.orig/drivers/gpu/drm/i915/i915_gem.c
+++ linux-next-20130619/drivers/gpu/drm/i915/i915_gem.c
@@ -3110,7 +3110,7 @@ i915_gem_object_bind_to_gtt(struct drm_i
 * before evicting everything in a vain attempt to find space.
 */
if (obj->base.size > gtt_max) {
-   DRM_ERROR("Attempting to bind an object larger than the 
aperture: object=%zd > %s aperture=%ld\n",
+   DRM_ERROR("Attempting to bind an object larger than the 
aperture: object=%zd > %s aperture=%zu\n",
  obj->base.size,
  map_and_fenceable ? "mappable" : "total",
  gtt_max);

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

> -Original Message-
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Wednesday, June 19, 2013 7:22 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
> 
> Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
> >
> > > -Original Message-
> > > From: Lucas Stach [mailto:l.stach at pengutronix.de]
> > > Sent: Tuesday, June 18, 2013 6:47 PM
> > > To: Inki Dae
> > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> > > kernel at lists.infradead.org; linux-media at vger.kernel.org
> > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
> synchronization
> > > framework
> > >
> > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
> > > [...]
> > > >
> > > > > a display device driver.  It shouldn't be used within a single
> driver
> > > > > as a means of passing buffers between userspace and kernel space.
> > > >
> > > > What I try to do is not really such ugly thing. What I try to do is
> to
> > > > notify that, when CPU tries to access a buffer , to kernel side
> through
> > > > dmabuf interface. So it's not really to send the buffer to kernel.
> > > >
> > > > Thanks,
> > > > Inki Dae
> > > >
> > > The most basic question about why you are trying to implement this
> sort
> > > of thing in the dma_buf framework still stands.
> > >
> > > Once you imported a dma_buf into your DRM driver it's a GEM object and
> > > you can and should use the native DRM ioctls to prepare/end a CPU
> access
> > > to this BO. Then internally to your driver you can use the dma_buf
> > > reservation/fence stuff to provide the necessary cross-device sync.
> > >
> >
> > I don't really want that is used only for DRM drivers. We really need
> > it for all other DMA devices; i.e., v4l2 based drivers. That is what I
> > try to do. And my approach uses reservation to use dma-buf resources
> > but not dma fence stuff anymore. However, I'm looking into Radeon DRM
> > driver for why we need dma fence stuff, and how we can use it if
> > needed.
> >
> 
> Still I don't see the point why you need syncpoints above dma-buf. In
> both the DRM and the V4L2 world we have defined points in the API where
> a buffer is allowed to change domain from device to CPU and vice versa.
> 
> In DRM if you want to access a buffer with the CPU you do a cpu_prepare.
> The buffer changes back to GPU domain once you do the execbuf
> validation, queue a pageflip to the buffer or similar things.
> 
> In V4L2 the syncpoints for cache operations are the queue/dequeue API
> entry points. Those are also the exact points to synchronize with other
> hardware thus using dma-buf reserve/fence.


If so, what if we want to access a buffer with the CPU _in V4L2_? We should 
open a drm device node, and then do a cpu_prepare? 

Thanks,
Inki Dae

> 
> In all this I can't see any need for a new syncpoint primitive slapped
> on top of dma-buf.
> 
> Regards,
> Lucas
> --
> Pengutronix e.K.   | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
> On the other hand, the below shows how we could enhance the conventional
> way with my approach (just example):
> 
> CPU -> DMA,
> ioctl(qbuf command)  ioctl(streamon)
>   |   |
>   |   |
> qbuf  <- dma_buf_sync_get   start streaming <- syncpoint
> 
> dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object. And
> the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
> accesses the sync buffer.
> 
> And DMA -> CPU,
> ioctl(dqbuf command)
>   |
>   |
> dqbuf <- nothing to do
> 
> Actual syncpoint is when DMA operation is completed (in interrupt handler):
> the syncpoint is performed by calling dma_buf_sync_unlock().
> Hence,  my approach is to move the syncpoints into just before dma access
> as long as possible.

What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.

[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma 
---
 arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
 arch/arm/boot/dts/exynos5250.dtsi |4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq = <66000>;

hdmiddc at 50 {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq = <378000>;

hdmiphy at 38 {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq = <66000>;

hdmiddc at 50 {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq = <66000>;

hdmiphy at 38 {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};

hdmi {
-   compatible = "samsung,exynos5-hdmi";
+   compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
clocks = < 333>, < 136>, < 137>,
@@ -611,7 +611,7 @@
};

mixer {
-   compatible = "samsung,exynos5-mixer";
+   compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
-- 
1.7.10.4

[PATCH v3 2/3] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Add support for exynos5420 mixer IP in the drm mixer driver.

Signed-off-by: Rahul Sharma 
---
 .../devicetree/bindings/video/exynos_mixer.txt |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c  |   49 +++-
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9131b99..3334b0a 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -5,6 +5,7 @@ Required properties:
1) "samsung,exynos5-mixer" 
2) "samsung,exynos4210-mixer"
3) "samsung,exynos5250-mixer"
+   4) "samsung,exynos5420-mixer"

 - reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6225501..b1280b4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+   MXR_VER_128_0_0_184,
 };

 struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);

-   /* choosing between porper HD and SD mode */
-   if (height <= 480)
-   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height <= 576)
-   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height <= 720)
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height <= 1080)
-   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
-   else
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+   /* choosing between proper HD and SD mode */
+   if (height <= 480)
+   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+   else if (height <= 576)
+   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+   else if (height <= 720)
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   else if (height <= 1080)
+   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+   else
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   }

mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
 }
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);

+   /* setup display size */
+   if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+   win == MIXER_DEFAULT_WIN) {
+   val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+   val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+   mixer_reg_write(res, MXR_RESOLUTION, val);
+   }
+
val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
mixer_cfg_layer(ctx, win, true);

/* layer update mandatory for mixer 16.0.33.0 */
-   if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);

mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)

 static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
 {
+   struct mixer_context *mixer_ctx = ctx;
u32 w, h;

w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);

+   if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+   mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+   return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
exynos_drm_hdmi_context *ctx,
return 0;
 }

+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+   .version = MXR_VER_128_0_0_184,
+   .is_vp_enabled = 0,
+};
+
 static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1145,6 +1167,9 @@ 

[PATCH v3 1/3] drm/exynos: add new compatible strings for hdmi subsystem

[Rahul Sharma]

This patch adds new combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.

Signed-off-by: Rahul Sharma 
---
 Documentation/devicetree/bindings/video/exynos_hdmi.txt   |7 +--
 .../devicetree/bindings/video/exynos_hdmiddc.txt  |7 +--
 .../devicetree/bindings/video/exynos_hdmiphy.txt  |7 +--
 Documentation/devicetree/bindings/video/exynos_mixer.txt  |8 ++--
 drivers/gpu/drm/exynos/exynos_ddc.c   |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
 drivers/gpu/drm/exynos/exynos_hdmiphy.c   |4 
 drivers/gpu/drm/exynos/exynos_mixer.c |   13 -
 8 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..c71d0f0 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,10 @@
 Device-Tree bindings for drm hdmi driver

 Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: value should be one among the following:
+   1) "samsung,exynos5-hdmi" 
+   2) "samsung,exynos4210-hdmi"
+   3) "samsung,exynos4212-hdmi"
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -15,7 +18,7 @@ Required properties:
 Example:

hdmi {
-   compatible = "samsung,exynos5-hdmi";
+   compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = < 7 0xf 1 3>;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..41eee97 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,15 @@
 Device-Tree bindings for hdmiddc driver

 Required properties:
-- compatible: value should be "samsung,exynos5-hdmiddc".
+- compatible: value should be one of the following
+   1) "samsung,exynos5-hdmiddc" 
+   2) "samsung,exynos4210-hdmiddc"
+
 - reg: I2C address of the hdmiddc device.

 Example:

hdmiddc {
-   compatible = "samsung,exynos5-hdmiddc";
+   compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..162f641 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,15 @@
 Device-Tree bindings for hdmiphy driver

 Required properties:
-- compatible: value should be "samsung,exynos5-hdmiphy".
+- compatible: value should be one of the following:
+   1) "samsung,exynos5-hdmiphy" 
+   2) "samsung,exynos4210-hdmiphy".
+   3) "samsung,exynos4212-hdmiphy".
 - reg: I2C address of the hdmiphy device.

 Example:

hdmiphy {
-   compatible = "samsung,exynos5-hdmiphy";
+   compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..9131b99 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,11 @@
 Device-Tree bindings for mixer driver

 Required properties:
-- compatible: value should be "samsung,exynos5-mixer".
+- compatible: value should be one of the following:
+   1) "samsung,exynos5-mixer" 
+   2) "samsung,exynos4210-mixer"
+   3) "samsung,exynos5250-mixer"
+
 - reg: physical base address of the mixer and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -9,7 +13,7 @@ Required properties:
 Example:

mixer {
-   compatible = "samsung,exynos5-mixer";
+   compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..95c75ed 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -53,6 +53,8 @@ static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = "samsung,exynos5-hdmiddc",
}, {
+  

[PATCH v3 0/3] exynos5420/hdmi: add support for hdmi subsystem

[Rahul Sharma]

Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 mixer and Changes the drivers as per IP modifications.

This set doesn't have changes for hdmiphy, which will posted
independently.

This set is based on drm-next branch of Inki Dae's tree at
http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git.

v3:
1) instead of replacing with old compatible strings, new ones are added
without removing the support for older ones.
2) removed patch "drm/exynos: fix interlace resolutions for exynos5420" as
it is independently merged.

v2:
1)update device mixer tree binding document with "samsung,exynos5420-mixer"

Rahul Sharma (3):
  drm/exynos: add new compatible strings for hdmi subsystem
  drm/exynos: add support for exynos5420 mixer
  ARM/dts: change compatible strings for hdmi subsystem

 .../devicetree/bindings/video/exynos_hdmi.txt  |7 ++-
 .../devicetree/bindings/video/exynos_hdmiddc.txt   |7 ++-
 .../devicetree/bindings/video/exynos_hdmiphy.txt   |7 ++-
 .../devicetree/bindings/video/exynos_mixer.txt |9 ++-
 arch/arm/boot/dts/cros5250-common.dtsi |4 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +-
 arch/arm/boot/dts/exynos5250.dtsi  |4 +-
 drivers/gpu/drm/exynos/exynos_ddc.c|2 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |3 +
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 ++
 drivers/gpu/drm/exynos/exynos_mixer.c  |   62 ++--
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 12 files changed, 89 insertions(+), 31 deletions(-)

-- 
1.7.10.4

[RFC PATCH v3] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
potentially user application (not implemented for user applications, yet).
And this framework can be used for all dma devices using system memory as
dma buffer, especially for most ARM based SoCs.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
1. Register dmabufs to a sync object - A task gets a new sync object and
can add one or more dmabufs that the task wants to access.
This registering should be performed when a device context or an event
context such as a page flip event is created or before CPU accesses a shared
buffer.

dma_buf_sync_get(a sync object, a dmabuf);

2. Lock a sync object - A task tries to lock all dmabufs added in its own
sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
and DMA. Taking a lock means that others cannot access all locked dmabufs
until the task that locked the corresponding dmabufs, unlocks all the locked
dmabufs.
This locking should be performed before DMA or CPU accesses these dmabufs.

dma_buf_sync_lock(a sync object);

3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
object. The unlock means that the DMA or CPU accesses to the dmabufs have
been completed so that others may access them.
This unlocking should be performed after DMA or CPU has completed accesses
to the dmabufs.

dma_buf_sync_unlock(a sync object);

4. Unregister one or all dmabufs from a sync object - A task unregisters
the given dmabufs from the sync object. This means that the task dosen't
want to lock the dmabufs.
The unregistering should be performed after DMA or CPU has completed
accesses to the dmabufs or when dma_buf_sync_lock() is failed.

dma_buf_sync_put(a sync object, a dmabuf);
dma_buf_sync_put_all(a sync object);

The described steps may be summarized as:
get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put

This framework includes the following two features.
1. read (shared) and write (exclusive) locks - A task is required to declare
the access type when the task tries to register a dmabuf;
READ, WRITE, READ DMA, or WRITE DMA.

The below is example codes,
struct dmabuf_sync *sync;

sync = dmabuf_sync_init(NULL, "test sync");

dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
...

And the below can be used as access types:
DMA_BUF_ACCESS_R - CPU will access a buffer for read.
DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or
write.

2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
A task may never try to unlock a buffer after taking a lock to the buffer.
In this case, a timer handler to the corresponding sync object is called
in five (default) seconds and then the timed-out buffer is unlocked by work
queue handler to avoid lockups and to enforce resources of the buffer.

The below is how to use:
1. Allocate and Initialize a sync object:
struct dmabuf_sync *sync;

sync = dmabuf_sync_init(NULL, "test sync");
...

2. Add a dmabuf to the sync object when setting up dma buffer relevant
   registers:
dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ);
...

3. Lock all dmabufs of the sync object before DMA or CPU accesses
   the dmabufs:
dmabuf_sync_lock(sync);
...

4. Now CPU or DMA can access all dmabufs locked in step 3.

5. Unlock all dmabufs added in a sync object after DMA or CPU access
   to these dmabufs is completed:
dmabuf_sync_unlock(sync);

   And call the following functions to release all resources,
dmabuf_sync_put_all(sync);
dmabuf_sync_fini(sync);

You can refer to actual example codes:

https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/

commit/?h=dmabuf-sync=4030bdee9bab5841ad32faade528d04cc0c5fc94

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Inki Dae]

> -Original Message-
> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> Behalf Of Lucas Stach
> Sent: Wednesday, June 19, 2013 4:59 PM
> To: Tomasz Figa
> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
> sw0312.kim at samsung.com; joshi at samsung.com;
dri-devel at lists.freedesktop.org;
> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
> 
> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> > Hi Rahul,
> >
> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> > > This patch renames the combatible strings for hdmi, mixer, ddc
> > > and hdmiphy. It follows the convention of using compatible string
> > > which represent the SoC in which the IP was added for the first
> > > time.
> > >
> > > Signed-off-by: Rahul Sharma 
> > > ---
> > >  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
> > >  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
|
> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> > > 589edee..2ac01ca 100644
> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > > @@ -1,7 +1,9 @@
> > >  Device-Tree bindings for drm hdmi driver
> > >
> > >  Required properties:
> > > -- compatible: value should be "samsung,exynos5-hdmi".
> > > +- compatible: value should be one among the following:
> > > + 1) "samsung,exynos4210-hdmi"
> > > + 2) "samsung,exynos4212-hdmi"
> > >  - reg: physical base address of the hdmi and length of memory mapped
> > >   region.
> > >  - interrupts: interrupt number to the cpu.
> > > @@ -15,7 +17,7 @@ Required properties:
> > >  Example:
> > >
> > >   hdmi {
> > > - compatible = "samsung,exynos5-hdmi";
> > > + compatible = "samsung,exynos4212-hdmi";
> >
> > Sorry, but it's a NAK from me.
> >
> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
> to
> > work with new kernels.
> >
> > If you just change the binding this way, you break all the existing
> users
> > of this compatible value.
> >
> > In addition you are doing it in a way that breaks bisection:
> >  - patch 1/4 breaks existing in-tree users of current compatible values,
> >  - after patch 2 and 3 it is still broken,
> >  - and eventually all in-tree users are fixed by patch 4 (but you can't
> > fix out-of-tree users).
> >
> > Please do it without changing existing compatible values. Even if they
> are
> > misleading, this is all can be described in the documentation - just
> list
> > SoCs that can be used with each compatible value there.
> >
> 
> Or you could just introduce the new compatible value and make all
> in-tree users use this, but keep the old values around and still accept
> them in the drivers. This way you get the goodness of the cleaner new
> symbols without breaking existing users. Just mark the old values as
> deprecated in the documentation, so no new devicetree usees them.
> 

That's a good idea. We really need to mitigate such misleading somehow or
other.

Thanks,
Inki Dae

> Regards,
> Lucas
> --
> Pengutronix e.K.   | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64913

--- Comment #15 from Alex Deucher  ---
Please use git to format the patch and include a description of what the patch
does and how it fixes the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/7f3f3987/attachment.html>

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64913

--- Comment #14 from Alex Deucher  ---
I'd suggest sending it to the mailing list (mesa-dev at lists.freedesktop.org).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/2c7d276c/attachment.html>

[PATCH] drm/radeon: update lockup tracking when scheduling in empty ring

[Christian König]

Am 19.06.2013 16:02, schrieb j.glisse at gmail.com:
> From: Jerome Glisse 
>
> There might be issue with lockup detection when scheduling on an
> empty ring that have been sitting idle for a while. Thus update
> the lockup tracking data when scheduling new work in an empty ring.
>
> Signed-off-by: Jerome Glisse 
> Tested-by: Andy Lutomirski 
> Cc: stable at vger.kernel.org

Reviewed-by: Christian K?nig 

> ---
>   drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index e17faa7..82434018 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct 
> radeon_ring *ring, unsi
>   return -ENOMEM;
>   /* Align requested size with padding so unlock_commit can
>* pad safely */
> + radeon_ring_free_size(rdev, ring);
> + if (ring->ring_free_dw == (ring->ring_size / 4)) {
> + /* This is an empty ring update lockup info to avoid
> +  * false positive.
> +  */
> + radeon_ring_lockup_update(ring);
> + }
>   ndw = (ndw + ring->align_mask) & ~ring->align_mask;
>   while (ndw > (ring->ring_free_dw - 1)) {
>   radeon_ring_free_size(rdev, ring);

[PATCH 10/10] idr: Rework idr_preload()

[Tejun Heo]

On Wed, Jun 19, 2013 at 04:33:44PM -0700, Kent Overstreet wrote:
> With respect to performance, strongly disagree. Leaving pointers out of
> the interior nodes cuts our space requirements by a factor of _64_ -
> that's huge, and with data structures the dominating factors w.r.t.
> performance tend to be the amount of memory you touch and the amount of
> pointer chasing.
> 
> The lack of pointer chasing also means I could add prefetching to the
> tree walking code (child nodes are always contiguous in memory) like I
> did in bcache's binary search trees - I didn't realize DLM was using
> this for so many ids so I'll probably add that.
>
> That means for quite large bitmaps, _all_ the interior nodes will fit
> onto a couple cachelines which are all contiguous in memory. That's
> _huge_.

Do all that in the leaf node which will be able to serve most use
cases with single leaf node anyway, so you really don't lose anything.

> Even for 1 million ids - that's 128 kilobytes for all the leaf nodes,
> which means all the interior nodes take up 2 kilobytes - which again is
> contiguous so we can prefetch far in advance as we walk down the tree.

So, that's ~30k IDs per page, right?  Let the internal node have 64
fan out, then you'll only have single depth tree for 1mil.  Again,
you're not losing much, if anything, while gaining more predictable
behavior and flexibility.

> Also, idr_find() was slower than radix_tree_lookup() before, as tested
> for some aio patches - decoupling the id allocation from the radix tree
> gives the id allocator more freedom in its data structures (couldn't
> realloc before without breaking RCU lookup).

Yeah, sure.  I don't have any problem implementing idr in terms of
ida.  I do have problems with ida being one contiguous array.

> Besides all that, the ida/idr reimplementations deleted > 300 lines of
> code from idr.[ch]. If you try to add caching to the existing ida code,
> it's only going to get more complicated - and trying to maintain the
> behaviour where we always allocate the smallest available id is going to
> be fun there (the cache has to be kept in sorted order every time you
> free an id).

It's like recursive code.  It looks more elegant and looks okay for
most cases but breaks in corner cases and we end up converting it to
iterative code anyway.  Similar thing.  Long contiguous arrays just
don't work.  We're very likely to break it up eventually anyway.

> (I'm still not going to go with anything resembling a radix tree though
> - instead of having a flat array, I'll have a an array of pointers to
> fixed size array segments once the entire tree exceeds a certain size).

I don't really care how it gets split but firm nack on single
contiguous array.

> > But we allow mixing preloaded and normal allocations and users are
> > allowed to allocate as many IDs they want after preloading.  It should
> > guarantee that the first allocation after preloading follows the
> > stronger allocation flag, and the above approach can't guarantee that.
> 
> None of the existing code nedes that guarantee, though.

Hmmm?  ISTR users mixing preloaded and !preloaded allocations.  Maybe
I'm misremembering.  I don't know.  But still the API is nasty like
hell.  Nobody is gonna notice even if it's being misused.  It's just
gonna have allocation failure after preloading once in a blue moon and
we won't be able to track it down.

> That's what I documented, and I audited all the existing idr_preload()
> users (had to anyways). Generally speaking idr allocations are done from
> a central location anyways so IMO it's a pretty trivial issue in
> practice.

If that has to happen, you need to enforce it.  Trigger WARN if
somebody violates the rule, but really this is just nasty.

Thanks.

-- 
tejun

[PATCH] drm/shmobile: Drop usage of removed drm_plane enabled field

[Laurent Pinchart]

The enabled field has been removed from struct drm_plane. Don't use it
in the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This fixes a compilation error in drm-next. I will send a pull request for the
shmob-drm patches by the end of the week.

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c 
b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
index 6898f6f..060ae03 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
@@ -166,7 +166,7 @@ void shmob_drm_plane_setup(struct drm_plane *plane)
 {
struct shmob_drm_plane *splane = to_shmob_plane(plane);

-   if (plane->fb == NULL || !plane->enabled)
+   if (plane->fb == NULL)
return;

__shmob_drm_plane_setup(splane, plane->fb);
-- 
Regards,

Laurent Pinchart

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Inki Dae]

> -Original Message-
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Wednesday, June 19, 2013 4:06 PM
> To: 'Rahul Sharma'; 'linux-samsung-soc at vger.kernel.org'; 'devicetree-
> discuss at lists.ozlabs.org'; 'dri-devel at lists.freedesktop.org'
> Cc: 'kgene.kim at samsung.com'; 'sw0312.kim at samsung.com';
'joshi at samsung.com';
> 'r.sh.open at gmail.com'
> Subject: RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
> 
> 
> 
> > -Original Message-
> > From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> > Sent: Tuesday, June 18, 2013 9:50 PM
> > To: linux-samsung-soc at vger.kernel.org; devicetree-
> discuss at lists.ozlabs.org;
> > dri-devel at lists.freedesktop.org
> > Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at 
> > samsung.com;
> > joshi at samsung.com; r.sh.open at gmail.com; Rahul Sharma
> > Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> > subsystem
> >
> > This patch renames the combatible strings for hdmi, mixer, ddc
> > and hdmiphy. It follows the convention of using compatible string
> > which represent the SoC in which the IP was added for the first
> > time.
> >
> 
> Hi Rahul,
> 
> Could you separate this patch into two patches, driver side and document
> side, and the below patch also?
>   [PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
> 

Sorry, just will merge them.

To devicetree maintainers, please give me ACK.

Thanks,
Inki Dae

> Thanks,
> Inki Dae
> 
> > Signed-off-by: Rahul Sharma 
> > ---
> >  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
--
> >  Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> >  Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6
--
> >  Documentation/devicetree/bindings/video/exynos_mixer.txt   |7
+--
> >  drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> >  drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
> >  drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> >  drivers/gpu/drm/exynos/exynos_mixer.c  |   12
++-
> -
> >  8 files changed, 26 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > index 589edee..2ac01ca 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > @@ -1,7 +1,9 @@
> >  Device-Tree bindings for drm hdmi driver
> >
> >  Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmi".
> > +- compatible: value should be one among the following:
> > +   1) "samsung,exynos4210-hdmi"
> > +   2) "samsung,exynos4212-hdmi"
> >  - reg: physical base address of the hdmi and length of memory mapped
> > region.
> >  - interrupts: interrupt number to the cpu.
> > @@ -15,7 +17,7 @@ Required properties:
> >  Example:
> >
> > hdmi {
> > -   compatible = "samsung,exynos5-hdmi";
> > +   compatible = "samsung,exynos4212-hdmi";
> > reg = <0x1453 0x10>;
> > interrupts = <0 95 0>;
> > hpd-gpio = < 7 0xf 1 3>;
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > index fa166d9..c1bd2ea 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> > @@ -1,12 +1,12 @@
> >  Device-Tree bindings for hdmiddc driver
> >
> >  Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmiddc".
> > +- compatible: value should be "samsung,exynos4210-hdmiddc".
> >  - reg: I2C address of the hdmiddc device.
> >
> >  Example:
> >
> > hdmiddc {
> > -   compatible = "samsung,exynos5-hdmiddc";
> > +   compatible = "samsung,exynos4210-hdmiddc";
> > reg = <0x50>;
> > };
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > index 858f4f9..e59d793 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> > @@ -1,12 +1,14 @@
> >  Device-Tree bindings for hdmiphy driver
> >
> >  Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmiphy".
> > +- compatible: value should be
> > +   1) "samsung,exynos4210-hdmiphy".
> > +   2) "samsung,exynos4212-hdmiphy".
> >  - reg: I2C address of the hdmiphy device.
> >
> >  Example:
> >
> > hdmiphy {
> > -   compatible = "samsung,exynos5-hdmiphy";
> > +   compatible = "samsung,exynos4210-hdmiphy";
> > reg = <0x38>;
> > };
> > diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> > 

[PATCH 10/10] idr: Rework idr_preload()

[Kent Overstreet]

On Wed, Jun 19, 2013 at 01:18:32AM -0700, Tejun Heo wrote:
> Hello, Kent.
> 
> On Tue, Jun 18, 2013 at 05:02:30PM -0700, Kent Overstreet wrote:
> > With the new ida implementation, that doesn't work anymore - the new ida
> > code grows its bitmap tree by reallocating the entire thing in power of
> > two increments. Doh.
> 
> So, I'm not sure about the single contiguous array implementation.  It
> introduces some nasty characteristics such as possibly too large
> contiguous allocation, bursty CPU usages, and loss of the ability to
> handle ID allocations clustered in high areas - sure, the old ida
> wasn't great on that part either but this can be much worse.
> 
> In addition, I'm not sure what this single contiguous allocation buys
> us.  Let's say each leaf node size is 4k.  Even with in-array tree
> implementation, it should be able to serve 2k IDs per-page, which
> would be enough for most use cases and with a bit of caching it can
> easily achieve both the performance benefits of array implementation
> and the flexibility of allocating each leaf separately.  Even without
> caching, the tree depth would normally be much lower than the current
> implementation and the performance should be better.  If you're
> bothered by having to implement another radix tree for it, it should
> be possible to just implement the leaf node logic and use the existing
> radix tree for internal nodes, right?

With respect to performance, strongly disagree. Leaving pointers out of
the interior nodes cuts our space requirements by a factor of _64_ -
that's huge, and with data structures the dominating factors w.r.t.
performance tend to be the amount of memory you touch and the amount of
pointer chasing.

The lack of pointer chasing also means I could add prefetching to the
tree walking code (child nodes are always contiguous in memory) like I
did in bcache's binary search trees - I didn't realize DLM was using
this for so many ids so I'll probably add that.

That means for quite large bitmaps, _all_ the interior nodes will fit
onto a couple cachelines which are all contiguous in memory. That's
_huge_.

Even for 1 million ids - that's 128 kilobytes for all the leaf nodes,
which means all the interior nodes take up 2 kilobytes - which again is
contiguous so we can prefetch far in advance as we walk down the tree.

(If I was optimizing for huge bitmaps I would've picked a bigger splay
factor and the interior nodes would take up even less memory, but I've
been assuming the common case for the bitmap size is less than a page in
which case BITS_PER_LONG should be about right).

Also, idr_find() was slower than radix_tree_lookup() before, as tested
for some aio patches - decoupling the id allocation from the radix tree
gives the id allocator more freedom in its data structures (couldn't
realloc before without breaking RCU lookup).

I'm highly skeptical the bursty CPU usage is going to be a real issue in
practice, as that can happen anywhere we do allocation - the realloc is
going to be trivial compared to what can happen then. What's important
is just the amortized cpu overhead, and in that respect doing the
realloc is definitely a performance win.

Besides all that, the ida/idr reimplementations deleted > 300 lines of
code from idr.[ch]. If you try to add caching to the existing ida code,
it's only going to get more complicated - and trying to maintain the
behaviour where we always allocate the smallest available id is going to
be fun there (the cache has to be kept in sorted order every time you
free an id).

Sparse id allocations/allocations clustered in the high areas isn't a
concern - part of the reason I separated out ida_alloc() from
ida_alloc_range() was to make sure none of the existing code was doing
anything dumb with the starting id.

The only thing that would've been a problem there was idr_alloc_cyclic()
(and the code that was open coding ida_alloc_cyclic() as a performance
hack), but the new ida_alloc_cyclic() handles that - handles it better
than the old version, too.

The only real concern I've come across is the fact that this
implementation currently can't allocate up to INT_MAX ids with the whole
allocation being contiguous - for all the uses I'd looked at I didn't
think this was going to be an issue, but turns out it probably will be
for DLM. So I've got a bit more work to do there.

(I'm still not going to go with anything resembling a radix tree though
- instead of having a flat array, I'll have a an array of pointers to
fixed size array segments once the entire tree exceeds a certain size).

> > So we need a slightly different trick. Note that if all allocations from
> > an idr start by calling idr_prealloc() and disabling premption, at
> > most nr_cpus() allocations can happen before someone calls
> > idr_prealloc() again.
> 
> But we allow mixing preloaded and normal allocations and users are
> allowed to allocate as many IDs they want after preloading.  It should
> guarantee that the first allocation 

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Inki Dae]

> -Original Message-
> From: Rahul Sharma [mailto:rahul.sharma at samsung.com]
> Sent: Tuesday, June 18, 2013 9:50 PM
> To: linux-samsung-soc at vger.kernel.org;
devicetree-discuss at lists.ozlabs.org;
> dri-devel at lists.freedesktop.org
> Cc: kgene.kim at samsung.com; sw0312.kim at samsung.com; inki.dae at 
> samsung.com;
> joshi at samsung.com; r.sh.open at gmail.com; Rahul Sharma
> Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> subsystem
> 
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
> 

Hi Rahul,

Could you separate this patch into two patches, driver side and document
side, and the below patch also?
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer

Thanks,
Inki Dae

> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
>  Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
>  Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
>  Documentation/devicetree/bindings/video/exynos_mixer.txt   |7 +--
>  drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
>  drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
>  drivers/gpu/drm/exynos/exynos_mixer.c  |   12
++--
>  8 files changed, 26 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
>  Device-Tree bindings for drm hdmi driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
>  - reg: physical base address of the hdmi and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
>  Example:
> 
>   hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
>   reg = <0x1453 0x10>;
>   interrupts = <0 95 0>;
>   hpd-gpio = < 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
>  Device-Tree bindings for hdmiddc driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
>  - reg: I2C address of the hdmiddc device.
> 
>  Example:
> 
>   hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
>   reg = <0x50>;
>   };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
>  Device-Tree bindings for hdmiphy driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
>  - reg: I2C address of the hdmiphy device.
> 
>  Example:
> 
>   hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
>   reg = <0x38>;
>   };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
>  Device-Tree bindings for mixer driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
>  - reg: physical base address of the mixer and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required properties:
>  Example:
> 
>   mixer {
> - compatible = "samsung,exynos5-mixer";
> + 

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Rahul Sharma]

On Wed, Jun 19, 2013 at 3:20 PM, Tomasz Figa  wrote:
> Hi Rahul,
>
> On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
>> Hi All,
>>
>> On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae  wrote:
>> >> -Original Message-
>> >> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
>> >> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] 
>> >> On
>> >> Behalf Of Lucas Stach
>> >> Sent: Wednesday, June 19, 2013 4:59 PM
>> >> To: Tomasz Figa
>> >> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
>> >> sw0312.kim at samsung.com; joshi at samsung.com;
>> >
>> > dri-devel at lists.freedesktop.org;
>> >
>> >> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
>> >> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
>> >> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
>> >> subsystem
>> >>
>> >> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
>> >> > Hi Rahul,
>> >> >
>> >> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
>> >> > > This patch renames the combatible strings for hdmi, mixer, ddc
>> >> > > and hdmiphy. It follows the convention of using compatible string
>> >> > > which represent the SoC in which the IP was added for the first
>> >> > > time.
>> >> > >
>> >> > > Signed-off-by: Rahul Sharma 
>> >> > > ---
>> >> > >
>> >> > >  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
>> >> > >
>> >> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
>> >> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
>> >> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
>> >> > >
>> >> > >  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
>> >> > >
>> >> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
>> >> > >
>> >> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|
>> >> > > 4
>> >> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c  |
>> >> > > 12
>> >> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>> >> > >
>> >> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
>> >> > > 589edee..2ac01ca 100644
>> >> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> >> > > @@ -1,7 +1,9 @@
>> >> > >
>> >> > >  Device-Tree bindings for drm hdmi driver
>> >> > >
>> >> > >  Required properties:
>> >> > > -- compatible: value should be "samsung,exynos5-hdmi".
>> >> > > +- compatible: value should be one among the following:
>> >> > > + 1) "samsung,exynos4210-hdmi"
>> >> > > + 2) "samsung,exynos4212-hdmi"
>> >> > >
>> >> > >  - reg: physical base address of the hdmi and length of memory mapped
>> >> > >
>> >> > >   region.
>> >> > >
>> >> > >  - interrupts: interrupt number to the cpu.
>> >> > >
>> >> > > @@ -15,7 +17,7 @@ Required properties:
>> >> > >  Example:
>> >> > >   hdmi {
>> >> > >
>> >> > > - compatible = "samsung,exynos5-hdmi";
>> >> > > + compatible = "samsung,exynos4212-hdmi";
>> >> >
>> >> > Sorry, but it's a NAK from me.
>> >> >
>> >> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
>> >>
>> >> to
>> >>
>> >> > work with new kernels.
>> >> >
>> >> > If you just change the binding this way, you break all the existing
>> >>
>> >> users
>> >>
>> >> > of this compatible value.
>> >> >
>> >> > In addition you are doing it in a way that breaks bisection:
>> >> >  - patch 1/4 breaks existing in-tree users of current compatible
>> >> >  values,
>> >> >  - after patch 2 and 3 it is still broken,
>> >> >  - and eventually all in-tree users are fixed by patch 4 (but you can't
>> >> >
>> >> > fix out-of-tree users).
>>
>> @Tomasz, I understand your point but how is it possible to change
>> compatible types in driver as well as in dtbs by not breaking either of them
>> other then putting changes in a single patch.
>
> It's very easy. (Let's forget about the fact that DT bindings are an ABI
> temporarily) You can simply add new compatible values to the driver in first
> patch, then modify dts files in second one and then remove old compatibles
> values from the driver in third patch. (Now we remember about DT being ABI
> again.)
>
>> I ensured that hdmi stuff is
>> intact with whole series merged in either tree (drm or arch). Please
>> suggest a better way.
>>
>> The Only existing user is Exynos5250, which is modified in the same patch
>> set.
>
> This is not true. You have modified only the existing _in_ _tree_ users.
>
> Keep in mind that device tree is not a part of the kernel. It is currently
> located in the same tree, but it is _not_ a part of the kernel.
>
> Now think about existing boards (like exynos5250-snow) that have a dtb built
> from older dts sources stored in their flash memory. You need to 

[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63599

--- Comment #11 from wojtek  ---
Motherboard: Gigabyte Technology Co., Ltd. GA-A75M-UD2H/GA-A75M-UD2H, BIOS F5
11/03/2011

CPU: AMD A4-3400 APU with Radeon(tm) HD Graphics (fam: 12, model: 01, stepping:
00)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/fffde289/attachment.html>

[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer

[김승우]

On 2013? 06? 19? 15:50, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
> 
> Signed-off-by: Rahul Sharma 

Acked-by: Seung-Woo Kim 

This patch can be merged after merging "[PATCH 1/4] drm/exynos: rename
compatible strings for hdmi subsystem".

Best Regards,
- Seung-Woo Kim

> ---
>  .../devicetree/bindings/video/exynos_mixer.txt |1 +
>  drivers/gpu/drm/exynos/exynos_mixer.c  |   49 
> +++-
>  drivers/gpu/drm/exynos/regs-mixer.h|7 +++
>  3 files changed, 45 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index a8b063f..c64ddc1 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - compatible: value should be:
>   1) "samsung,exynos4210-mixer"
>   2) "samsung,exynos5250-mixer"
> + 3) "samsung,exynos5420-mixer"
>  
>  - reg: physical base address of the mixer and length of memory mapped
>   region.
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2fe6d33..d51ff36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
>  enum mixer_version_id {
>   MXR_VER_0_0_0_16,
>   MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
>  };
>  
>  struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
> unsigned int height)
>   val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
>   MXR_CFG_SCAN_PROGRASSIVE);
>  
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>  
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>  }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context 
> *ctx, int win)
>   /* setup geometry */
>   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>  
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
>   val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
>   val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
>   val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
> int win)
>   mixer_cfg_layer(ctx, win, true);
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
>   mixer_layer_update(ctx);
>  
>   mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>  
>  static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
>  {
> + struct mixer_context *mixer_ctx = ctx;
>   u32 w, h;
>  
>   w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
> drm_display_mode *mode)
>   mode->hdisplay, mode->vdisplay, mode->vrefresh,
>   (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>  
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
>   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
> 

[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63599

--- Comment #10 from Jerome Glisse  ---
What is the motherboard and cpu reference ?

AMD A4-3400 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/bff6148a/attachment.html>

[PATCH] drm/prime: support to cache mapping

[Joonyoung Shim]

The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/drm_prime.c | 54 +
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..ac48038 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,15 +62,29 @@ struct drm_prime_member {
struct dma_buf *dma_buf;
uint32_t handle;
 };
+
+struct drm_prime_attachment {
+   struct sg_table *sgt;
+   enum dma_data_direction dir;
+};
+
 static int drm_prime_add_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);

 static int drm_gem_map_attach(struct dma_buf *dma_buf,
  struct device *target_dev,
  struct dma_buf_attachment *attach)
 {
+   struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;

+   prime_attach = kzalloc(sizeof(*prime_attach), GFP_KERNEL);
+   if (!prime_attach)
+   return -ENOMEM;
+
+   prime_attach->dir = DMA_NONE;
+   attach->priv = prime_attach;
+
if (!dev->driver->gem_prime_pin)
return 0;

@@ -80,25 +94,59 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
 static void drm_gem_map_detach(struct dma_buf *dma_buf,
   struct dma_buf_attachment *attach)
 {
+   struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
+   struct sg_table *sgt;

if (dev->driver->gem_prime_unpin)
dev->driver->gem_prime_unpin(obj);
+
+   if (!prime_attach)
+   return;
+
+   sgt = prime_attach->sgt;
+
+   if (prime_attach->dir != DMA_NONE)
+   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+   prime_attach->dir);
+
+   sg_free_table(sgt);
+   kfree(sgt);
+   kfree(prime_attach);
+   attach->priv = NULL;
 }

 static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
 {
+   struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
struct sg_table *sgt;

+   if (WARN_ON(dir == DMA_NONE || !prime_attach))
+   return ERR_PTR(-EINVAL);
+
+   /* return the cached mapping when possible */
+   if (prime_attach->dir == dir)
+   return prime_attach->sgt;
+
+   /*
+* two mappings with different directions for the same attachment are
+* not allowed
+*/
+   if (WARN_ON(prime_attach->dir != DMA_NONE))
+   return ERR_PTR(-EBUSY);
+
mutex_lock(>dev->struct_mutex);

sgt = obj->dev->driver->gem_prime_get_sg_table(obj);

-   if (!IS_ERR_OR_NULL(sgt))
+   if (!IS_ERR_OR_NULL(sgt)) {
dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   prime_attach->sgt = sgt;
+   prime_attach->dir = dir;
+   }

mutex_unlock(>dev->struct_mutex);
return sgt;
@@ -107,9 +155,7 @@ static struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
 static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sgt, enum dma_data_direction dir)
 {
-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
-   sg_free_table(sgt);
-   kfree(sgt);
+   /* nothing to be done here */
 }

 static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
-- 
1.8.1.2

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Rahul Sharma]

Hi All,

On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae  wrote:
>
>
>> -Original Message-
>> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
>> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
>> Behalf Of Lucas Stach
>> Sent: Wednesday, June 19, 2013 4:59 PM
>> To: Tomasz Figa
>> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
>> sw0312.kim at samsung.com; joshi at samsung.com;
> dri-devel at lists.freedesktop.org;
>> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
>> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
>> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
>> subsystem
>>
>> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
>> > Hi Rahul,
>> >
>> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
>> > > This patch renames the combatible strings for hdmi, mixer, ddc
>> > > and hdmiphy. It follows the convention of using compatible string
>> > > which represent the SoC in which the IP was added for the first
>> > > time.
>> > >
>> > > Signed-off-by: Rahul Sharma 
>> > > ---
>> > >  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
>> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
>> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
>> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
>> > >  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
> |
>> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
>> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
>> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
>> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
>> > >
>> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
>> > > 589edee..2ac01ca 100644
>> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> > > @@ -1,7 +1,9 @@
>> > >  Device-Tree bindings for drm hdmi driver
>> > >
>> > >  Required properties:
>> > > -- compatible: value should be "samsung,exynos5-hdmi".
>> > > +- compatible: value should be one among the following:
>> > > + 1) "samsung,exynos4210-hdmi"
>> > > + 2) "samsung,exynos4212-hdmi"
>> > >  - reg: physical base address of the hdmi and length of memory mapped
>> > >   region.
>> > >  - interrupts: interrupt number to the cpu.
>> > > @@ -15,7 +17,7 @@ Required properties:
>> > >  Example:
>> > >
>> > >   hdmi {
>> > > - compatible = "samsung,exynos5-hdmi";
>> > > + compatible = "samsung,exynos4212-hdmi";
>> >
>> > Sorry, but it's a NAK from me.
>> >
>> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
>> to
>> > work with new kernels.
>> >
>> > If you just change the binding this way, you break all the existing
>> users
>> > of this compatible value.
>> >
>> > In addition you are doing it in a way that breaks bisection:
>> >  - patch 1/4 breaks existing in-tree users of current compatible values,
>> >  - after patch 2 and 3 it is still broken,
>> >  - and eventually all in-tree users are fixed by patch 4 (but you can't
>> > fix out-of-tree users).
>> >

@Tomasz, I understand your point but how is it possible to change
compatible types in driver as well as in dtbs by not breaking either of them
other then putting changes in a single patch. I ensured that hdmi stuff is
intact with whole series merged in either tree (drm or arch). Please suggest
a better way.

The Only existing user is Exynos5250, which is modified in the same patch
set.

>> > Please do it without changing existing compatible values. Even if they
>> are
>> > misleading, this is all can be described in the documentation - just
>> list
>> > SoCs that can be used with each compatible value there.
>> >
>>
>> Or you could just introduce the new compatible value and make all
>> in-tree users use this, but keep the old values around and still accept
>> them in the drivers. This way you get the goodness of the cleaner new
>> symbols without breaking existing users. Just mark the old values as
>> deprecated in the documentation, so no new devicetree usees them.
>>

I agree, above is a decent approach, but in this case we have only one
user for this compatible type including in flight patches which I have
modified along.

If it seems better to keep old compatible type (deprecated), it is fine
with me.

>
> That's a good idea. We really need to mitigate such misleading somehow or
> other.

Please sugggest me how to proceed.

regards,
Rahul Sharma.

>
> Thanks,
> Inki Dae
>
>> Regards,
>> Lucas
>> --
>> Pengutronix e.K.   | Lucas Stach |
>> Industrial Linux Solutions | http://www.pengutronix.de/  |
>> Peiner Str. 6-8, 31137 Hildesheim, 

[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420

[Inki Dae]

Applied.

Thanks,
Inki Dae

> -Original Message-
> From: ??? [mailto:sw0312.kim at samsung.com]
> Sent: Wednesday, June 19, 2013 2:34 PM
> To: Rahul Sharma
> Cc: linux-samsung-soc at vger.kernel.org; devicetree-
discuss at lists.ozlabs.org;
> dri-devel at lists.freedesktop.org; kgene.kim at samsung.com;
> inki.dae at samsung.com; joshi at samsung.com; r.sh.open at gmail.com; 
> Seung-Woo
> Kim
> Subject: Re: [PATCH 3/4] drm/exynos: fix interlace resolutions for
> exynos5420
> 
> Hi Rahul,
> 
> This patch looks good to me.
> 
> On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> > Modified code for calculating hdmi IP register values from drm timing
> > values. The modification is based on the inputs from hw team and
> specifically
> > proposed for 1440x576i and 1440x480i. But same changes holds good for
> other
> > interlaced resolutions also.
> >
> > Signed-off-by: Rahul Sharma 
> 
> Acked-by: Seung-Woo Kim 
> 
> > ---
> >  drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
> >  1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > index 8752171..2f807d5 100644
> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > (m->vsync_start - m->vdisplay) / 2);
> > hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
> > hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) /
> 2);
> > -   hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
> > -   ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
> > +   hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay /
> 2);
> > hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
> > hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) +
> 7);
> > hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) +
> 2);
> > @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > (m->htotal / 2) + (m->hsync_start - m->hdisplay));
> > hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
> > hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
> > -   hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
> > +   hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
> > +   hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
> > +   hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
> > +   hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
> > hdmi_set_reg(tg->vact_st3, 2, 0x0);
> > hdmi_set_reg(tg->vact_st4, 2, 0x0);
> > } else {
> > @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
> > hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
> > hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
> > +   hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> > +   hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value
> */
> > +   hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value
> */
> > }
> >
> > /* Following values & calculations are same irrespective of mode
> type */
> > @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
> > hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
> > hdmi_set_reg(tg->vsync, 2, 0x1);
> > -   hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
> > -   hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
> > -   hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->tg_3d, 1, 0x0);
> >  }
> >
> >
> 
> --
> Seung-Woo Kim
> Samsung Software R Center
> --

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

> -Original Message-
> From: Lucas Stach [mailto:l.stach at pengutronix.de]
> Sent: Tuesday, June 18, 2013 6:47 PM
> To: Inki Dae
> Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
> 
> Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
> [...]
> >
> > > a display device driver.  It shouldn't be used within a single driver
> > > as a means of passing buffers between userspace and kernel space.
> >
> > What I try to do is not really such ugly thing. What I try to do is to
> > notify that, when CPU tries to access a buffer , to kernel side through
> > dmabuf interface. So it's not really to send the buffer to kernel.
> >
> > Thanks,
> > Inki Dae
> >
> The most basic question about why you are trying to implement this sort
> of thing in the dma_buf framework still stands.
> 
> Once you imported a dma_buf into your DRM driver it's a GEM object and
> you can and should use the native DRM ioctls to prepare/end a CPU access
> to this BO. Then internally to your driver you can use the dma_buf
> reservation/fence stuff to provide the necessary cross-device sync.
> 

I don't really want that is used only for DRM drivers. We really need it for 
all other DMA devices; i.e., v4l2 based drivers. That is what I try to do. And 
my approach uses reservation to use dma-buf resources but not dma fence stuff 
anymore. However, I'm looking into Radeon DRM driver for why we need dma fence 
stuff, and how we can use it if needed.

Thanks,
Inki Dae

> Regards,
> Lucas
> --
> Pengutronix e.K.   | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[김승우]

Hi Rahul,

It looks good, at least, to me.

Best Regards,
- Seung-Woo Kim

On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
> 
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
>  Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
>  Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
>  Documentation/devicetree/bindings/video/exynos_mixer.txt   |7 +--
>  drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
>  drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
>  drivers/gpu/drm/exynos/exynos_mixer.c  |   12 
> ++--
>  8 files changed, 26 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
>  Device-Tree bindings for drm hdmi driver
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
>  - reg: physical base address of the hdmi and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
>  Example:
>  
>   hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
>   reg = <0x1453 0x10>;
>   interrupts = <0 95 0>;
>   hpd-gpio = < 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
>  Device-Tree bindings for hdmiddc driver
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
>  - reg: I2C address of the hdmiddc device.
>  
>  Example:
>  
>   hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
>   reg = <0x50>;
>   };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
>  Device-Tree bindings for hdmiphy driver
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
>  - reg: I2C address of the hdmiphy device.
>  
>  Example:
>  
>   hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
>   reg = <0x38>;
>   };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
>  Device-Tree bindings for mixer driver
>  
>  Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
>  - reg: physical base address of the mixer and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required properties:
>  Example:
>  
>   mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
>   reg = <0x1445 0x1>;
>   interrupts = <0 94 0>;
>   };
> diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
> b/drivers/gpu/drm/exynos/exynos_ddc.c
> index 4e9b5ba..1a0cca1 100644
> --- a/drivers/gpu/drm/exynos/exynos_ddc.c
> +++ b/drivers/gpu/drm/exynos/exynos_ddc.c
> @@ -51,7 +51,7 @@ static struct i2c_device_id ddc_idtable[] = {
>  #ifdef CONFIG_OF
>  static struct of_device_id hdmiddc_match_types[] = {
>   {
> - .compatible = "samsung,exynos5-hdmiddc",
> + 

[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=59761





--- Comment #2 from t3st3r at mail.ru  2013-06-19 14:36:31 ---
Quite hard/time consuming for me at this point. But if no other options left, I
probably can try since this bug is quite annoying.

Right now I know that MESA 9.0.x has been working perfectly with that HD5770.
But MESA 9.1 and up (9.2 git, etc) are broken. This also seems to produce some
visually visible artifacts on textured objects in mentioned "Ryzom" game. Say,
"metallic" objects

However as for kernel itself - the problem is that kernel detects lock-up but
then EPIC FAILs when trying to reset GPU. 

I bet there should be no "BUG: unable to handle kernel paging request" at very
least. Then, kernel never manages to recover from this condition. Neither old
3.8 kernel, nor recent changed GPU reset code from 3.9/3.10 would work.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420

[김승우]

Hi Rahul,

This patch looks good to me.

On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> Modified code for calculating hdmi IP register values from drm timing
> values. The modification is based on the inputs from hw team and specifically
> proposed for 1440x576i and 1440x480i. But same changes holds good for other
> interlaced resolutions also.
> 
> Signed-off-by: Rahul Sharma 

Acked-by: Seung-Woo Kim 

> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 8752171..2f807d5 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context 
> *hdata,
>   (m->vsync_start - m->vdisplay) / 2);
>   hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
>   hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) / 2);
> - hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
> - ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
> + hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay / 2);
>   hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
>   hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) + 7);
>   hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) + 2);
> @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context 
> *hdata,
>   (m->htotal / 2) + (m->hsync_start - m->hdisplay));
>   hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
>   hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
> - hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
> + hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
> + hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
> + hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
> + hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
>   hdmi_set_reg(tg->vact_st3, 2, 0x0);
>   hdmi_set_reg(tg->vact_st4, 2, 0x0);
>   } else {
> @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context 
> *hdata,
>   hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
>   hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
>   hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
> + hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> + hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> + hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
>   }
>  
>   /* Following values & calculations are same irrespective of mode type */
> @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context 
> *hdata,
>   hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
>   hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
>   hdmi_set_reg(tg->vsync, 2, 0x1);
> - hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
>   hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
>   hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
> - hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
>   hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
> - hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
>   hdmi_set_reg(tg->tg_3d, 1, 0x0);
>  }
>  
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae:
> 
> > -Original Message-
> > From: Lucas Stach [mailto:l.stach at pengutronix.de]
> > Sent: Wednesday, June 19, 2013 7:22 PM
> > To: Inki Dae
> > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> > kernel at lists.infradead.org; linux-media at vger.kernel.org
> > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> > framework
> > 
> > Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
> > >
> > > > -Original Message-
> > > > From: Lucas Stach [mailto:l.stach at pengutronix.de]
> > > > Sent: Tuesday, June 18, 2013 6:47 PM
> > > > To: Inki Dae
> > > > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> > > > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> > > > kernel at lists.infradead.org; linux-media at vger.kernel.org
> > > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
> > synchronization
> > > > framework
> > > >
> > > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
> > > > [...]
> > > > >
> > > > > > a display device driver.  It shouldn't be used within a single
> > driver
> > > > > > as a means of passing buffers between userspace and kernel space.
> > > > >
> > > > > What I try to do is not really such ugly thing. What I try to do is
> > to
> > > > > notify that, when CPU tries to access a buffer , to kernel side
> > through
> > > > > dmabuf interface. So it's not really to send the buffer to kernel.
> > > > >
> > > > > Thanks,
> > > > > Inki Dae
> > > > >
> > > > The most basic question about why you are trying to implement this
> > sort
> > > > of thing in the dma_buf framework still stands.
> > > >
> > > > Once you imported a dma_buf into your DRM driver it's a GEM object and
> > > > you can and should use the native DRM ioctls to prepare/end a CPU
> > access
> > > > to this BO. Then internally to your driver you can use the dma_buf
> > > > reservation/fence stuff to provide the necessary cross-device sync.
> > > >
> > >
> > > I don't really want that is used only for DRM drivers. We really need
> > > it for all other DMA devices; i.e., v4l2 based drivers. That is what I
> > > try to do. And my approach uses reservation to use dma-buf resources
> > > but not dma fence stuff anymore. However, I'm looking into Radeon DRM
> > > driver for why we need dma fence stuff, and how we can use it if
> > > needed.
> > >
> > 
> > Still I don't see the point why you need syncpoints above dma-buf. In
> > both the DRM and the V4L2 world we have defined points in the API where
> > a buffer is allowed to change domain from device to CPU and vice versa.
> > 
> > In DRM if you want to access a buffer with the CPU you do a cpu_prepare.
> > The buffer changes back to GPU domain once you do the execbuf
> > validation, queue a pageflip to the buffer or similar things.
> > 
> > In V4L2 the syncpoints for cache operations are the queue/dequeue API
> > entry points. Those are also the exact points to synchronize with other
> > hardware thus using dma-buf reserve/fence.
> 
> 
> If so, what if we want to access a buffer with the CPU _in V4L2_? We
> should open a drm device node, and then do a cpu_prepare? 
> 
Not at all. As I said the syncpoints are the queue/dequeue operations.
When dequeueing a buffer you are explicitly dragging the buffer domain
back from device into userspace and thus CPU domain.

If you are operating on an mmap of a V4L2 processed buffer it's either
before or after it got processed by the hardware and therefore all DMA
operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls.
That is where cache operations and synchronization should happen. The
V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it
back into CPU domain while there is still DMA ongoing. Equally the queue
ioctrl should make sure caches are properly written back to memory. The
results of reading/writing to the mmap of a V4L2 buffer while it is
enqueued to the hardware is simply undefined and there is nothing
suggesting that this is a valid usecase.

Regards,
Lucas

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 2/4] drm/exynos: add support for exynos5420 mixer

[김승우]

Hi Rahul,

Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable string
samsung,exynos5420-mixer is added with this patch.

 Required properties:
 - compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsung,exynos5250-mixer"
+   3) "samsung,exynos5420-mixer"

Thanks and Regards,
- Seung-Woo Kim

On 2013? 06? 18? 21:49, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
> 
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |   49 
> +
>  drivers/gpu/drm/exynos/regs-mixer.h   |7 +
>  2 files changed, 44 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2fe6d33..d51ff36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
>  enum mixer_version_id {
>   MXR_VER_0_0_0_16,
>   MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
>  };
>  
>  struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
> unsigned int height)
>   val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
>   MXR_CFG_SCAN_PROGRASSIVE);
>  
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>  
>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>  }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context 
> *ctx, int win)
>   /* setup geometry */
>   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>  
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
>   val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
>   val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
>   val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
> int win)
>   mixer_cfg_layer(ctx, win, true);
>  
>   /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
>   mixer_layer_update(ctx);
>  
>   mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>  
>  static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
>  {
> + struct mixer_context *mixer_ctx = ctx;
>   u32 w, h;
>  
>   w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
> drm_display_mode *mode)
>   mode->hdisplay, mode->vdisplay, mode->vrefresh,
>   (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>  
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
>   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
> exynos_drm_hdmi_context *ctx,
>   return 0;
>  }
>  
> +static struct mixer_drv_data exynos5420_mxr_drv_data = {
> + .version = MXR_VER_128_0_0_184,
> + .is_vp_enabled = 0,
> +};
> +
>  static struct mixer_drv_data exynos5250_mxr_drv_data = {
>   .version = MXR_VER_16_0_33_0,
>   .is_vp_enabled = 0,
> @@ -1139,6 +1161,9 @@ static struct platform_device_id mixer_driver_types[] = 
> {
>  
>  static struct 

[PATCH] drm: Improve manual IRQ installation documentation

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/drm.tmpl | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f9df3b8..738b727 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -186,11 +186,12 @@
   
 DRIVER_HAVE_IRQDRIVER_IRQ_SHARED
 
-  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. 
The
-  DRM core will automatically register an interrupt handler when 
the
-  flag is set. DRIVER_IRQ_SHARED indicates whether the device 
-  handler support shared IRQs (note that this is required of PCI
-  drivers).
+  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
+  managed by the DRM Core. The core will support simple IRQ handler
+  installation when the flag is set. The installation process is
+  described in .
+  DRIVER_IRQ_SHARED indicates whether the device  
handler
+  support shared IRQs (note that this is required of PCI  drivers).
 
   
   
@@ -344,7 +345,8 @@ char *date;
   The DRM core tries to facilitate IRQ handler registration and
   unregistration by providing drm_irq_install and
   drm_irq_uninstall functions. Those functions 
only
-  support a single interrupt per device.
+  support a single interrupt per device, devices that use more than one
+  IRQs need to be handled manually.
 
   
 
-- 
Regards,

Laurent Pinchart

[PATCH v4] drm: Renesas R-Car Display Unit DRM driver

[Laurent Pinchart]

The R-Car Display Unit (DU) DRM driver supports both superposition
processors and all eight planes in RGB and YUV formats with alpha
blending.

Only VGA and LVDS encoders and connectors are currently supported.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/rcar-du/Kconfig |   9 +
 drivers/gpu/drm/rcar-du/Makefile|   8 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 595 
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  50 +++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c   | 325 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  66 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 245 +
 drivers/gpu/drm/rcar-du/rcar_du_kms.h   |  59 
 drivers/gpu/drm/rcar-du/rcar_du_lvds.c  | 216 
 drivers/gpu/drm/rcar-du/rcar_du_lvds.h  |  24 ++
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 507 +++
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  67 
 drivers/gpu/drm/rcar-du/rcar_du_regs.h  | 445 
 drivers/gpu/drm/rcar-du/rcar_du_vga.c   | 149 
 drivers/gpu/drm/rcar-du/rcar_du_vga.h   |  24 ++
 include/linux/platform_data/rcar-du.h   |  54 +++
 18 files changed, 2846 insertions(+)
 create mode 100644 drivers/gpu/drm/rcar-du/Kconfig
 create mode 100644 drivers/gpu/drm/rcar-du/Makefile
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_crtc.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_drv.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_kms.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvds.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_plane.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_regs.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vga.h
 create mode 100644 include/linux/platform_data/rcar-du.h

Changes since v3:

 - Use drm_send_vblank_event()
 - Enable compilation on all ARM platforms
 - Don't add default modes to VGA connector

Changes since v2:

 - Enable the DE signal
 - Split hardware and KMS planes
 - Add support for the second CRTC
 - Name the encoder platform data union
 - Fix crash when disabling an already disabled plane
 - Prepare/unprepare clock
 - Centralize DU device core resource management
 - Reorganize CRTC start/stop and power management code
 - Create common encoder and connector structures
 - Add support for cloned mode on DU1
 - Add XRGB1555 format support
 - Add plane property to set global alpha value
 - Don't modify mode active size in encoder fixup
 - Use the mode active size in mode set
 - Take offsets into account in the mode_set_base handler
 - Fix plane source position configuration
 - Don't clean up mode setting if it hasn't been initialized
 - Enable extended range for display timings

Changes since v1:

 - Use drm_encoder_cleanup() directly as .destroy handlers
 - Enable alpha blending support
 - Don't re-reserve hardware plane at each update
 - Fix planes allocation for multiplanar formats
 - Add DRM PRIME support
 - Fix race condition between page flip request and handler
 - Add configurable z-order support for planes
 - Support configurable color keying for planes
 - Update plane format after releasing hardware planes
 - Fix register access for global registers
 - Fix plane index wrap-around for multi-planar overlays

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b16c50e..71ca63b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -213,6 +213,8 @@ source "drivers/gpu/drm/mgag200/Kconfig"

 source "drivers/gpu/drm/cirrus/Kconfig"

+source "drivers/gpu/drm/rcar-du/Kconfig"
+
 source "drivers/gpu/drm/shmobile/Kconfig"

 source "drivers/gpu/drm/omapdrm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1ecbe5b..801bcaf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_DRM_EXYNOS) +=exynos/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
+obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
new file mode 100644
index 000..72887df
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -0,0 +1,9 @@
+config DRM_RCAR_DU
+   tristate "DRM Support for R-Car Display Unit"
+   depends on DRM && ARM
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select 

exynos-drm-next todo work.

[Inki Dae]

> -Original Message-
> From: Rahul Sharma [mailto:r.sh.open at gmail.com]
> Sent: Tuesday, June 18, 2013 6:46 PM
> To: Inki Dae
> Cc: linux-samsung-soc at vger.kernel.org; DRI mailing list
> Subject: Re: exynos-drm-next todo work.
> 
> Hi Mr. Dae,
> 
> Related to HDMI sound support in Alsa, I have posted a working RFC
> "exynos-hdmi to CDF complaint display driver". It registers a separate
> sound card by registering hdmi audio codec dai and cpu-dai, as you
> mentioned. But there is a problem with this approach that I2S being the
> single cpu dai for HDMI and Speaker sound card, only one card can
> support playback at a time.
> 
> I would like to work on this to provide a more refined solution.
> 

Thanks. However, I think it's not good to use the CDF framework to interface
between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF
framework is to provide common interfaces to display bus drivers to Linux
framebuffer and DRM KMS based display controller drivers as long as I know.
So my opinion is to implement ALSA Soc DAI driver-it seems like possible to
use as is-based on a new common framework that the other can also use it.

Thanks,
Inki Dae

> regards,
> Rahul Sharma.
> 
> On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae  wrote:
> > Hi all,
> >
> > I'd like to discuss Exynos DRM TODO work.
> >
> > There are features we have to solve and implement. The purpose of this
> email
> > is to share what we have to do so that other guys can be involved
> without
> > duplicated work.
> >
> > 1. gscaler based on KMS interfaces - exynos5250 and later use the
> gscaler
> > device instead of VP device. And now exynos drm driver has gscaler
> module as
> > a sub module of IPP framework. However, this gscaler module is very
> specific
> > to IPP framework so it's not easy to reuse this module. So maybe we need
> so
> > many works for it.
> >
> > Video play back path using post process (AS IS):
> > MFCIPPKMS-FIMD or HDMI
> >
> > Ideal video play back path using post process (TO BE):
> > MFCKMSFIMD or HDMI
> >
> > The above scenario is to send decoded image data (YUV format) to display
> > device via post process. However, we don't really need to use IPP
> framework
> > in case of using gscaler as VP. All we have to do is to call kms
> interface
> > (setplane) for it like we did before.
> >
> > 2. More features for HDMI sound support - we need to implement Exynos
> ALSA
> > SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq,
> bit
> > rate, and so on from user side should be sent to drm hdmi driver via
> ALSA
> > interface and the ALSA SoC DAI driver. As of now, it seems like that we
> > should implement this driver like OMAP does because there is no common
> > framework for interfacing between ALSA SoC DAI driver and DRM HDMI
> driver:
> > in case of OMAP, it seems like that ALSA SoC audio driver calls
> interfaces
> > of DSS driver directly. I think we could implement ALSA SoC DAI driver
> in
> > more generic way if we first implement common framework for it.
> >
> > Welcome to any volunteer and other opinions.
> >
> > Thanks,
> > Inki Dae
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm/shmobile: Enable compilation on all ARM platforms

[Laurent Pinchart]

This is required to support multi-arch kernels.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/shmobile/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
index 7e7d52b..62905b4 100644
--- a/drivers/gpu/drm/shmobile/Kconfig
+++ b/drivers/gpu/drm/shmobile/Kconfig
@@ -1,6 +1,6 @@
 config DRM_SHMOBILE
tristate "DRM Support for SH Mobile"
-   depends on DRM && (SUPERH || ARCH_SHMOBILE)
+   depends on DRM && (ARM || SUPERH)
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-- 
Regards,

Laurent Pinchart

[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
> 
> > -Original Message-
> > From: Lucas Stach [mailto:l.stach at pengutronix.de]
> > Sent: Tuesday, June 18, 2013 6:47 PM
> > To: Inki Dae
> > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
> > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
> > kernel at lists.infradead.org; linux-media at vger.kernel.org
> > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> > framework
> > 
> > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
> > [...]
> > >
> > > > a display device driver.  It shouldn't be used within a single driver
> > > > as a means of passing buffers between userspace and kernel space.
> > >
> > > What I try to do is not really such ugly thing. What I try to do is to
> > > notify that, when CPU tries to access a buffer , to kernel side through
> > > dmabuf interface. So it's not really to send the buffer to kernel.
> > >
> > > Thanks,
> > > Inki Dae
> > >
> > The most basic question about why you are trying to implement this sort
> > of thing in the dma_buf framework still stands.
> > 
> > Once you imported a dma_buf into your DRM driver it's a GEM object and
> > you can and should use the native DRM ioctls to prepare/end a CPU access
> > to this BO. Then internally to your driver you can use the dma_buf
> > reservation/fence stuff to provide the necessary cross-device sync.
> > 
> 
> I don't really want that is used only for DRM drivers. We really need
> it for all other DMA devices; i.e., v4l2 based drivers. That is what I
> try to do. And my approach uses reservation to use dma-buf resources
> but not dma fence stuff anymore. However, I'm looking into Radeon DRM
> driver for why we need dma fence stuff, and how we can use it if
> needed.
> 

Still I don't see the point why you need syncpoints above dma-buf. In
both the DRM and the V4L2 world we have defined points in the API where
a buffer is allowed to change domain from device to CPU and vice versa.

In DRM if you want to access a buffer with the CPU you do a cpu_prepare.
The buffer changes back to GPU domain once you do the execbuf
validation, queue a pageflip to the buffer or similar things.

In V4L2 the syncpoints for cache operations are the queue/dequeue API
entry points. Those are also the exact points to synchronize with other
hardware thus using dma-buf reserve/fence.

In all this I can't see any need for a new syncpoint primitive slapped
on top of dma-buf.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Add support for exynos5420 mixer IP in the drm mixer driver.

Signed-off-by: Rahul Sharma 
---
 .../devicetree/bindings/video/exynos_mixer.txt |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c  |   49 +++-
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index a8b063f..c64ddc1 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsung,exynos5250-mixer"
+   3) "samsung,exynos5420-mixer"

 - reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+   MXR_VER_128_0_0_184,
 };

 struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);

-   /* choosing between porper HD and SD mode */
-   if (height <= 480)
-   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height <= 576)
-   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height <= 720)
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height <= 1080)
-   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
-   else
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+   /* choosing between proper HD and SD mode */
+   if (height <= 480)
+   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+   else if (height <= 576)
+   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+   else if (height <= 720)
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   else if (height <= 1080)
+   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+   else
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   }

mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
 }
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);

+   /* setup display size */
+   if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+   win == MIXER_DEFAULT_WIN) {
+   val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+   val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+   mixer_reg_write(res, MXR_RESOLUTION, val);
+   }
+
val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
mixer_cfg_layer(ctx, win, true);

/* layer update mandatory for mixer 16.0.33.0 */
-   if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);

mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)

 static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
 {
+   struct mixer_context *mixer_ctx = ctx;
u32 w, h;

w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);

+   if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+   mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+   return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
exynos_drm_hdmi_context *ctx,
return 0;
 }

+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+   .version = MXR_VER_128_0_0_184,
+   .is_vp_enabled = 0,
+};
+
 static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @@ static 

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Tomasz Figa]

Hi Rahul,

On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
> Hi All,
> 
> On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae  wrote:
> >> -Original Message-
> >> From: dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org
> >> [mailto:dri-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org] On
> >> Behalf Of Lucas Stach
> >> Sent: Wednesday, June 19, 2013 4:59 PM
> >> To: Tomasz Figa
> >> Cc: kgene.kim at samsung.com; devicetree-discuss at lists.ozlabs.org;
> >> sw0312.kim at samsung.com; joshi at samsung.com;
> > 
> > dri-devel at lists.freedesktop.org;
> > 
> >> linux-samsung-soc at vger.kernel.org; rob.herring at calxeda.com;
> >> s.nawrocki at samsung.com; grant.likely at linaro.org; Rahul Sharma
> >> Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
> >> subsystem
> >> 
> >> Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> >> > Hi Rahul,
> >> > 
> >> > On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> >> > > This patch renames the combatible strings for hdmi, mixer, ddc
> >> > > and hdmiphy. It follows the convention of using compatible string
> >> > > which represent the SoC in which the IP was added for the first
> >> > > time.
> >> > > 
> >> > > Signed-off-by: Rahul Sharma 
> >> > > ---
> >> > > 
> >> > >  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> >> > > 
> >> > > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
> >> > > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
> >> > > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
> >> > > 
> >> > >  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
> >> > >  
> >> > >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
> >> > > 
> >> > > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|   
> >> > > 4
> >> > > +++- drivers/gpu/drm/exynos/exynos_mixer.c  |  
> >> > > 12
> >> > > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> >> > > 
> >> > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> >> > > 589edee..2ac01ca 100644
> >> > > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> >> > > @@ -1,7 +1,9 @@
> >> > > 
> >> > >  Device-Tree bindings for drm hdmi driver
> >> > > 
> >> > >  Required properties:
> >> > > -- compatible: value should be "samsung,exynos5-hdmi".
> >> > > +- compatible: value should be one among the following:
> >> > > + 1) "samsung,exynos4210-hdmi"
> >> > > + 2) "samsung,exynos4212-hdmi"
> >> > > 
> >> > >  - reg: physical base address of the hdmi and length of memory mapped
> >> > >  
> >> > >   region.
> >> > >  
> >> > >  - interrupts: interrupt number to the cpu.
> >> > > 
> >> > > @@ -15,7 +17,7 @@ Required properties:
> >> > >  Example:
> >> > >   hdmi {
> >> > > 
> >> > > - compatible = "samsung,exynos5-hdmi";
> >> > > + compatible = "samsung,exynos4212-hdmi";
> >> > 
> >> > Sorry, but it's a NAK from me.
> >> > 
> >> > DeviceTree bindings are considered an ABI. This is to allow older dtbs
> >> 
> >> to
> >> 
> >> > work with new kernels.
> >> > 
> >> > If you just change the binding this way, you break all the existing
> >> 
> >> users
> >> 
> >> > of this compatible value.
> >> > 
> >> > In addition you are doing it in a way that breaks bisection:
> >> >  - patch 1/4 breaks existing in-tree users of current compatible
> >> >  values,
> >> >  - after patch 2 and 3 it is still broken,
> >> >  - and eventually all in-tree users are fixed by patch 4 (but you can't
> >> > 
> >> > fix out-of-tree users).
> 
> @Tomasz, I understand your point but how is it possible to change
> compatible types in driver as well as in dtbs by not breaking either of them
> other then putting changes in a single patch.

It's very easy. (Let's forget about the fact that DT bindings are an ABI 
temporarily) You can simply add new compatible values to the driver in first 
patch, then modify dts files in second one and then remove old compatibles 
values from the driver in third patch. (Now we remember about DT being ABI 
again.)

> I ensured that hdmi stuff is
> intact with whole series merged in either tree (drm or arch). Please
> suggest a better way.
> 
> The Only existing user is Exynos5250, which is modified in the same patch
> set.

This is not true. You have modified only the existing _in_ _tree_ users.

Keep in mind that device tree is not a part of the kernel. It is currently 
located in the same tree, but it is _not_ a part of the kernel.

Now think about existing boards (like exynos5250-snow) that have a dtb built 
from older dts sources stored in their flash memory. You need to maintain 
compatibilty with this old dtb in new kernels as well.

> >> > Please do it without changing existing compatible values. Even if they
> >> 
> >> 

[PATCH] drm/prime: Honor requested file flags when exporting a buffer

[Dave Airlie]

On Wed, Jun 19, 2013 at 11:14 AM, Laurent Pinchart
 wrote:
> The DRM PRIME API passes file flags to the driver for the exported
> buffer. Honor them instead of hardcoding 0600.
>
> Signed-off-by: Laurent Pinchart 

(this time keeping cc's).

Pushed to drm-fixes.

thanks for noticing/fixing

Dave.

[PATCH 4/4] drm: Constify the pretty-print functions

[Dave Airlie]

On Wed, Jun 19, 2013 at 10:53 AM, Laurent Pinchart
 wrote:
> Hi Ville,
>
> On Friday 07 June 2013 18:43:07 ville.syrjala at linux.intel.com wrote:
>> From: Ville Syrj?l? 
>>
>> The structures and strings involved with various pretty-print functions
>> aren't meant to be modified, so make them all const. The exception is
>> drm_connector_enum_list which does get modified in drm_connector_init().
>>
>> While at it move the drm_get_connector_status_name() prototype from
>> drmP.h to drm_crtc.h where it belongs.
>
> This breaks compilation on drm-next:
>
> drivers/gpu/drm/drm_fb_helper.c: In function
> ?drm_fb_helper_parse_command_line?:
> drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of
> ?fb_get_options? discards ?const? qualifier from pointer target type [enabled
> by default]
> In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
> include/linux/fb.h:627:12: note: expected ?char *? but argument is of type
> ?const char

The fix is in the fbdev tree, which appears not to be in -next, fail.

Dave.

[PATCH 2/4] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Sure Seung-Woo,

I will update binding document along with this patch.

regards,
Rahul Sharma.

On Wed, Jun 19, 2013 at 10:54 AM, ???  wrote:
> Hi Rahul,
>
> Code part looks good to me but IMHO, binding document for exynos_mixer
> is also fixed like following because compitable string
> samsung,exynos5420-mixer is added with this patch.
>
>  Required properties:
>  - compatible: value should be:
> 1) "samsung,exynos4210-mixer"
> 2) "samsung,exynos5250-mixer"
> +   3) "samsung,exynos5420-mixer"
>
> Thanks and Regards,
> - Seung-Woo Kim
>
> On 2013? 06? 18? 21:49, Rahul Sharma wrote:
>> Add support for exynos5420 mixer IP in the drm mixer driver.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  drivers/gpu/drm/exynos/exynos_mixer.c |   49 
>> +
>>  drivers/gpu/drm/exynos/regs-mixer.h   |7 +
>>  2 files changed, 44 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 2fe6d33..d51ff36 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -78,6 +78,7 @@ struct mixer_resources {
>>  enum mixer_version_id {
>>   MXR_VER_0_0_0_16,
>>   MXR_VER_16_0_33_0,
>> + MXR_VER_128_0_0_184,
>>  };
>>
>>  struct mixer_context {
>> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
>> unsigned int height)
>>   val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
>>   MXR_CFG_SCAN_PROGRASSIVE);
>>
>> - /* choosing between porper HD and SD mode */
>> - if (height <= 480)
>> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
>> - else if (height <= 576)
>> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
>> - else if (height <= 720)
>> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> - else if (height <= 1080)
>> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
>> - else
>> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
>> + /* choosing between proper HD and SD mode */
>> + if (height <= 480)
>> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
>> + else if (height <= 576)
>> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
>> + else if (height <= 720)
>> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + else if (height <= 1080)
>> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
>> + else
>> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + }
>>
>>   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>>  }
>> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx, int win)
>>   /* setup geometry */
>>   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>>
>> + /* setup display size */
>> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
>> + win == MIXER_DEFAULT_WIN) {
>> + val  = MXR_MXR_RES_HEIGHT(win_data->fb_height);
>> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
>> + mixer_reg_write(res, MXR_RESOLUTION, val);
>> + }
>> +
>>   val  = MXR_GRP_WH_WIDTH(win_data->crtc_width);
>>   val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
>>   val |= MXR_GRP_WH_H_SCALE(x_ratio);
>> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context 
>> *ctx, int win)
>>   mixer_cfg_layer(ctx, win, true);
>>
>>   /* layer update mandatory for mixer 16.0.33.0 */
>> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
>> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>> + ctx->mxr_ver == MXR_VER_128_0_0_184)
>>   mixer_layer_update(ctx);
>>
>>   mixer_run(ctx);
>> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>>
>>  static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
>>  {
>> + struct mixer_context *mixer_ctx = ctx;
>>   u32 w, h;
>>
>>   w = mode->hdisplay;
>> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
>> drm_display_mode *mode)
>>   mode->hdisplay, mode->vdisplay, mode->vrefresh,
>>   (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>>
>> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
>> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
>> + return 0;
>> +
>>   if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>>   (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>>   (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
>> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
>> exynos_drm_hdmi_context *ctx,
>>   return 0;
>>  }
>>
>> +static struct mixer_drv_data exynos5420_mxr_drv_data = {
>> + .version = MXR_VER_128_0_0_184,
>> + 

[PATCH 1/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.

[J L]

On 13-06-17 09:19 AM, Julia Lemire wrote:
> +static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode * 
> mode,
> +   int bits_per_pixel)
> +{
> +   uint64_t active_area, total_area, pixels_per_second;
> +   uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
> +
> +   if(!mode->htotal || !mode->vtotal || !mode->clock)
> +   return 0;
> +
> +   active_area = mode->hdisplay * mode->vdisplay;
> +   total_area = mode->htotal * mode->vtotal;
> +   pixels_per_second = active_area * mode->clock * 1000 / total_area;
> +   return (uint32_t)(pixels_per_second * bytes_per_pixel * 100 / (1024));
> +}
I found a bug while testing this on a 32-bit machine linked to the 
64-bit division.  Sorry.

-- 
Julia Lemire Jr. Eng./Ing.
Software Designer
Matrox Graphics Inc.
Phone : 514 822-6000 x7010
Email :julia.lemire at matrox.com

[PATCH 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality

[Joonyoung Shim]

On 06/19/2013 08:02 AM, Laurent Pinchart wrote:
> Hi Joonyoung,
>
> On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
>> Hi,
>>
>> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
>> dma_buf. We can use prime helpers for dma_buf by commit
>> 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so
>> this patchset is to replace from using GEM CMA specific functions to
>> using prime helpers.
> Overall this looks good to me, except the that prime helpers don't cache
> mappings, unlike the current implementation in the GEM CMA helpers. Could that
> be fixed in the prime helpers first ?

Right, i will update it first.

Thanks.

[PATCH] drm/radeon: update lockup tracking when scheduling in empty ring

[j.gli...@gmail.com]

From: Jerome Glisse 

There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.

Signed-off-by: Jerome Glisse 
Tested-by: Andy Lutomirski 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index e17faa7..82434018 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct 
radeon_ring *ring, unsi
return -ENOMEM;
/* Align requested size with padding so unlock_commit can
 * pad safely */
+   radeon_ring_free_size(rdev, ring);
+   if (ring->ring_free_dw == (ring->ring_size / 4)) {
+   /* This is an empty ring update lockup info to avoid
+* false positive.
+*/
+   radeon_ring_lockup_update(ring);
+   }
ndw = (ndw + ring->align_mask) & ~ring->align_mask;
while (ndw > (ring->ring_free_dw - 1)) {
radeon_ring_free_size(rdev, ring);
-- 
1.7.11.7

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Lucas Stach]

Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
> Hi Rahul,
> 
> On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> > This patch renames the combatible strings for hdmi, mixer, ddc
> > and hdmiphy. It follows the convention of using compatible string
> > which represent the SoC in which the IP was added for the first
> > time.
> > 
> > Signed-off-by: Rahul Sharma 
> > ---
> >  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> > -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |   
> > 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |   
> > 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |  
> >  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
> >2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |   
> > 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> > +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
> > ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> > 589edee..2ac01ca 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> > @@ -1,7 +1,9 @@
> >  Device-Tree bindings for drm hdmi driver
> > 
> >  Required properties:
> > -- compatible: value should be "samsung,exynos5-hdmi".
> > +- compatible: value should be one among the following:
> > +   1) "samsung,exynos4210-hdmi"
> > +   2) "samsung,exynos4212-hdmi"
> >  - reg: physical base address of the hdmi and length of memory mapped
> > region.
> >  - interrupts: interrupt number to the cpu.
> > @@ -15,7 +17,7 @@ Required properties:
> >  Example:
> > 
> > hdmi {
> > -   compatible = "samsung,exynos5-hdmi";
> > +   compatible = "samsung,exynos4212-hdmi";
> 
> Sorry, but it's a NAK from me.
> 
> DeviceTree bindings are considered an ABI. This is to allow older dtbs to 
> work with new kernels.
> 
> If you just change the binding this way, you break all the existing users 
> of this compatible value.
> 
> In addition you are doing it in a way that breaks bisection:
>  - patch 1/4 breaks existing in-tree users of current compatible values,
>  - after patch 2 and 3 it is still broken,
>  - and eventually all in-tree users are fixed by patch 4 (but you can't 
> fix out-of-tree users).
> 
> Please do it without changing existing compatible values. Even if they are 
> misleading, this is all can be described in the documentation - just list 
> SoCs that can be used with each compatible value there.
> 

Or you could just introduce the new compatible value and make all
in-tree users use this, but keep the old values around and still accept
them in the drivers. This way you get the goodness of the cleaner new
symbols without breaking existing users. Just mark the old values as
deprecated in the documentation, so no new devicetree usees them.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Tomasz Figa]

Hi Rahul,

On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
> 
> Signed-off-by: Rahul Sharma 
> ---
>  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
> -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |   
> 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |   
> 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |  
>  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
>2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |   
> 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
> +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
> ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
> 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
>  Device-Tree bindings for drm hdmi driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
>  - reg: physical base address of the hdmi and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
>  Example:
> 
>   hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";

Sorry, but it's a NAK from me.

DeviceTree bindings are considered an ABI. This is to allow older dtbs to 
work with new kernels.

If you just change the binding this way, you break all the existing users 
of this compatible value.

In addition you are doing it in a way that breaks bisection:
 - patch 1/4 breaks existing in-tree users of current compatible values,
 - after patch 2 and 3 it is still broken,
 - and eventually all in-tree users are fixed by patch 4 (but you can't 
fix out-of-tree users).

Please do it without changing existing compatible values. Even if they are 
misleading, this is all can be described in the documentation - just list 
SoCs that can be used with each compatible value there.

Best regards,
Tomasz

>   reg = <0x1453 0x10>;
>   interrupts = <0 95 0>;
>   hpd-gpio = < 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt index
> fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
>  Device-Tree bindings for hdmiddc driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
>  - reg: I2C address of the hdmiddc device.
> 
>  Example:
> 
>   hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
>   reg = <0x50>;
>   };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt index
> 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
>  Device-Tree bindings for hdmiphy driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
>  - reg: I2C address of the hdmiphy device.
> 
>  Example:
> 
>   hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
>   reg = <0x38>;
>   };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt index
> 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
>  Device-Tree bindings for mixer driver
> 
>  Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
>  - reg: physical base address of the mixer and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required 

[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem

[Rahul Sharma]

+ mike

On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma  
wrote:
> Add clock changes for hdmi subsystem for exynos5250 SoC. These
> include addition of new clocks like mout_hdmi and smmu_tv, associating
> ID to clk_hdmiphy and some essential corrections.
>
> This set is based on kukjin's for-next branch at
> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
>
> This set dependents on the following patches which add support for Exynos5420
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19264.html
>
> Rahul Sharma (5):
>   clk/exynos5420: add sclk_hdmiphy to the list of special clocks
>   clk/exynos5420: add gate clock for tv sysmmu
>   clk/exynos5420: fix the order of parents of hdmi mux
>   clk/exynos5420: add hdmi mux to change parents in hdmi driver
>   clk/exynos5420: assign sclk_pixel id to pixel clock divider
>
>  .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
>  drivers/clk/samsung/clk-exynos5420.c |   18 
> +++---
>  2 files changed, 18 insertions(+), 7 deletions(-)
>
> --
> 1.7.10.4
>

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #72 from Marc Dietrich  ---
yup, heaven works, kronos test suite reports doesn't crash anymore, but fail
(misrenders) on sin/cos as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/cc4c06e3/attachment.html>

[PATCH] drm/prime: Honor requested file flags when exporting a buffer

[Laurent Pinchart]

The DRM PRIME API passes file flags to the driver for the exported
buffer. Honor them instead of hardcoding 0600.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_prime.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..e57c675 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -210,8 +210,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj, int flags)
 {
-   return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
-0600);
+   return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size, flags);
 }
 EXPORT_SYMBOL(drm_gem_prime_export);

-- 
Regards,

Laurent Pinchart

[PATCH v2] drm: Remove some unused stuff from drm_plane

[Laurent Pinchart]

Hello,

On Wednesday 08 May 2013 15:52:10 Laurent Pinchart wrote:
> On Wednesday 08 May 2013 16:40:54 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l? 
> > 
> > There's a bunch of unused members inside drm_plane, bloating the size of
> > the structure needlessly. Eliminate them.
> > 
> > v2: Remove all of it from kernel-doc too
> > 
> > Signed-off-by: Ville Syrj?l? 
> 
> Reviewed-by: Laurent Pinchart 

Wow, I've managed to review the patch and miss that it broke compilation of 
the shmob-drm driver :-( I'll send a patch to fix it.

> > ---
> > 
> >  drivers/gpu/drm/drm_crtc.c |  2 +-
> >  include/drm/drm_crtc.h | 11 ---
> >  2 files changed, 1 insertion(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d7c449f..e591914 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1739,7 +1739,7 @@ int drm_mode_getplane(struct drm_device *dev, void
> > *data,
> > 
> > plane_resp->plane_id = plane->base.id;
> > plane_resp->possible_crtcs = plane->possible_crtcs;
> > 
> > -   plane_resp->gamma_size = plane->gamma_size;
> > +   plane_resp->gamma_size = 0;
> > 
> > /*
> > 
> >  * This ioctl is called twice, once to determine how much space is
> > 
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index adb3f9b..e11c6bc 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -654,11 +654,7 @@ struct drm_plane_funcs {
> >   * @format_count: number of formats supported
> >   * @crtc: currently bound CRTC
> >   * @fb: currently bound fb
> > - * @gamma_size: size of gamma table
> > - * @gamma_store: gamma correction table
> > - * @enabled: enabled flag
> >   * @funcs: helper functions
> > - * @helper_private: storage for drver layer
> >   * @properties: property tracking for this plane
> >   */
> >  
> >  struct drm_plane {
> > @@ -674,14 +670,7 @@ struct drm_plane {
> > struct drm_crtc *crtc;
> > struct drm_framebuffer *fb;
> > 
> > -   /* CRTC gamma size for reporting to userspace */
> > -   uint32_t gamma_size;
> > -   uint16_t *gamma_store;
> > -
> > -   bool enabled;
> > -
> > const struct drm_plane_funcs *funcs;
> > -   void *helper_private;
> > 
> > struct drm_object_properties properties;
> >  };
-- 
Regards,

Laurent Pinchart

[PATCH 4/4] drm: Constify the pretty-print functions

[Laurent Pinchart]

Hi Ville,

On Friday 07 June 2013 18:43:07 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modified in drm_connector_init().
> 
> While at it move the drm_get_connector_status_name() prototype from
> drmP.h to drm_crtc.h where it belongs.

This breaks compilation on drm-next:

drivers/gpu/drm/drm_fb_helper.c: In function 
?drm_fb_helper_parse_command_line?:
drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of 
?fb_get_options? discards ?const? qualifier from pointer target type [enabled 
by default]
In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
include/linux/fb.h:627:12: note: expected ?char *? but argument is of type 
?const char 

> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/drm_crtc.c | 30 +++---
>  include/drm/drmP.h |  1 -
>  include/drm/drm_crtc.h | 17 +
>  3 files changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 079996a..44c3421 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
> 
>  /* Avoid boilerplate.  I'm tired of typing. */
>  #define DRM_ENUM_NAME_FN(fnname, list)   \
> - char *fnname(int val)   \
> + const char *fnname(int val) \
>   {   \
>   int i;  \
>   for (i = 0; i < ARRAY_SIZE(list); i++) {\
> @@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
>  /*
>   * Global properties
>   */
> -static struct drm_prop_enum_list drm_dpms_enum_list[] =
> +static const struct drm_prop_enum_list drm_dpms_enum_list[] =
>  {{ DRM_MODE_DPMS_ON, "On" },
>   { DRM_MODE_DPMS_STANDBY, "Standby" },
>   { DRM_MODE_DPMS_SUSPEND, "Suspend" },
> @@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>  /*
>   * Optional properties
>   */
> -static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
>  {
>   { DRM_MODE_SCALE_NONE, "None" },
>   { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> @@ -125,7 +125,7 @@ static struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] = { DRM_MODE_SCALE_ASPECT, "Full aspect" },
>  };
> 
> -static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
>  {
>   { DRM_MODE_DITHERING_OFF, "Off" },
>   { DRM_MODE_DITHERING_ON, "On" },
> @@ -135,7 +135,7 @@ static struct drm_prop_enum_list
> drm_dithering_mode_enum_list[] = /*
>   * Non-global properties, but "required" for certain connectors.
>   */
> -static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
>  {
>   { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
>   { DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
> @@ -144,7 +144,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] =
> 
>  DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
> 
> -static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> {
>   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I and TV-out */
>   { DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
> @@ -154,7 +154,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
>drm_dvi_i_subconnector_enum_list)
> 
> -static struct drm_prop_enum_list drm_tv_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
>  {
>   { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
>   { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -165,7 +165,7 @@ static struct drm_prop_enum_list
> drm_tv_select_enum_list[] =
> 
>  DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
> 
> -static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
>  {
>   { DRM_MODE_SUBCONNECTOR_Unknown,   "Unknown"   }, /* DVI-I and TV-out */
>   { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -177,7 +177,7 @@ static struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
> 

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64913

--- Comment #13 from Krzysztof A. Sobiecki  ---
Is someone interested in this patch?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130619/91653786/attachment.html>

[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem

[Kukjin Kim]

On 06/18/13 14:09, Rahul Sharma wrote:
> Hi Mr. Kukjin,
>
> Kindly consider the following patches for review and integration.
>
(+ Mike)

Rahul, basically, looks good to me but I'm waiting for Mike's ack on 
this series...

> regards,
> Rahul Sharma.
>
> On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K  
> wrote:
>> Hi,
>> Tested this series on snow board and is working fine.
>>
>> Tested-by: Arun Kumar K
>>
Arun, thanks for your test.

- Kukjin

>> Regards
>> Arun
>>
>> On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma  
>> wrote:
>>> Add clock changes for hdmi subsystem for exynos5250 SoC. These
>>> include addition of new clocks like mout_hdmi and smmu_tv, associating
>>> ID to clk_hdmiphy and some essential corrections.
>>>
>>> This set is based on kukjin's for-next branch at
>>> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.
>>>
>>> Arun Kumar K (1):
>>>clk/exynos5250: Fix HDMI clock number in documentation
>>>
>>> Rahul Sharma (4):
>>>clk/exynos5250: add mout_hdmi mux clock for hdmi
>>>clk/exynos5250: add sclk_hdmiphy in the list of special clocks
>>>clk/exynos5250: add clock for tv sysmmu
>>>clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem
>>>
>>>   .../devicetree/bindings/clock/exynos5250-clock.txt   |   12 +++-
>>>   drivers/clk/samsung/clk-exynos5250.c |   18 
>>> +-
>>>   2 files changed, 24 insertions(+), 6 deletions(-)

[PATCH v3] drm: Renesas R-Car Display Unit DRM driver

[Laurent Pinchart]

Hello Adam,

Ping ?

Daniel, would it help getting the driver in v3.11 if I resubmit it now with a 
get_modes operation that just returns 0 ?

On Friday 14 June 2013 16:03:19 Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 02:54:04AM +0200, Laurent Pinchart wrote:
> > On Friday 07 June 2013 10:50:55 Daniel Vetter wrote:
> > > On Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> > > > On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > > > > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > > > > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > > > > > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > > > > > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > > > > > > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart 
wrote:
> > > > > [snip]
> > > > > 
> > > > > > > >> > +static int rcar_du_vga_connector_get_modes(struct
> > > > > > > >> > drm_connector
> > > > > > > >> > *connector)
> > > > > > > >> > +{
> > > > > > > >> > +   return drm_add_modes_noedid(connector, 1280, 768);
> > > > > > > >> > +}
> > > > > > > >> 
> > > > > > > >> This (and the dummy detect function below) looks a bit funny,
> > > > > > > >> since it essentially overrides the default behaviour already
> > > > > > > >> provided by the crtc helpers. Until rcar has at least proper
> > > > > > > >> detect support for VGA
> > > > > > > > 
> > > > > > > > I would add that but the DDC signals are not connected on the
> > > > > > > > boards I have access to :-/
> > > > > > > > 
> > > > > > > >> I'd just kill this and use the connector force support (and
> > > > > > > >> manually adding the right resolutions).
> > > > > > > > 
> > > > > > > > Looks like that's a candidate for better documentation... How
> > > > > > > > does force support work ?
> > > > > > > 
> > > > > > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline,
> > > > > > > where you can also force a specific mode. The best I could find
> > > > > > > wrt docs is the kerneldoc for
> > > > > > > drm_mode_parse_command_line_for_connector. With a bit more
> > > > > > > reading it looks like it's intermingled with the fbdev helper
> > > > > > > code, but should be fairly easy to extract and used by your
> > > > > > > driver.
> > > > > > 
> > > > > > It makes sense to force the connector state from command line, but
> > > > > > I'm not sure if the same mechanism is the best solution here. As
> > > > > > the driver has no way to know the connector state, the best we can
> > > > > > do is guess what modes are supported. I can just return 0 in the
> > > > > > get_modes handler, but then the core will not call
> > > > > > drm_add_modes_noedid(), and modes will need to be added manually.
> > > > > > 
> > > > > > Is your point that for a board on which the VGA connector state
> > > > > > can't be detected, the user should always be responsible for
> > > > > > adding all the modes supported by the VGA monitor on the command
> > > > > > line ?
> > > > > 
> > > > > My point is that we already have both an established code for
> > > > > connected outputs without EDID to add fallback modes and means to
> > > > > force connectors to certain states. Your code here seems to reinvent
> > > > > that wheel, so I wonder what we should/need to improve in the common
> > > > > code to suit your needs.
> > > > 
> > > > The currently available code might suit my needs, it might just be
> > > > that I fail to see how to use it properly.
> > > > 
> > > > Regarding the "code for connected outputs without EDID to add fallback
> > > > modes" you're referring to, is that
> > > > 
> > > > if (count == 0 && connector->status ==
> > > > connector_status_connected)
> > > > count = drm_add_modes_noedid(connector, 1024, 768);
> > > > 
> > > > in drm_helper_probe_single_connector_modes() ? That function will only
> > > > be called if the connector status is connector_status_connected. There
> > > > are two ways to enforce that:
> > > > 
> > > > - returning connector_status_connected from the connector detect()
> > > > operation, which seems to defeat the purpose of having
> > > > connector_status_unknown completely.
> > > 
> > > We might want to add such a default mode also for unknown, I'm not sure.
> > > Userspace policy is to first try to light up any connected outputs, and
> > > if> there's none try to light up any unknown outputs. Not sure whether
> > > userspace (i.e. X) will automatically add a default mode. fbcon might
> > > also handle this less gracefully.
> > > 
> > > Personally I'm ok with extending this to unknown, it shouldn't really
> > > hurt (since we already try really hard not to leak unknown anywhere
> > > visible).
> > 
> > Do you mean something like
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> > b/drivers/gpu/drm/drm_crtc_helper.c index f554516..9aae384 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -160,7 

[PATCH v3 1/3] drm: add prime helpers

[Laurent Pinchart]

Hi Aaron,

On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
> On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
> > Hi Aaron,
> > 
> > A bit late, but here's a small question.
> > 
> > On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
> >> Instead of reimplementing all of the dma_buf functionality in every
> >> driver, create helpers drm_prime_import and drm_prime_export that
> >> implement them in terms of new, lower-level hook functions:
> >> gem_prime_pin: callback when a buffer is created, used to pin buffers
> >> into 
> >> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
> >> export gem_prime_import_sg_table: convert an sg_table into a
> >> drm_gem_object
> >> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
> >> 
> >> These hooks are optional; drivers can opt in by using
> >> drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
> >> and .gem_prime_export fields of struct drm_driver.
> >> 
> >> v2:
> >> - Drop .begin_cpu_access.  None of the drivers this code replaces
> >> implemented it.  Having it here was a leftover from when I was trying to
> >> include i915 in this rework.
> >> - Use mutex_lock instead of mutex_lock_interruptible, as these three
> >> drivers did.  This patch series shouldn't change that behavior.
> >> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
> >> 
> >>Rename struct sg_table* variables to 'sgt' for clarity.
> >> 
> >> - Update drm.tmpl for these new hooks.
> >> 
> >> v3:
> >> - Pass the vaddr down to the driver.  This lets drivers that just call
> >> vunmap on the pointer avoid having to store the pointer in their GEM
> >> private structures. - Move documentation into a /** DOC */ comment in
> >> drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
> >> lines to include documentation of the individual functions from drmP.h,
> >> but
> >> the docproc / kernel-doc scripts barf on that file, so hopefully this is
> >> good enough for now.
> >> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
> >> 
> >>("drm/prime: drop reference on imported dma-buf come from gem")
> >> 
> >> Signed-off-by: Aaron Plattner 
> >> Cc: Daniel Vetter 
> >> Cc: David Airlie 
> >> ---
> >> 
> >>   Documentation/DocBook/drm.tmpl |   4 +
> >>   drivers/gpu/drm/drm_prime.c| 186
> >>   +-
> >>   include/drm/drmP.h |  12 +++
> >>   3 files changed, 201 insertions(+), 1 deletion(-)
> > 
> > [snip]
> > 
> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >> index 7f12573..366910d 100644
> >> --- a/drivers/gpu/drm/drm_prime.c
> >> +++ b/drivers/gpu/drm/drm_prime.c
> > 
> > [snip]
> > 
> >> +/**
> >> + * DOC: PRIME Helpers
> >> + *
> >> + * Drivers can implement @gem_prime_export and @gem_prime_import in
> >> terms
> >> of + * simpler APIs by using the helper functions @drm_gem_prime_export
> >> and
> >> + * @drm_gem_prime_import.  These functions implement dma-buf support in
> >> terms of + * five lower-level driver callbacks:
> >> + *
> >> + * Export callbacks:
> >> + *
> >> + *  - @gem_prime_pin (optional): prepare a GEM object for exporting
> >> + *
> >> + *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
> >> pages + *
> >> + *  - @gem_prime_vmap: vmap a buffer exported by your driver
> >> + *
> >> + *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
> >> + *
> >> + * Import callback:
> >> + *
> >> + *  - @gem_prime_import_sg_table (import): produce a GEM object from
> >> another + *driver's scatter/gather table
> >> + */
> >> +
> >> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> >> +   struct drm_gem_object *obj, int flags)
> >> +{
> >> +  if (dev->driver->gem_prime_pin) {
> >> +  int ret = dev->driver->gem_prime_pin(obj);
> >> +  if (ret)
> >> +  return ERR_PTR(ret);
> >> +  }
> >> +  return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
> >> +0600);
> > 
> > Why do you use 0600 instead of the flags passed by the caller ?
> 
> Because I copied & pasted it from i915_gem_prime_export prior to commit
> 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
> pointed it out just now.

That's a pretty valid reason I guess :-) Should I submit a patch or are you 
already working on one ?

> >> +}
> >> +EXPORT_SYMBOL(drm_gem_prime_export);

-- 
Regards,

Laurent Pinchart

[PATCH v3 1/3] drm: add prime helpers

[Laurent Pinchart]

Hi Aaron,

A bit late, but here's a small question.

On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
> 
>   gem_prime_pin: callback when a buffer is created, used to pin buffers into
> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
> export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
> 
> These hooks are optional; drivers can opt in by using drm_gem_prime_import
> and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
> fields of struct drm_driver.
> 
> v2:
> - Drop .begin_cpu_access.  None of the drivers this code replaces
> implemented it.  Having it here was a leftover from when I was trying to
> include i915 in this rework.
> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
> did.  This patch series shouldn't change that behavior.
> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
>   Rename struct sg_table* variables to 'sgt' for clarity.
> - Update drm.tmpl for these new hooks.
> 
> v3:
> - Pass the vaddr down to the driver.  This lets drivers that just call
> vunmap on the pointer avoid having to store the pointer in their GEM
> private structures. - Move documentation into a /** DOC */ comment in
> drm_prime.c and include it in drm.tmpl with a !P line.  I tried to use !F
> lines to include documentation of the individual functions from drmP.h, but
> the docproc / kernel-doc scripts barf on that file, so hopefully this is
> good enough for now.
> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
>   ("drm/prime: drop reference on imported dma-buf come from gem")
> 
> Signed-off-by: Aaron Plattner 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
>  Documentation/DocBook/drm.tmpl |   4 +
>  drivers/gpu/drm/drm_prime.c| 186 +-
>  include/drm/drmP.h |  12 +++
>  3 files changed, 201 insertions(+), 1 deletion(-)

[snip]

> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7f12573..366910d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c

[snip]

> +/**
> + * DOC: PRIME Helpers
> + *
> + * Drivers can implement @gem_prime_export and @gem_prime_import in terms
> of + * simpler APIs by using the helper functions @drm_gem_prime_export and
> + * @drm_gem_prime_import.  These functions implement dma-buf support in
> terms of + * five lower-level driver callbacks:
> + *
> + * Export callbacks:
> + *
> + *  - @gem_prime_pin (optional): prepare a GEM object for exporting
> + *
> + *  - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
> pages + *
> + *  - @gem_prime_vmap: vmap a buffer exported by your driver
> + *
> + *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
> + *
> + * Import callback:
> + *
> + *  - @gem_prime_import_sg_table (import): produce a GEM object from
> another + *driver's scatter/gather table
> + */
> +
> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> +  struct drm_gem_object *obj, int flags)
> +{
> + if (dev->driver->gem_prime_pin) {
> + int ret = dev->driver->gem_prime_pin(obj);
> + if (ret)
> + return ERR_PTR(ret);
> + }
> + return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
> +   0600);

Why do you use 0600 instead of the flags passed by the caller ?

> +}
> +EXPORT_SYMBOL(drm_gem_prime_export);

-- 
Regards,

Laurent Pinchart

[PATCH 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality

[Laurent Pinchart]

Hi Joonyoung,

On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote:
> Hi,
> 
> GEM CMA supports dma_buf but it needs GEM CMA specific functionality for
> dma_buf. We can use prime helpers for dma_buf by commit
> 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so
> this patchset is to replace from using GEM CMA specific functions to
> using prime helpers.

Overall this looks good to me, except the that prime helpers don't cache 
mappings, unlike the current implementation in the GEM CMA helpers. Could that 
be fixed in the prime helpers first ?

> Thanks.
> 
> Joonyoung Shim (3):
>drm: add mmap function to prime helpers
>drm/cma: add low-level hook functions to use prime helpers
>drm/cma: remove GEM CMA specific dma_buf functionality
> 
>   drivers/gpu/drm/drm_gem_cma_helper.c | 291 ---
>   drivers/gpu/drm/drm_prime.c  |   5 +-
>   include/drm/drmP.h   |   2 +
>   include/drm/drm_gem_cma_helper.h |  13 +-
>   4 files changed, 56 insertions(+), 255 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH] drm: Avoid forcing a detection cycle following a hotplug event

[Laurent Pinchart]

Hi Chris,

On Saturday 08 June 2013 08:53:30 Chris Wilson wrote:
> On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote:
> > Could you please also update Documentation/DocBook/drm.tmpl ?
> 
> It looks out of context there, as nothing explains the hotplug ->
> fill_modes -> probe -> detect loop...

Sorry, I should have been more precise. You patches changes the prototype of 
the fill_modes() operation and the drm_helper_probe_single_connector_modes() 
function, documented in drm.tmpl. I'd like to keep the documentation in sync.

> 
> How about:
> 
>   Modes
>   int (*fill_modes)(struct drm_connector *connector, uint32_t
> max_width, uint32_t max_height, bool force);
>   
> Fill the mode list with all supported modes for the connector. If the
> max_width and max_height
> arguments are non-zero, the implementation must ignore all modes wider
> than max_width or higher than
> max_height. The driver may use the existing
> connector status, unless force is passed. During
> a hotplug event, the driver may already have updated its knowledge of the
> output and so may simply refresh the modes list from the information it
> acquired whilst handling the event. However, the caller may explicitly
> request that any cached information be dropped, and for the output to be
> queried for its current status and modes - under such circumstances
> force is true.
>   

That looks good to me (I would split this in two paragraphs, but that's just 
nitpicking).

Could you please also update the drm_helper_probe_single_connector_modes() 
description in drm.tmpl ?

-- 
Regards,

Laurent Pinchart

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #71 from Andy Furniss  ---
(In reply to comment #70)

> Andy, does current master work on your rv790 and Unigine ?

Yes, Heaven 3.0 is working for me on master.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

RE: [PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420

[Inki Dae]

Applied.

Thanks,
Inki Dae

 -Original Message-
 From: 김승우 [mailto:sw0312@samsung.com]
 Sent: Wednesday, June 19, 2013 2:34 PM
 To: Rahul Sharma
 Cc: linux-samsung-...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org;
 dri-devel@lists.freedesktop.org; kgene@samsung.com;
 inki@samsung.com; jo...@samsung.com; r.sh.o...@gmail.com; Seung-Woo
 Kim
 Subject: Re: [PATCH 3/4] drm/exynos: fix interlace resolutions for
 exynos5420
 
 Hi Rahul,
 
 This patch looks good to me.
 
 On 2013년 06월 18일 21:49, Rahul Sharma wrote:
  Modified code for calculating hdmi IP register values from drm timing
  values. The modification is based on the inputs from hw team and
 specifically
  proposed for 1440x576i and 1440x480i. But same changes holds good for
 other
  interlaced resolutions also.
 
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 
 Acked-by: Seung-Woo Kim sw0312@samsung.com
 
  ---
   drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
   1 file changed, 8 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
  index 8752171..2f807d5 100644
  --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
  +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
  @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
 *hdata,
  (m-vsync_start - m-vdisplay) / 2);
  hdmi_set_reg(core-v2_blank, 2, m-vtotal / 2);
  hdmi_set_reg(core-v1_blank, 2, (m-vtotal - m-vdisplay) /
 2);
  -   hdmi_set_reg(core-v_blank_f0, 2, (m-vtotal +
  -   ((m-vsync_end - m-vsync_start) * 4) + 5) / 2);
  +   hdmi_set_reg(core-v_blank_f0, 2, m-vtotal - m-vdisplay /
 2);
  hdmi_set_reg(core-v_blank_f1, 2, m-vtotal);
  hdmi_set_reg(core-v_sync_line_aft_2, 2, (m-vtotal / 2) +
 7);
  hdmi_set_reg(core-v_sync_line_aft_1, 2, (m-vtotal / 2) +
 2);
  @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context
 *hdata,
  (m-htotal / 2) + (m-hsync_start - m-hdisplay));
  hdmi_set_reg(tg-vact_st, 2, (m-vtotal - m-vdisplay) / 2);
  hdmi_set_reg(tg-vact_sz, 2, m-vdisplay / 2);
  -   hdmi_set_reg(tg-vact_st2, 2, 0x249);/* Reset value + 1*/
  +   hdmi_set_reg(tg-vact_st2, 2, m-vtotal - m-vdisplay / 2);
  +   hdmi_set_reg(tg-vsync2, 2, (m-vtotal / 2) + 1);
  +   hdmi_set_reg(tg-vsync_bot_hdmi, 2, (m-vtotal / 2) + 1);
  +   hdmi_set_reg(tg-field_bot_hdmi, 2, (m-vtotal / 2) + 1);
  hdmi_set_reg(tg-vact_st3, 2, 0x0);
  hdmi_set_reg(tg-vact_st4, 2, 0x0);
  } else {
  @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
 *hdata,
  hdmi_set_reg(tg-vact_st2, 2, 0x248); /* Reset value */
  hdmi_set_reg(tg-vact_st3, 2, 0x47b); /* Reset value */
  hdmi_set_reg(tg-vact_st4, 2, 0x6ae); /* Reset value */
  +   hdmi_set_reg(tg-vsync2, 2, 0x233); /* Reset value */
  +   hdmi_set_reg(tg-vsync_bot_hdmi, 2, 0x233); /* Reset value
 */
  +   hdmi_set_reg(tg-field_bot_hdmi, 2, 0x233); /* Reset value
 */
  }
 
  /* Following values  calculations are same irrespective of mode
 type */
  @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
 *hdata,
  hdmi_set_reg(tg-hact_sz, 2, m-hdisplay);
  hdmi_set_reg(tg-v_fsz, 2, m-vtotal);
  hdmi_set_reg(tg-vsync, 2, 0x1);
  -   hdmi_set_reg(tg-vsync2, 2, 0x233); /* Reset value */
  hdmi_set_reg(tg-field_chg, 2, 0x233); /* Reset value */
  hdmi_set_reg(tg-vsync_top_hdmi, 2, 0x1); /* Reset value */
  -   hdmi_set_reg(tg-vsync_bot_hdmi, 2, 0x233); /* Reset value */
  hdmi_set_reg(tg-field_top_hdmi, 2, 0x1); /* Reset value */
  -   hdmi_set_reg(tg-field_bot_hdmi, 2, 0x233); /* Reset value */
  hdmi_set_reg(tg-tg_3d, 1, 0x0);
   }
 
 
 
 --
 Seung-Woo Kim
 Samsung Software RD Center
 --

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/prime: support to cache mapping

[Joonyoung Shim]

The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/gpu/drm/drm_prime.c | 54 +
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..ac48038 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,15 +62,29 @@ struct drm_prime_member {
struct dma_buf *dma_buf;
uint32_t handle;
 };
+
+struct drm_prime_attachment {
+   struct sg_table *sgt;
+   enum dma_data_direction dir;
+};
+
 static int drm_prime_add_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
 
 static int drm_gem_map_attach(struct dma_buf *dma_buf,
  struct device *target_dev,
  struct dma_buf_attachment *attach)
 {
+   struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf-priv;
struct drm_device *dev = obj-dev;
 
+   prime_attach = kzalloc(sizeof(*prime_attach), GFP_KERNEL);
+   if (!prime_attach)
+   return -ENOMEM;
+
+   prime_attach-dir = DMA_NONE;
+   attach-priv = prime_attach;
+
if (!dev-driver-gem_prime_pin)
return 0;
 
@@ -80,25 +94,59 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
 static void drm_gem_map_detach(struct dma_buf *dma_buf,
   struct dma_buf_attachment *attach)
 {
+   struct drm_prime_attachment *prime_attach = attach-priv;
struct drm_gem_object *obj = dma_buf-priv;
struct drm_device *dev = obj-dev;
+   struct sg_table *sgt;
 
if (dev-driver-gem_prime_unpin)
dev-driver-gem_prime_unpin(obj);
+
+   if (!prime_attach)
+   return;
+
+   sgt = prime_attach-sgt;
+
+   if (prime_attach-dir != DMA_NONE)
+   dma_unmap_sg(attach-dev, sgt-sgl, sgt-nents,
+   prime_attach-dir);
+
+   sg_free_table(sgt);
+   kfree(sgt);
+   kfree(prime_attach);
+   attach-priv = NULL;
 }
 
 static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
 {
+   struct drm_prime_attachment *prime_attach = attach-priv;
struct drm_gem_object *obj = attach-dmabuf-priv;
struct sg_table *sgt;
 
+   if (WARN_ON(dir == DMA_NONE || !prime_attach))
+   return ERR_PTR(-EINVAL);
+
+   /* return the cached mapping when possible */
+   if (prime_attach-dir == dir)
+   return prime_attach-sgt;
+
+   /*
+* two mappings with different directions for the same attachment are
+* not allowed
+*/
+   if (WARN_ON(prime_attach-dir != DMA_NONE))
+   return ERR_PTR(-EBUSY);
+
mutex_lock(obj-dev-struct_mutex);
 
sgt = obj-dev-driver-gem_prime_get_sg_table(obj);
 
-   if (!IS_ERR_OR_NULL(sgt))
+   if (!IS_ERR_OR_NULL(sgt)) {
dma_map_sg(attach-dev, sgt-sgl, sgt-nents, dir);
+   prime_attach-sgt = sgt;
+   prime_attach-dir = dir;
+   }
 
mutex_unlock(obj-dev-struct_mutex);
return sgt;
@@ -107,9 +155,7 @@ static struct sg_table *drm_gem_map_dma_buf(struct 
dma_buf_attachment *attach,
 static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sgt, enum dma_data_direction dir)
 {
-   dma_unmap_sg(attach-dev, sgt-sgl, sgt-nents, dir);
-   sg_free_table(sgt);
-   kfree(sgt);
+   /* nothing to be done here */
 }
 
 static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer

[김승우]

On 2013년 06월 19일 15:50, Rahul Sharma wrote:
 Add support for exynos5420 mixer IP in the drm mixer driver.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Acked-by: Seung-Woo Kim sw0312@samsung.com

This patch can be merged after merging [PATCH 1/4] drm/exynos: rename
compatible strings for hdmi subsystem.

Best Regards,
- Seung-Woo Kim

 ---
  .../devicetree/bindings/video/exynos_mixer.txt |1 +
  drivers/gpu/drm/exynos/exynos_mixer.c  |   49 
 +++-
  drivers/gpu/drm/exynos/regs-mixer.h|7 +++
  3 files changed, 45 insertions(+), 12 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
 b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 index a8b063f..c64ddc1 100644
 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 @@ -4,6 +4,7 @@ Required properties:
  - compatible: value should be:
   1) samsung,exynos4210-mixer
   2) samsung,exynos5250-mixer
 + 3) samsung,exynos5420-mixer
  
  - reg: physical base address of the mixer and length of memory mapped
   region.
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 2fe6d33..d51ff36 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -78,6 +78,7 @@ struct mixer_resources {
  enum mixer_version_id {
   MXR_VER_0_0_0_16,
   MXR_VER_16_0_33_0,
 + MXR_VER_128_0_0_184,
  };
  
  struct mixer_context {
 @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
 unsigned int height)
   val = (ctx-interlace ? MXR_CFG_SCAN_INTERLACE :
   MXR_CFG_SCAN_PROGRASSIVE);
  
 - /* choosing between porper HD and SD mode */
 - if (height = 480)
 - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
 - else if (height = 576)
 - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
 - else if (height = 720)
 - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 - else if (height = 1080)
 - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
 - else
 - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 + if (ctx-mxr_ver != MXR_VER_128_0_0_184) {
 + /* choosing between proper HD and SD mode */
 + if (height = 480)
 + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
 + else if (height = 576)
 + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
 + else if (height = 720)
 + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 + else if (height = 1080)
 + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
 + else
 + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 + }
  
   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
  }
 @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context 
 *ctx, int win)
   /* setup geometry */
   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data-fb_width);
  
 + /* setup display size */
 + if (ctx-mxr_ver == MXR_VER_128_0_0_184 
 + win == MIXER_DEFAULT_WIN) {
 + val  = MXR_MXR_RES_HEIGHT(win_data-fb_height);
 + val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
 + mixer_reg_write(res, MXR_RESOLUTION, val);
 + }
 +
   val  = MXR_GRP_WH_WIDTH(win_data-crtc_width);
   val |= MXR_GRP_WH_HEIGHT(win_data-crtc_height);
   val |= MXR_GRP_WH_H_SCALE(x_ratio);
 @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
 int win)
   mixer_cfg_layer(ctx, win, true);
  
   /* layer update mandatory for mixer 16.0.33.0 */
 - if (ctx-mxr_ver == MXR_VER_16_0_33_0)
 + if (ctx-mxr_ver == MXR_VER_16_0_33_0 ||
 + ctx-mxr_ver == MXR_VER_128_0_0_184)
   mixer_layer_update(ctx);
  
   mixer_run(ctx);
 @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
  
  static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
  {
 + struct mixer_context *mixer_ctx = ctx;
   u32 w, h;
  
   w = mode-hdisplay;
 @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
 drm_display_mode *mode)
   mode-hdisplay, mode-vdisplay, mode-vrefresh,
   (mode-flags  DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
  
 + if (mixer_ctx-mxr_ver == MXR_VER_0_0_0_16 ||
 + mixer_ctx-mxr_ver == MXR_VER_128_0_0_184)
 + return 0;
 +
   if ((w = 464  w = 720  h = 261  h = 576) ||
   (w = 1024  w = 1280  h = 576  h = 720) ||
   (w = 1664  w = 1920  h = 936  h = 1080))
 @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
 exynos_drm_hdmi_context *ctx,
   return 0;
  }
  
 +static struct mixer_drv_data exynos5420_mxr_drv_data = {
 + .version = 

RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Inki Dae]

 -Original Message-
 From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
 Sent: Tuesday, June 18, 2013 9:50 PM
 To: linux-samsung-...@vger.kernel.org;
devicetree-disc...@lists.ozlabs.org;
 dri-devel@lists.freedesktop.org
 Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
 jo...@samsung.com; r.sh.o...@gmail.com; Rahul Sharma
 Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
 subsystem
 
 This patch renames the combatible strings for hdmi, mixer, ddc
 and hdmiphy. It follows the convention of using compatible string
 which represent the SoC in which the IP was added for the first
 time.
 

Hi Rahul,

Could you separate this patch into two patches, driver side and document
side, and the below patch also?
[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer

Thanks,
Inki Dae

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
  Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
  Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
  Documentation/devicetree/bindings/video/exynos_mixer.txt   |7 +--
  drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
  drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
  drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
  drivers/gpu/drm/exynos/exynos_mixer.c  |   12
++--
  8 files changed, 26 insertions(+), 17 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 index 589edee..2ac01ca 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 @@ -1,7 +1,9 @@
  Device-Tree bindings for drm hdmi driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-hdmi.
 +- compatible: value should be one among the following:
 + 1) samsung,exynos4210-hdmi
 + 2) samsung,exynos4212-hdmi
  - reg: physical base address of the hdmi and length of memory mapped
   region.
  - interrupts: interrupt number to the cpu.
 @@ -15,7 +17,7 @@ Required properties:
  Example:
 
   hdmi {
 - compatible = samsung,exynos5-hdmi;
 + compatible = samsung,exynos4212-hdmi;
   reg = 0x1453 0x10;
   interrupts = 0 95 0;
   hpd-gpio = gpx3 7 0xf 1 3;
 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 index fa166d9..c1bd2ea 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 @@ -1,12 +1,12 @@
  Device-Tree bindings for hdmiddc driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-hdmiddc.
 +- compatible: value should be samsung,exynos4210-hdmiddc.
  - reg: I2C address of the hdmiddc device.
 
  Example:
 
   hdmiddc {
 - compatible = samsung,exynos5-hdmiddc;
 + compatible = samsung,exynos4210-hdmiddc;
   reg = 0x50;
   };
 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 index 858f4f9..e59d793 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 @@ -1,12 +1,14 @@
  Device-Tree bindings for hdmiphy driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-hdmiphy.
 +- compatible: value should be
 + 1) samsung,exynos4210-hdmiphy.
 + 2) samsung,exynos4212-hdmiphy.
  - reg: I2C address of the hdmiphy device.
 
  Example:
 
   hdmiphy {
 - compatible = samsung,exynos5-hdmiphy;
 + compatible = samsung,exynos4210-hdmiphy;
   reg = 0x38;
   };
 diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
 b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 index 9b2ea03..a8b063f 100644
 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 @@ -1,7 +1,10 @@
  Device-Tree bindings for mixer driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-mixer.
 +- compatible: value should be:
 + 1) samsung,exynos4210-mixer
 + 2) samsung,exynos5250-mixer
 +
  - reg: physical base address of the mixer and length of memory mapped
   region.
  - interrupts: interrupt number to the cpu.
 @@ -9,7 +12,7 @@ Required properties:
  Example:
 
   mixer {
 - compatible = samsung,exynos5-mixer;
 + compatible = samsung,exynos5250-mixer;
   reg = 0x1445 0x1;
   interrupts = 0 94 0;
   };
 diff --git 

RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Inki Dae]

 -Original Message-
 From: Inki Dae [mailto:inki@samsung.com]
 Sent: Wednesday, June 19, 2013 4:06 PM
 To: 'Rahul Sharma'; 'linux-samsung-...@vger.kernel.org'; 'devicetree-
 disc...@lists.ozlabs.org'; 'dri-devel@lists.freedesktop.org'
 Cc: 'kgene@samsung.com'; 'sw0312@samsung.com';
'jo...@samsung.com';
 'r.sh.o...@gmail.com'
 Subject: RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
 subsystem
 
 
 
  -Original Message-
  From: Rahul Sharma [mailto:rahul.sha...@samsung.com]
  Sent: Tuesday, June 18, 2013 9:50 PM
  To: linux-samsung-...@vger.kernel.org; devicetree-
 disc...@lists.ozlabs.org;
  dri-devel@lists.freedesktop.org
  Cc: kgene@samsung.com; sw0312@samsung.com; inki@samsung.com;
  jo...@samsung.com; r.sh.o...@gmail.com; Rahul Sharma
  Subject: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
  subsystem
 
  This patch renames the combatible strings for hdmi, mixer, ddc
  and hdmiphy. It follows the convention of using compatible string
  which represent the SoC in which the IP was added for the first
  time.
 
 
 Hi Rahul,
 
 Could you separate this patch into two patches, driver side and document
 side, and the below patch also?
   [PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
 

Sorry, just will merge them.

To devicetree maintainers, please give me ACK.

Thanks,
Inki Dae

 Thanks,
 Inki Dae
 
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
  ---
   Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
--
   Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
   Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6
--
   Documentation/devicetree/bindings/video/exynos_mixer.txt   |7
+--
   drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
   drivers/gpu/drm/exynos/exynos_hdmi.c   |2 +-
   drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
   drivers/gpu/drm/exynos/exynos_mixer.c  |   12
++-
 -
   8 files changed, 26 insertions(+), 17 deletions(-)
 
  diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  index 589edee..2ac01ca 100644
  --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  @@ -1,7 +1,9 @@
   Device-Tree bindings for drm hdmi driver
 
   Required properties:
  -- compatible: value should be samsung,exynos5-hdmi.
  +- compatible: value should be one among the following:
  +   1) samsung,exynos4210-hdmi
  +   2) samsung,exynos4212-hdmi
   - reg: physical base address of the hdmi and length of memory mapped
  region.
   - interrupts: interrupt number to the cpu.
  @@ -15,7 +17,7 @@ Required properties:
   Example:
 
  hdmi {
  -   compatible = samsung,exynos5-hdmi;
  +   compatible = samsung,exynos4212-hdmi;
  reg = 0x1453 0x10;
  interrupts = 0 95 0;
  hpd-gpio = gpx3 7 0xf 1 3;
  diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
  b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
  index fa166d9..c1bd2ea 100644
  --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
  +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
  @@ -1,12 +1,12 @@
   Device-Tree bindings for hdmiddc driver
 
   Required properties:
  -- compatible: value should be samsung,exynos5-hdmiddc.
  +- compatible: value should be samsung,exynos4210-hdmiddc.
   - reg: I2C address of the hdmiddc device.
 
   Example:
 
  hdmiddc {
  -   compatible = samsung,exynos5-hdmiddc;
  +   compatible = samsung,exynos4210-hdmiddc;
  reg = 0x50;
  };
  diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
  b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
  index 858f4f9..e59d793 100644
  --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
  +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
  @@ -1,12 +1,14 @@
   Device-Tree bindings for hdmiphy driver
 
   Required properties:
  -- compatible: value should be samsung,exynos5-hdmiphy.
  +- compatible: value should be
  +   1) samsung,exynos4210-hdmiphy.
  +   2) samsung,exynos4212-hdmiphy.
   - reg: I2C address of the hdmiphy device.
 
   Example:
 
  hdmiphy {
  -   compatible = samsung,exynos5-hdmiphy;
  +   compatible = samsung,exynos4210-hdmiphy;
  reg = 0x38;
  };
  diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
  b/Documentation/devicetree/bindings/video/exynos_mixer.txt
  index 9b2ea03..a8b063f 100644
  --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
  +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
  @@ -1,7 +1,10 @@
   Device-Tree bindings for mixer driver
 
   Required properties:
  -- 

[Bug 64257] RS880 issues with r600-llvm-compiler

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64257

--- Comment #72 from Marc Dietrich marvi...@gmx.de ---
yup, heaven works, kronos test suite reports doesn't crash anymore, but fail
(misrenders) on sin/cos as expected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Tomasz Figa]

Hi Rahul,

On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
 This patch renames the combatible strings for hdmi, mixer, ddc
 and hdmiphy. It follows the convention of using compatible string
 which represent the SoC in which the IP was added for the first
 time.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
 -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |   
 4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |   
 6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |  
  7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |   
 2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
 +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
 ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
 589edee..2ac01ca 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 @@ -1,7 +1,9 @@
  Device-Tree bindings for drm hdmi driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-hdmi.
 +- compatible: value should be one among the following:
 + 1) samsung,exynos4210-hdmi
 + 2) samsung,exynos4212-hdmi
  - reg: physical base address of the hdmi and length of memory mapped
   region.
  - interrupts: interrupt number to the cpu.
 @@ -15,7 +17,7 @@ Required properties:
  Example:
 
   hdmi {
 - compatible = samsung,exynos5-hdmi;
 + compatible = samsung,exynos4212-hdmi;

Sorry, but it's a NAK from me.

DeviceTree bindings are considered an ABI. This is to allow older dtbs to 
work with new kernels.

If you just change the binding this way, you break all the existing users 
of this compatible value.

In addition you are doing it in a way that breaks bisection:
 - patch 1/4 breaks existing in-tree users of current compatible values,
 - after patch 2 and 3 it is still broken,
 - and eventually all in-tree users are fixed by patch 4 (but you can't 
fix out-of-tree users).

Please do it without changing existing compatible values. Even if they are 
misleading, this is all can be described in the documentation - just list 
SoCs that can be used with each compatible value there.

Best regards,
Tomasz

   reg = 0x1453 0x10;
   interrupts = 0 95 0;
   hpd-gpio = gpx3 7 0xf 1 3;
 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt index
 fa166d9..c1bd2ea 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
 @@ -1,12 +1,12 @@
  Device-Tree bindings for hdmiddc driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-hdmiddc.
 +- compatible: value should be samsung,exynos4210-hdmiddc.
  - reg: I2C address of the hdmiddc device.
 
  Example:
 
   hdmiddc {
 - compatible = samsung,exynos5-hdmiddc;
 + compatible = samsung,exynos4210-hdmiddc;
   reg = 0x50;
   };
 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt index
 858f4f9..e59d793 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
 @@ -1,12 +1,14 @@
  Device-Tree bindings for hdmiphy driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-hdmiphy.
 +- compatible: value should be
 + 1) samsung,exynos4210-hdmiphy.
 + 2) samsung,exynos4212-hdmiphy.
  - reg: I2C address of the hdmiphy device.
 
  Example:
 
   hdmiphy {
 - compatible = samsung,exynos5-hdmiphy;
 + compatible = samsung,exynos4210-hdmiphy;
   reg = 0x38;
   };
 diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
 b/Documentation/devicetree/bindings/video/exynos_mixer.txt index
 9b2ea03..a8b063f 100644
 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 @@ -1,7 +1,10 @@
  Device-Tree bindings for mixer driver
 
  Required properties:
 -- compatible: value should be samsung,exynos5-mixer.
 +- compatible: value should be:
 + 1) samsung,exynos4210-mixer
 + 2) samsung,exynos5250-mixer
 +
  - reg: physical base address of the mixer and length of memory mapped
   region.
  - interrupts: interrupt number to the cpu.
 @@ -9,7 +12,7 @@ Required properties:
  Example:
 
   mixer {
 - compatible = samsung,exynos5-mixer;
 + compatible = 

Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Lucas Stach]

Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
 Hi Rahul,
 
 On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
  This patch renames the combatible strings for hdmi, mixer, ddc
  and hdmiphy. It follows the convention of using compatible string
  which represent the SoC in which the IP was added for the first
  time.
  
  Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
  ---
   Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
  -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |   
  4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |   
  6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |  
   7 +-- drivers/gpu/drm/exynos/exynos_ddc.c|
 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |   
  2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
  +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
  ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
  
  diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
  589edee..2ac01ca 100644
  --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
  @@ -1,7 +1,9 @@
   Device-Tree bindings for drm hdmi driver
  
   Required properties:
  -- compatible: value should be samsung,exynos5-hdmi.
  +- compatible: value should be one among the following:
  +   1) samsung,exynos4210-hdmi
  +   2) samsung,exynos4212-hdmi
   - reg: physical base address of the hdmi and length of memory mapped
  region.
   - interrupts: interrupt number to the cpu.
  @@ -15,7 +17,7 @@ Required properties:
   Example:
  
  hdmi {
  -   compatible = samsung,exynos5-hdmi;
  +   compatible = samsung,exynos4212-hdmi;
 
 Sorry, but it's a NAK from me.
 
 DeviceTree bindings are considered an ABI. This is to allow older dtbs to 
 work with new kernels.
 
 If you just change the binding this way, you break all the existing users 
 of this compatible value.
 
 In addition you are doing it in a way that breaks bisection:
  - patch 1/4 breaks existing in-tree users of current compatible values,
  - after patch 2 and 3 it is still broken,
  - and eventually all in-tree users are fixed by patch 4 (but you can't 
 fix out-of-tree users).
 
 Please do it without changing existing compatible values. Even if they are 
 misleading, this is all can be described in the documentation - just list 
 SoCs that can be used with each compatible value there.
 

Or you could just introduce the new compatible value and make all
in-tree users use this, but keep the old values around and still accept
them in the drivers. This way you get the goodness of the cleaner new
symbols without breaking existing users. Just mark the old values as
deprecated in the documentation, so no new devicetree usees them.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Inki Dae]

 -Original Message-
 From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
 [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
 Behalf Of Lucas Stach
 Sent: Wednesday, June 19, 2013 4:59 PM
 To: Tomasz Figa
 Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
 sw0312@samsung.com; jo...@samsung.com;
dri-devel@lists.freedesktop.org;
 linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
 s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
 Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
 subsystem
 
 Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
  Hi Rahul,
 
  On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
   This patch renames the combatible strings for hdmi, mixer, ddc
   and hdmiphy. It follows the convention of using compatible string
   which represent the SoC in which the IP was added for the first
   time.
  
   Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
   ---
Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
   -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
   4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
   6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
|
  2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
   2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
   +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
   ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
  
   diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
   b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
   589edee..2ac01ca 100644
   --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
   +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
   @@ -1,7 +1,9 @@
Device-Tree bindings for drm hdmi driver
  
Required properties:
   -- compatible: value should be samsung,exynos5-hdmi.
   +- compatible: value should be one among the following:
   + 1) samsung,exynos4210-hdmi
   + 2) samsung,exynos4212-hdmi
- reg: physical base address of the hdmi and length of memory mapped
 region.
- interrupts: interrupt number to the cpu.
   @@ -15,7 +17,7 @@ Required properties:
Example:
  
 hdmi {
   - compatible = samsung,exynos5-hdmi;
   + compatible = samsung,exynos4212-hdmi;
 
  Sorry, but it's a NAK from me.
 
  DeviceTree bindings are considered an ABI. This is to allow older dtbs
 to
  work with new kernels.
 
  If you just change the binding this way, you break all the existing
 users
  of this compatible value.
 
  In addition you are doing it in a way that breaks bisection:
   - patch 1/4 breaks existing in-tree users of current compatible values,
   - after patch 2 and 3 it is still broken,
   - and eventually all in-tree users are fixed by patch 4 (but you can't
  fix out-of-tree users).
 
  Please do it without changing existing compatible values. Even if they
 are
  misleading, this is all can be described in the documentation - just
 list
  SoCs that can be used with each compatible value there.
 
 
 Or you could just introduce the new compatible value and make all
 in-tree users use this, but keep the old values around and still accept
 them in the drivers. This way you get the goodness of the cleaner new
 symbols without breaking existing users. Just mark the old values as
 deprecated in the documentation, so no new devicetree usees them.
 

That's a good idea. We really need to mitigate such misleading somehow or
other.

Thanks,
Inki Dae

 Regards,
 Lucas
 --
 Pengutronix e.K.   | Lucas Stach |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v3] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.

The purpose of this framework is to provide not only buffer access control
to CPU and DMA but also easy-to-use interfaces for device drivers and
potentially user application (not implemented for user applications, yet).
And this framework can be used for all dma devices using system memory as
dma buffer, especially for most ARM based SoCs.

Changelog v3:
- remove cache operation relevant codes and update document file.

Changelog v2:
- use atomic_add_unless to avoid potential bug.
- add a macro for checking valid access type.
- code clean.

The mechanism of this framework has the following steps,
1. Register dmabufs to a sync object - A task gets a new sync object and
can add one or more dmabufs that the task wants to access.
This registering should be performed when a device context or an event
context such as a page flip event is created or before CPU accesses a shared
buffer.

dma_buf_sync_get(a sync object, a dmabuf);

2. Lock a sync object - A task tries to lock all dmabufs added in its own
sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead
lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA
and DMA. Taking a lock means that others cannot access all locked dmabufs
until the task that locked the corresponding dmabufs, unlocks all the locked
dmabufs.
This locking should be performed before DMA or CPU accesses these dmabufs.

dma_buf_sync_lock(a sync object);

3. Unlock a sync object - The task unlocks all dmabufs added in its own sync
object. The unlock means that the DMA or CPU accesses to the dmabufs have
been completed so that others may access them.
This unlocking should be performed after DMA or CPU has completed accesses
to the dmabufs.

dma_buf_sync_unlock(a sync object);

4. Unregister one or all dmabufs from a sync object - A task unregisters
the given dmabufs from the sync object. This means that the task dosen't
want to lock the dmabufs.
The unregistering should be performed after DMA or CPU has completed
accesses to the dmabufs or when dma_buf_sync_lock() is failed.

dma_buf_sync_put(a sync object, a dmabuf);
dma_buf_sync_put_all(a sync object);

The described steps may be summarized as:
get - lock - CPU or DMA access to a buffer/s - unlock - put

This framework includes the following two features.
1. read (shared) and write (exclusive) locks - A task is required to declare
the access type when the task tries to register a dmabuf;
READ, WRITE, READ DMA, or WRITE DMA.

The below is example codes,
struct dmabuf_sync *sync;

sync = dmabuf_sync_init(NULL, test sync);

dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_R);
...

And the below can be used as access types:
DMA_BUF_ACCESS_R - CPU will access a buffer for read.
DMA_BUF_ACCESS_W - CPU will access a buffer for read or write.
DMA_BUF_ACCESS_DMA_R - DMA will access a buffer for read
DMA_BUF_ACCESS_DMA_W - DMA will access a buffer for read or
write.

2. Mandatory resource releasing - a task cannot hold a lock indefinitely.
A task may never try to unlock a buffer after taking a lock to the buffer.
In this case, a timer handler to the corresponding sync object is called
in five (default) seconds and then the timed-out buffer is unlocked by work
queue handler to avoid lockups and to enforce resources of the buffer.

The below is how to use:
1. Allocate and Initialize a sync object:
struct dmabuf_sync *sync;

sync = dmabuf_sync_init(NULL, test sync);
...

2. Add a dmabuf to the sync object when setting up dma buffer relevant
   registers:
dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ);
...

3. Lock all dmabufs of the sync object before DMA or CPU accesses
   the dmabufs:
dmabuf_sync_lock(sync);
...

4. Now CPU or DMA can access all dmabufs locked in step 3.

5. Unlock all dmabufs added in a sync object after DMA or CPU access
   to these dmabufs is completed:
dmabuf_sync_unlock(sync);

   And call the following functions to release all resources,
dmabuf_sync_put_all(sync);
dmabuf_sync_fini(sync);

You can refer to actual example codes:

https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/

commit/?h=dmabuf-syncid=4030bdee9bab5841ad32faade528d04cc0c5fc94


https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/

Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Rahul Sharma]

Hi All,

On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae inki@samsung.com wrote:


 -Original Message-
 From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
 [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
 Behalf Of Lucas Stach
 Sent: Wednesday, June 19, 2013 4:59 PM
 To: Tomasz Figa
 Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
 sw0312@samsung.com; jo...@samsung.com;
 dri-devel@lists.freedesktop.org;
 linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
 s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
 Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
 subsystem

 Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
  Hi Rahul,
 
  On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
   This patch renames the combatible strings for hdmi, mixer, ddc
   and hdmiphy. It follows the convention of using compatible string
   which represent the SoC in which the IP was added for the first
   time.
  
   Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
   ---
Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
   -- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
   4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
   6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
 |
  2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
   2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4
   +++- drivers/gpu/drm/exynos/exynos_mixer.c  |   12
   ++-- 8 files changed, 26 insertions(+), 17 deletions(-)
  
   diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
   b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
   589edee..2ac01ca 100644
   --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
   +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
   @@ -1,7 +1,9 @@
Device-Tree bindings for drm hdmi driver
  
Required properties:
   -- compatible: value should be samsung,exynos5-hdmi.
   +- compatible: value should be one among the following:
   + 1) samsung,exynos4210-hdmi
   + 2) samsung,exynos4212-hdmi
- reg: physical base address of the hdmi and length of memory mapped
 region.
- interrupts: interrupt number to the cpu.
   @@ -15,7 +17,7 @@ Required properties:
Example:
  
 hdmi {
   - compatible = samsung,exynos5-hdmi;
   + compatible = samsung,exynos4212-hdmi;
 
  Sorry, but it's a NAK from me.
 
  DeviceTree bindings are considered an ABI. This is to allow older dtbs
 to
  work with new kernels.
 
  If you just change the binding this way, you break all the existing
 users
  of this compatible value.
 
  In addition you are doing it in a way that breaks bisection:
   - patch 1/4 breaks existing in-tree users of current compatible values,
   - after patch 2 and 3 it is still broken,
   - and eventually all in-tree users are fixed by patch 4 (but you can't
  fix out-of-tree users).
 

@Tomasz, I understand your point but how is it possible to change
compatible types in driver as well as in dtbs by not breaking either of them
other then putting changes in a single patch. I ensured that hdmi stuff is
intact with whole series merged in either tree (drm or arch). Please suggest
a better way.

The Only existing user is Exynos5250, which is modified in the same patch
set.

  Please do it without changing existing compatible values. Even if they
 are
  misleading, this is all can be described in the documentation - just
 list
  SoCs that can be used with each compatible value there.
 

 Or you could just introduce the new compatible value and make all
 in-tree users use this, but keep the old values around and still accept
 them in the drivers. This way you get the goodness of the cleaner new
 symbols without breaking existing users. Just mark the old values as
 deprecated in the documentation, so no new devicetree usees them.


I agree, above is a decent approach, but in this case we have only one
user for this compatible type including in flight patches which I have
modified along.

If it seems better to keep old compatible type (deprecated), it is fine
with me.


 That's a good idea. We really need to mitigate such misleading somehow or
 other.

Please sugggest me how to proceed.

regards,
Rahul Sharma.


 Thanks,
 Inki Dae

 Regards,
 Lucas
 --
 Pengutronix e.K.   | Lucas Stach |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

 

Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Tomasz Figa]

Hi Rahul,

On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
 Hi All,
 
 On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae inki@samsung.com wrote:
  -Original Message-
  From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
  [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
  Behalf Of Lucas Stach
  Sent: Wednesday, June 19, 2013 4:59 PM
  To: Tomasz Figa
  Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
  sw0312@samsung.com; jo...@samsung.com;
  
  dri-devel@lists.freedesktop.org;
  
  linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
  s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
  Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
  subsystem
  
  Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
   Hi Rahul,
   
   On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---

 Documentation/devicetree/bindings/video/exynos_hdmi.txt|6

-- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |

 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
 
   2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |

2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|   
4
+++- drivers/gpu/drm/exynos/exynos_mixer.c  |  
12
++-- 8 files changed, 26 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
589edee..2ac01ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,9 @@

 Device-Tree bindings for drm hdmi driver

 Required properties:
-- compatible: value should be samsung,exynos5-hdmi.
+- compatible: value should be one among the following:
+ 1) samsung,exynos4210-hdmi
+ 2) samsung,exynos4212-hdmi

 - reg: physical base address of the hdmi and length of memory mapped
 
  region.
 
 - interrupts: interrupt number to the cpu.

@@ -15,7 +17,7 @@ Required properties:
 Example:
  hdmi {

- compatible = samsung,exynos5-hdmi;
+ compatible = samsung,exynos4212-hdmi;
   
   Sorry, but it's a NAK from me.
   
   DeviceTree bindings are considered an ABI. This is to allow older dtbs
  
  to
  
   work with new kernels.
   
   If you just change the binding this way, you break all the existing
  
  users
  
   of this compatible value.
   
   In addition you are doing it in a way that breaks bisection:
- patch 1/4 breaks existing in-tree users of current compatible
values,
- after patch 2 and 3 it is still broken,
- and eventually all in-tree users are fixed by patch 4 (but you can't
   
   fix out-of-tree users).
 
 @Tomasz, I understand your point but how is it possible to change
 compatible types in driver as well as in dtbs by not breaking either of them
 other then putting changes in a single patch.

It's very easy. (Let's forget about the fact that DT bindings are an ABI 
temporarily) You can simply add new compatible values to the driver in first 
patch, then modify dts files in second one and then remove old compatibles 
values from the driver in third patch. (Now we remember about DT being ABI 
again.)

 I ensured that hdmi stuff is
 intact with whole series merged in either tree (drm or arch). Please
 suggest a better way.
 
 The Only existing user is Exynos5250, which is modified in the same patch
 set.

This is not true. You have modified only the existing _in_ _tree_ users.

Keep in mind that device tree is not a part of the kernel. It is currently 
located in the same tree, but it is _not_ a part of the kernel.

Now think about existing boards (like exynos5250-snow) that have a dtb built 
from older dts sources stored in their flash memory. You need to maintain 
compatibilty with this old dtb in new kernels as well.

   Please do it without changing existing compatible values. Even if they
  
  are
  
   misleading, this is all can be described in the documentation - just
  
  list
  
   SoCs that can be used with each compatible value there.
  
  Or you could just introduce the new compatible value and make all
  in-tree users use this, but keep the old values around and still accept
  them in the drivers. This way you get the goodness of the cleaner new
  symbols without breaking existing users. Just mark 

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
 
  -Original Message-
  From: Lucas Stach [mailto:l.st...@pengutronix.de]
  Sent: Tuesday, June 18, 2013 6:47 PM
  To: Inki Dae
  Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
  mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
  ker...@lists.infradead.org; linux-me...@vger.kernel.org
  Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
  framework
  
  Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
  [...]
  
a display device driver.  It shouldn't be used within a single driver
as a means of passing buffers between userspace and kernel space.
  
   What I try to do is not really such ugly thing. What I try to do is to
   notify that, when CPU tries to access a buffer , to kernel side through
   dmabuf interface. So it's not really to send the buffer to kernel.
  
   Thanks,
   Inki Dae
  
  The most basic question about why you are trying to implement this sort
  of thing in the dma_buf framework still stands.
  
  Once you imported a dma_buf into your DRM driver it's a GEM object and
  you can and should use the native DRM ioctls to prepare/end a CPU access
  to this BO. Then internally to your driver you can use the dma_buf
  reservation/fence stuff to provide the necessary cross-device sync.
  
 
 I don't really want that is used only for DRM drivers. We really need
 it for all other DMA devices; i.e., v4l2 based drivers. That is what I
 try to do. And my approach uses reservation to use dma-buf resources
 but not dma fence stuff anymore. However, I'm looking into Radeon DRM
 driver for why we need dma fence stuff, and how we can use it if
 needed.
 

Still I don't see the point why you need syncpoints above dma-buf. In
both the DRM and the V4L2 world we have defined points in the API where
a buffer is allowed to change domain from device to CPU and vice versa.

In DRM if you want to access a buffer with the CPU you do a cpu_prepare.
The buffer changes back to GPU domain once you do the execbuf
validation, queue a pageflip to the buffer or similar things.

In V4L2 the syncpoints for cache operations are the queue/dequeue API
entry points. Those are also the exact points to synchronize with other
hardware thus using dma-buf reserve/fence.

In all this I can't see any need for a new syncpoint primitive slapped
on top of dma-buf.

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem

[Rahul Sharma]

On Wed, Jun 19, 2013 at 3:20 PM, Tomasz Figa t.f...@samsung.com wrote:
 Hi Rahul,

 On Wednesday 19 of June 2013 15:02:59 Rahul Sharma wrote:
 Hi All,

 On Wed, Jun 19, 2013 at 1:57 PM, Inki Dae inki@samsung.com wrote:
  -Original Message-
  From: dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org
  [mailto:dri-devel-bounces+inki.dae=samsung@lists.freedesktop.org] On
  Behalf Of Lucas Stach
  Sent: Wednesday, June 19, 2013 4:59 PM
  To: Tomasz Figa
  Cc: kgene@samsung.com; devicetree-disc...@lists.ozlabs.org;
  sw0312@samsung.com; jo...@samsung.com;
 
  dri-devel@lists.freedesktop.org;
 
  linux-samsung-...@vger.kernel.org; rob.herr...@calxeda.com;
  s.nawro...@samsung.com; grant.lik...@linaro.org; Rahul Sharma
  Subject: Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi
  subsystem
 
  Am Mittwoch, den 19.06.2013, 09:52 +0200 schrieb Tomasz Figa:
   Hi Rahul,
  
   On Tuesday 18 of June 2013 18:19:35 Rahul Sharma wrote:
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
   
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
   
 Documentation/devicetree/bindings/video/exynos_hdmi.txt|6
   
-- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |
4 ++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |
6 -- Documentation/devicetree/bindings/video/exynos_mixer.txt   |
   
 7 +-- drivers/gpu/drm/exynos/exynos_ddc.c
   
   2 +- drivers/gpu/drm/exynos/exynos_hdmi.c   |
   
2 +- drivers/gpu/drm/exynos/exynos_hdmiphy.c|
4
+++- drivers/gpu/drm/exynos/exynos_mixer.c  |
12
++-- 8 files changed, 26 insertions(+), 17 deletions(-)
   
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index
589edee..2ac01ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,9 @@
   
 Device-Tree bindings for drm hdmi driver
   
 Required properties:
-- compatible: value should be samsung,exynos5-hdmi.
+- compatible: value should be one among the following:
+ 1) samsung,exynos4210-hdmi
+ 2) samsung,exynos4212-hdmi
   
 - reg: physical base address of the hdmi and length of memory mapped
   
  region.
   
 - interrupts: interrupt number to the cpu.
   
@@ -15,7 +17,7 @@ Required properties:
 Example:
  hdmi {
   
- compatible = samsung,exynos5-hdmi;
+ compatible = samsung,exynos4212-hdmi;
  
   Sorry, but it's a NAK from me.
  
   DeviceTree bindings are considered an ABI. This is to allow older dtbs
 
  to
 
   work with new kernels.
  
   If you just change the binding this way, you break all the existing
 
  users
 
   of this compatible value.
  
   In addition you are doing it in a way that breaks bisection:
- patch 1/4 breaks existing in-tree users of current compatible
values,
- after patch 2 and 3 it is still broken,
- and eventually all in-tree users are fixed by patch 4 (but you can't
  
   fix out-of-tree users).

 @Tomasz, I understand your point but how is it possible to change
 compatible types in driver as well as in dtbs by not breaking either of them
 other then putting changes in a single patch.

 It's very easy. (Let's forget about the fact that DT bindings are an ABI
 temporarily) You can simply add new compatible values to the driver in first
 patch, then modify dts files in second one and then remove old compatibles
 values from the driver in third patch. (Now we remember about DT being ABI
 again.)

 I ensured that hdmi stuff is
 intact with whole series merged in either tree (drm or arch). Please
 suggest a better way.

 The Only existing user is Exynos5250, which is modified in the same patch
 set.

 This is not true. You have modified only the existing _in_ _tree_ users.

 Keep in mind that device tree is not a part of the kernel. It is currently
 located in the same tree, but it is _not_ a part of the kernel.

 Now think about existing boards (like exynos5250-snow) that have a dtb built
 from older dts sources stored in their flash memory. You need to maintain
 compatibilty with this old dtb in new kernels as well.

   Please do it without changing existing compatible values. Even if they
 
  are
 
   misleading, this is all can be described in the documentation - just
 
  list
 
   SoCs that can be used with each compatible value there.
 
  Or you could just introduce the new compatible value and make all
  in-tree users use this, but keep the old values around and still accept
  them in the drivers. This way you get the goodness of the cleaner new
  symbols without 

RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

 -Original Message-
 From: Lucas Stach [mailto:l.st...@pengutronix.de]
 Sent: Wednesday, June 19, 2013 7:22 PM
 To: Inki Dae
 Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
 mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
 ker...@lists.infradead.org; linux-me...@vger.kernel.org
 Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
 framework
 
 Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
 
   -Original Message-
   From: Lucas Stach [mailto:l.st...@pengutronix.de]
   Sent: Tuesday, June 18, 2013 6:47 PM
   To: Inki Dae
   Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
   mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
   ker...@lists.infradead.org; linux-me...@vger.kernel.org
   Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
 synchronization
   framework
  
   Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
   [...]
   
 a display device driver.  It shouldn't be used within a single
 driver
 as a means of passing buffers between userspace and kernel space.
   
What I try to do is not really such ugly thing. What I try to do is
 to
notify that, when CPU tries to access a buffer , to kernel side
 through
dmabuf interface. So it's not really to send the buffer to kernel.
   
Thanks,
Inki Dae
   
   The most basic question about why you are trying to implement this
 sort
   of thing in the dma_buf framework still stands.
  
   Once you imported a dma_buf into your DRM driver it's a GEM object and
   you can and should use the native DRM ioctls to prepare/end a CPU
 access
   to this BO. Then internally to your driver you can use the dma_buf
   reservation/fence stuff to provide the necessary cross-device sync.
  
 
  I don't really want that is used only for DRM drivers. We really need
  it for all other DMA devices; i.e., v4l2 based drivers. That is what I
  try to do. And my approach uses reservation to use dma-buf resources
  but not dma fence stuff anymore. However, I'm looking into Radeon DRM
  driver for why we need dma fence stuff, and how we can use it if
  needed.
 
 
 Still I don't see the point why you need syncpoints above dma-buf. In
 both the DRM and the V4L2 world we have defined points in the API where
 a buffer is allowed to change domain from device to CPU and vice versa.
 
 In DRM if you want to access a buffer with the CPU you do a cpu_prepare.
 The buffer changes back to GPU domain once you do the execbuf
 validation, queue a pageflip to the buffer or similar things.
 
 In V4L2 the syncpoints for cache operations are the queue/dequeue API
 entry points. Those are also the exact points to synchronize with other
 hardware thus using dma-buf reserve/fence.


If so, what if we want to access a buffer with the CPU _in V4L2_? We should 
open a drm device node, and then do a cpu_prepare? 

Thanks,
Inki Dae

 
 In all this I can't see any need for a new syncpoint primitive slapped
 on top of dma-buf.
 
 Regards,
 Lucas
 --
 Pengutronix e.K.   | Lucas Stach |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/shmobile: Enable compilation on all ARM platforms

[Laurent Pinchart]

This is required to support multi-arch kernels.

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 drivers/gpu/drm/shmobile/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/shmobile/Kconfig b/drivers/gpu/drm/shmobile/Kconfig
index 7e7d52b..62905b4 100644
--- a/drivers/gpu/drm/shmobile/Kconfig
+++ b/drivers/gpu/drm/shmobile/Kconfig
@@ -1,6 +1,6 @@
 config DRM_SHMOBILE
tristate DRM Support for SH Mobile
-   depends on DRM  (SUPERH || ARCH_SHMOBILE)
+   depends on DRM  (ARM || SUPERH)
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Improve manual IRQ installation documentation

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 Documentation/DocBook/drm.tmpl | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f9df3b8..738b727 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -186,11 +186,12 @@
   varlistentry
 termDRIVER_HAVE_IRQ/termtermDRIVER_IRQ_SHARED/term
 listitempara
-  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. 
The
-  DRM core will automatically register an interrupt handler when 
the
-  flag is set. DRIVER_IRQ_SHARED indicates whether the device amp;
-  handler support shared IRQs (note that this is required of PCI
-  drivers).
+  DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
+  managed by the DRM Core. The core will support simple IRQ handler
+  installation when the flag is set. The installation process is
+  described in xref linkend=drm-irq-registration/./para
+  paraDRIVER_IRQ_SHARED indicates whether the device amp; 
handler
+  support shared IRQs (note that this is required of PCI  drivers).
 /para/listitem
   /varlistentry
   varlistentry
@@ -344,7 +345,8 @@ char *date;/synopsis
   The DRM core tries to facilitate IRQ handler registration and
   unregistration by providing functiondrm_irq_install/function and
   functiondrm_irq_uninstall/function functions. Those functions 
only
-  support a single interrupt per device.
+  support a single interrupt per device, devices that use more than one
+  IRQs need to be handled manually.
 /para
   !--!Fdrivers/char/drm/drm_irq.c drm_irq_install--
 para
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Lucas Stach]

Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae:
 
  -Original Message-
  From: Lucas Stach [mailto:l.st...@pengutronix.de]
  Sent: Wednesday, June 19, 2013 7:22 PM
  To: Inki Dae
  Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
  mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
  ker...@lists.infradead.org; linux-me...@vger.kernel.org
  Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
  framework
  
  Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
  
-Original Message-
From: Lucas Stach [mailto:l.st...@pengutronix.de]
Sent: Tuesday, June 18, 2013 6:47 PM
To: Inki Dae
Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
ker...@lists.infradead.org; linux-me...@vger.kernel.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
  synchronization
framework
   
Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
[...]

  a display device driver.  It shouldn't be used within a single
  driver
  as a means of passing buffers between userspace and kernel space.

 What I try to do is not really such ugly thing. What I try to do is
  to
 notify that, when CPU tries to access a buffer , to kernel side
  through
 dmabuf interface. So it's not really to send the buffer to kernel.

 Thanks,
 Inki Dae

The most basic question about why you are trying to implement this
  sort
of thing in the dma_buf framework still stands.
   
Once you imported a dma_buf into your DRM driver it's a GEM object and
you can and should use the native DRM ioctls to prepare/end a CPU
  access
to this BO. Then internally to your driver you can use the dma_buf
reservation/fence stuff to provide the necessary cross-device sync.
   
  
   I don't really want that is used only for DRM drivers. We really need
   it for all other DMA devices; i.e., v4l2 based drivers. That is what I
   try to do. And my approach uses reservation to use dma-buf resources
   but not dma fence stuff anymore. However, I'm looking into Radeon DRM
   driver for why we need dma fence stuff, and how we can use it if
   needed.
  
  
  Still I don't see the point why you need syncpoints above dma-buf. In
  both the DRM and the V4L2 world we have defined points in the API where
  a buffer is allowed to change domain from device to CPU and vice versa.
  
  In DRM if you want to access a buffer with the CPU you do a cpu_prepare.
  The buffer changes back to GPU domain once you do the execbuf
  validation, queue a pageflip to the buffer or similar things.
  
  In V4L2 the syncpoints for cache operations are the queue/dequeue API
  entry points. Those are also the exact points to synchronize with other
  hardware thus using dma-buf reserve/fence.
 
 
 If so, what if we want to access a buffer with the CPU _in V4L2_? We
 should open a drm device node, and then do a cpu_prepare? 
 
Not at all. As I said the syncpoints are the queue/dequeue operations.
When dequeueing a buffer you are explicitly dragging the buffer domain
back from device into userspace and thus CPU domain.

If you are operating on an mmap of a V4L2 processed buffer it's either
before or after it got processed by the hardware and therefore all DMA
operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls.
That is where cache operations and synchronization should happen. The
V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it
back into CPU domain while there is still DMA ongoing. Equally the queue
ioctrl should make sure caches are properly written back to memory. The
results of reading/writing to the mmap of a V4L2 buffer while it is
enqueued to the hardware is simply undefined and there is nothing
suggesting that this is a valid usecase.

Regards,
Lucas

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: update lockup tracking when scheduling in empty ring

[j . glisse]

From: Jerome Glisse jgli...@redhat.com

There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.

Signed-off-by: Jerome Glisse jgli...@redhat.com
Tested-by: Andy Lutomirski l...@amacapital.net
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index e17faa7..82434018 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct 
radeon_ring *ring, unsi
return -ENOMEM;
/* Align requested size with padding so unlock_commit can
 * pad safely */
+   radeon_ring_free_size(rdev, ring);
+   if (ring-ring_free_dw == (ring-ring_size / 4)) {
+   /* This is an empty ring update lockup info to avoid
+* false positive.
+*/
+   radeon_ring_lockup_update(ring);
+   }
ndw = (ndw + ring-align_mask)  ~ring-align_mask;
while (ndw  (ring-ring_free_dw - 1)) {
radeon_ring_free_size(rdev, ring);
-- 
1.7.11.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=59761





--- Comment #2 from t3s...@mail.ru  2013-06-19 14:36:31 ---
Quite hard/time consuming for me at this point. But if no other options left, I
probably can try since this bug is quite annoying.

Right now I know that MESA 9.0.x has been working perfectly with that HD5770.
But MESA 9.1 and up (9.2 git, etc) are broken. This also seems to produce some
visually visible artifacts on textured objects in mentioned Ryzom game. Say,
metallic objects

However as for kernel itself - the problem is that kernel detects lock-up but
then EPIC FAILs when trying to reset GPU. 

I bet there should be no BUG: unable to handle kernel paging request at very
least. Then, kernel never manages to recover from this condition. Neither old
3.8 kernel, nor recent changed GPU reset code from 3.9/3.10 would work.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/shmobile: Drop usage of removed drm_plane enabled field

[Laurent Pinchart]

The enabled field has been removed from struct drm_plane. Don't use it
in the driver.

Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
 drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This fixes a compilation error in drm-next. I will send a pull request for the
shmob-drm patches by the end of the week.

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c 
b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
index 6898f6f..060ae03 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
@@ -166,7 +166,7 @@ void shmob_drm_plane_setup(struct drm_plane *plane)
 {
struct shmob_drm_plane *splane = to_shmob_plane(plane);
 
-   if (plane-fb == NULL || !plane-enabled)
+   if (plane-fb == NULL)
return;
 
__shmob_drm_plane_setup(splane, plane-fb);
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: update lockup tracking when scheduling in empty ring

[Christian König]

Am 19.06.2013 16:02, schrieb j.gli...@gmail.com:

From: Jerome Glisse jgli...@redhat.com

There might be issue with lockup detection when scheduling on an
empty ring that have been sitting idle for a while. Thus update
the lockup tracking data when scheduling new work in an empty ring.

Signed-off-by: Jerome Glisse jgli...@redhat.com
Tested-by: Andy Lutomirski l...@amacapital.net
Cc: sta...@vger.kernel.org


Reviewed-by: Christian König christian.koe...@amd.com


---
  drivers/gpu/drm/radeon/radeon_ring.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_ring.c 
b/drivers/gpu/drm/radeon/radeon_ring.c
index e17faa7..82434018 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -402,6 +402,13 @@ int radeon_ring_alloc(struct radeon_device *rdev, struct 
radeon_ring *ring, unsi
return -ENOMEM;
/* Align requested size with padding so unlock_commit can
 * pad safely */
+   radeon_ring_free_size(rdev, ring);
+   if (ring-ring_free_dw == (ring-ring_size / 4)) {
+   /* This is an empty ring update lockup info to avoid
+* false positive.
+*/
+   radeon_ring_lockup_update(ring);
+   }
ndw = (ndw + ring-align_mask)  ~ring-align_mask;
while (ndw  (ring-ring_free_dw - 1)) {
radeon_ring_free_size(rdev, ring);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Inki Dae]

2013/6/19 Lucas Stach l.st...@pengutronix.de

 Am Mittwoch, den 19.06.2013, 19:44 +0900 schrieb Inki Dae:
 
   -Original Message-
   From: Lucas Stach [mailto:l.st...@pengutronix.de]
   Sent: Wednesday, June 19, 2013 7:22 PM
   To: Inki Dae
   Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI
   mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
   ker...@lists.infradead.org; linux-me...@vger.kernel.org
   Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
 synchronization
   framework
  
   Am Mittwoch, den 19.06.2013, 14:45 +0900 schrieb Inki Dae:
   
 -Original Message-
 From: Lucas Stach [mailto:l.st...@pengutronix.de]
 Sent: Tuesday, June 18, 2013 6:47 PM
 To: Inki Dae
 Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park';
 'DRI
 mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm-
 ker...@lists.infradead.org; linux-me...@vger.kernel.org
 Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer
   synchronization
 framework

 Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae:
 [...]
 
   a display device driver.  It shouldn't be used within a single
   driver
   as a means of passing buffers between userspace and kernel
 space.
 
  What I try to do is not really such ugly thing. What I try to do
 is
   to
  notify that, when CPU tries to access a buffer , to kernel side
   through
  dmabuf interface. So it's not really to send the buffer to
 kernel.
 
  Thanks,
  Inki Dae
 
 The most basic question about why you are trying to implement this
   sort
 of thing in the dma_buf framework still stands.

 Once you imported a dma_buf into your DRM driver it's a GEM object
 and
 you can and should use the native DRM ioctls to prepare/end a CPU
   access
 to this BO. Then internally to your driver you can use the dma_buf
 reservation/fence stuff to provide the necessary cross-device sync.

   
I don't really want that is used only for DRM drivers. We really need
it for all other DMA devices; i.e., v4l2 based drivers. That is what
 I
try to do. And my approach uses reservation to use dma-buf resources
but not dma fence stuff anymore. However, I'm looking into Radeon DRM
driver for why we need dma fence stuff, and how we can use it if
needed.
   
  
   Still I don't see the point why you need syncpoints above dma-buf. In
   both the DRM and the V4L2 world we have defined points in the API where
   a buffer is allowed to change domain from device to CPU and vice versa.
  
   In DRM if you want to access a buffer with the CPU you do a
 cpu_prepare.
   The buffer changes back to GPU domain once you do the execbuf
   validation, queue a pageflip to the buffer or similar things.
  
   In V4L2 the syncpoints for cache operations are the queue/dequeue API
   entry points. Those are also the exact points to synchronize with other
   hardware thus using dma-buf reserve/fence.
 
 
  If so, what if we want to access a buffer with the CPU _in V4L2_? We
  should open a drm device node, and then do a cpu_prepare?
 
 Not at all. As I said the syncpoints are the queue/dequeue operations.
 When dequeueing a buffer you are explicitly dragging the buffer domain
 back from device into userspace and thus CPU domain.

 If you are operating on an mmap of a V4L2 processed buffer it's either
 before or after it got processed by the hardware and therefore all DMA
 operations on the buffer are bracketed by the V4L2 qbug/dqbuf ioctls.
 That is where cache operations and synchronization should happen. The
 V4L2 driver shouldn't allow you to dequeue a buffer and thus dragging it
 back into CPU domain while there is still DMA ongoing. Equally the queue
 ioctrl should make sure caches are properly written back to memory. The
 results of reading/writing to the mmap of a V4L2 buffer while it is
 enqueued to the hardware is simply undefined and there is nothing
 suggesting that this is a valid usecase.


Thanks to comments. However, that's not definitely my point, and you
just say the conventional way. My point is to more enhance the conventional
way.

The conventional way is (sorry but I'm not really a good painter) :

CPU - DMA,
ioctl(qbuf command)  ioctl(streamon)
   |  |
   |  |
qbuf  - syncpoint   start streaming - dma access

DMA accesses a queued buffer with start streaming if source and
destination queues are ready.

And DMA - CPU,
ioctl(dqbuf command)
  |
  |
dqbuf - syncpoint

Internally, dqbuf waits for until DMA opertion is completed. And if
completed then user process can access a dequeued buffer.


On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):

CPU - DMA,
ioctl(qbuf command)  

Re: [PATCH 1/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.

[J L]

On 13-06-17 09:19 AM, Julia Lemire wrote:

+static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode * 
mode,
+   int bits_per_pixel)
+{
+   uint64_t active_area, total_area, pixels_per_second;
+   uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
+
+   if(!mode-htotal || !mode-vtotal || !mode-clock)
+   return 0;
+
+   active_area = mode-hdisplay * mode-vdisplay;
+   total_area = mode-htotal * mode-vtotal;
+   pixels_per_second = active_area * mode-clock * 1000 / total_area;
+   return (uint32_t)(pixels_per_second * bytes_per_pixel * 100 / (1024));
+}
I found a bug while testing this on a 32-bit machine linked to the 
64-bit division.  Sorry.


--
Julia Lemire Jr. Eng./Ing.
Software Designer
Matrox Graphics Inc.
Phone : 514 822-6000 x7010
Email :julia.lem...@matrox.com

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63599

--- Comment #10 from Jerome Glisse gli...@freedesktop.org ---
What is the motherboard and cpu reference ?

AMD A4-3400 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63599] [r600][r600] GPU lockup CP stall (kernel 3.8, 3.9)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63599

--- Comment #11 from wojtek wojta...@wp.pl ---
Motherboard: Gigabyte Technology Co., Ltd. GA-A75M-UD2H/GA-A75M-UD2H, BIOS F5
11/03/2011

CPU: AMD A4-3400 APU with Radeon(tm) HD Graphics (fam: 12, model: 01, stepping:
00)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

Thanks Mr. Kim,

I will post v4 with aforesaid change.

regards,
Rahul Sharma.

On Wed, Jun 19, 2013 at 7:22 PM, Kukjin Kim kgene@samsung.com wrote:
 On 06/19/13 22:50, Kukjin Kim wrote:

 On 06/19/13 21:51, Rahul Sharma wrote:

 This patch renames the combatible strings for hdmi, mixer, ddc
 and hdmiphy. It follows the convention of using compatible string
 which represent the SoC in which the IP was added for the first
 time.

 Signed-off-by: Rahul Sharmarahul.sha...@samsung.com


 Acked-by: Kukjin Kim kgene@samsung.com


 Just one nit in subject:

 [PATCH] ARM: dts: . for exynos5250

 Thanks,

 - Kukjin

 ---
 arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
 arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

 diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
 b/arch/arm/boot/dts/cros5250-common.dtsi
 index 3f0239e..dc259e8b 100644
 --- a/arch/arm/boot/dts/cros5250-common.dtsi
 +++ b/arch/arm/boot/dts/cros5250-common.dtsi
 @@ -190,7 +190,7 @@
 samsung,i2c-max-bus-freq =66000;

 hdmiddc@50 {
 - compatible = samsung,exynos5-hdmiddc;
 + compatible = samsung,exynos4210-hdmiddc;
 reg =0x50;
 };
 };
 @@ -224,7 +224,7 @@
 samsung,i2c-max-bus-freq =378000;

 hdmiphy@38 {
 - compatible = samsung,exynos5-hdmiphy;
 + compatible = samsung,exynos4212-hdmiphy;
 reg =0x38;
 };
 };
 diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
 b/arch/arm/boot/dts/exynos5250-smdk5250.dts
 index 3e0c792..f320d7c 100644
 --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
 +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
 @@ -72,7 +72,7 @@
 samsung,i2c-max-bus-freq =66000;

 hdmiddc@50 {
 - compatible = samsung,exynos5-hdmiddc;
 + compatible = samsung,exynos4210-hdmiddc;
 reg =0x50;
 };
 };
 @@ -102,7 +102,7 @@
 samsung,i2c-max-bus-freq =66000;

 hdmiphy@38 {
 - compatible = samsung,exynos5-hdmiphy;
 + compatible = samsung,exynos4212-hdmiphy;
 reg =0x38;
 };
 };
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi
 b/arch/arm/boot/dts/exynos5250.dtsi
 index 0673524..2f7763b 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -601,7 +601,7 @@
 };

 hdmi {
 - compatible = samsung,exynos5-hdmi;
 + compatible = samsung,exynos4212-hdmi;
 reg =0x1453 0x7;
 interrupts =0 95 0;
 clocks =clock 333,clock 136,clock 137,
 @@ -611,7 +611,7 @@
 };

 mixer {
 - compatible = samsung,exynos5-mixer;
 + compatible = samsung,exynos5250-mixer;
 reg =0x1445 0x1;
 interrupts =0 94 0;
 };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64913

--- Comment #14 from Alex Deucher ag...@yahoo.com ---
I'd suggest sending it to the mailing list (mesa-...@lists.freedesktop.org).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Add support for exynos5420 mixer IP in the drm mixer driver.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 .../devicetree/bindings/video/exynos_mixer.txt |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c  |   49 +++-
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index a8b063f..c64ddc1 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible: value should be:
1) samsung,exynos4210-mixer
2) samsung,exynos5250-mixer
+   3) samsung,exynos5420-mixer
 
 - reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+   MXR_VER_128_0_0_184,
 };
 
 struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
val = (ctx-interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
 
-   /* choosing between porper HD and SD mode */
-   if (height = 480)
-   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height = 576)
-   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height = 720)
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height = 1080)
-   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
-   else
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   if (ctx-mxr_ver != MXR_VER_128_0_0_184) {
+   /* choosing between proper HD and SD mode */
+   if (height = 480)
+   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+   else if (height = 576)
+   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+   else if (height = 720)
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   else if (height = 1080)
+   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+   else
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   }
 
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
 }
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data-fb_width);
 
+   /* setup display size */
+   if (ctx-mxr_ver == MXR_VER_128_0_0_184 
+   win == MIXER_DEFAULT_WIN) {
+   val  = MXR_MXR_RES_HEIGHT(win_data-fb_height);
+   val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
+   mixer_reg_write(res, MXR_RESOLUTION, val);
+   }
+
val  = MXR_GRP_WH_WIDTH(win_data-crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data-crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
mixer_cfg_layer(ctx, win, true);
 
/* layer update mandatory for mixer 16.0.33.0 */
-   if (ctx-mxr_ver == MXR_VER_16_0_33_0)
+   if (ctx-mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx-mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
 
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
 
 static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
 {
+   struct mixer_context *mixer_ctx = ctx;
u32 w, h;
 
w = mode-hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
drm_display_mode *mode)
mode-hdisplay, mode-vdisplay, mode-vrefresh,
(mode-flags  DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
 
+   if (mixer_ctx-mxr_ver == MXR_VER_0_0_0_16 ||
+   mixer_ctx-mxr_ver == MXR_VER_128_0_0_184)
+   return 0;
+
if ((w = 464  w = 720  h = 261  h = 576) ||
(w = 1024  w = 1280  h = 576  h = 720) ||
(w = 1664  w = 1920  h = 936  h = 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
exynos_drm_hdmi_context *ctx,
return 0;
 }
 
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+   .version = MXR_VER_128_0_0_184,
+   .is_vp_enabled = 0,
+};
+
 static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @@ static struct platform_device_id 

[PATCH v3 0/3] exynos5420/hdmi: add support for hdmi subsystem

[Rahul Sharma]

Add support for exynos5420 hdmi subsystem. It adds compatible strings
for exynos5420 mixer and Changes the drivers as per IP modifications.

This set doesn't have changes for hdmiphy, which will posted
independently.

This set is based on drm-next branch of Inki Dae's tree at
http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git.

v3:
1) instead of replacing with old compatible strings, new ones are added
without removing the support for older ones.
2) removed patch drm/exynos: fix interlace resolutions for exynos5420 as
it is independently merged.

v2:
1)update device mixer tree binding document with samsung,exynos5420-mixer

Rahul Sharma (3):
  drm/exynos: add new compatible strings for hdmi subsystem
  drm/exynos: add support for exynos5420 mixer
  ARM/dts: change compatible strings for hdmi subsystem

 .../devicetree/bindings/video/exynos_hdmi.txt  |7 ++-
 .../devicetree/bindings/video/exynos_hdmiddc.txt   |7 ++-
 .../devicetree/bindings/video/exynos_hdmiphy.txt   |7 ++-
 .../devicetree/bindings/video/exynos_mixer.txt |9 ++-
 arch/arm/boot/dts/cros5250-common.dtsi |4 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +-
 arch/arm/boot/dts/exynos5250.dtsi  |4 +-
 drivers/gpu/drm/exynos/exynos_ddc.c|2 +
 drivers/gpu/drm/exynos/exynos_hdmi.c   |3 +
 drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 ++
 drivers/gpu/drm/exynos/exynos_mixer.c  |   62 ++--
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 12 files changed, 89 insertions(+), 31 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/3] drm/exynos: add new compatible strings for hdmi subsystem

[Rahul Sharma]

This patch adds new combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Drivers continue to support the previous compatible strings
but further addition of these compatible strings in device tree
is deprecated.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 Documentation/devicetree/bindings/video/exynos_hdmi.txt   |7 +--
 .../devicetree/bindings/video/exynos_hdmiddc.txt  |7 +--
 .../devicetree/bindings/video/exynos_hdmiphy.txt  |7 +--
 Documentation/devicetree/bindings/video/exynos_mixer.txt  |8 ++--
 drivers/gpu/drm/exynos/exynos_ddc.c   |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
 drivers/gpu/drm/exynos/exynos_hdmiphy.c   |4 
 drivers/gpu/drm/exynos/exynos_mixer.c |   13 -
 8 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..c71d0f0 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,10 @@
 Device-Tree bindings for drm hdmi driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-hdmi.
+- compatible: value should be one among the following:
+   1) samsung,exynos5-hdmi DEPRECATED
+   2) samsung,exynos4210-hdmi
+   3) samsung,exynos4212-hdmi
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -15,7 +18,7 @@ Required properties:
 Example:
 
hdmi {
-   compatible = samsung,exynos5-hdmi;
+   compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 0xf 1 3;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..41eee97 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,15 @@
 Device-Tree bindings for hdmiddc driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-hdmiddc.
+- compatible: value should be one of the following
+   1) samsung,exynos5-hdmiddc DEPRECATED
+   2) samsung,exynos4210-hdmiddc
+
 - reg: I2C address of the hdmiddc device.
 
 Example:
 
hdmiddc {
-   compatible = samsung,exynos5-hdmiddc;
+   compatible = samsung,exynos4210-hdmiddc;
reg = 0x50;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..162f641 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,15 @@
 Device-Tree bindings for hdmiphy driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-hdmiphy.
+- compatible: value should be one of the following:
+   1) samsung,exynos5-hdmiphy DEPRECATED
+   2) samsung,exynos4210-hdmiphy.
+   3) samsung,exynos4212-hdmiphy.
 - reg: I2C address of the hdmiphy device.
 
 Example:
 
hdmiphy {
-   compatible = samsung,exynos5-hdmiphy;
+   compatible = samsung,exynos4210-hdmiphy;
reg = 0x38;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..9131b99 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,11 @@
 Device-Tree bindings for mixer driver
 
 Required properties:
-- compatible: value should be samsung,exynos5-mixer.
+- compatible: value should be one of the following:
+   1) samsung,exynos5-mixer DEPRECATED
+   2) samsung,exynos4210-mixer
+   3) samsung,exynos5250-mixer
+
 - reg: physical base address of the mixer and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
@@ -9,7 +13,7 @@ Required properties:
 Example:
 
mixer {
-   compatible = samsung,exynos5-mixer;
+   compatible = samsung,exynos5250-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c 
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..95c75ed 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -53,6 +53,8 @@ static struct of_device_id hdmiddc_match_types[] = {
{
.compatible = samsung,exynos5-hdmiddc,

[PATCH v3 2/3] drm/exynos: add support for exynos5420 mixer

[Rahul Sharma]

Add support for exynos5420 mixer IP in the drm mixer driver.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 .../devicetree/bindings/video/exynos_mixer.txt |1 +
 drivers/gpu/drm/exynos/exynos_mixer.c  |   49 +++-
 drivers/gpu/drm/exynos/regs-mixer.h|7 +++
 3 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9131b99..3334b0a 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -5,6 +5,7 @@ Required properties:
1) samsung,exynos5-mixer DEPRECATED
2) samsung,exynos4210-mixer
3) samsung,exynos5250-mixer
+   4) samsung,exynos5420-mixer
 
 - reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6225501..b1280b4 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
 enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+   MXR_VER_128_0_0_184,
 };
 
 struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
val = (ctx-interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
 
-   /* choosing between porper HD and SD mode */
-   if (height = 480)
-   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height = 576)
-   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height = 720)
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height = 1080)
-   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
-   else
-   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   if (ctx-mxr_ver != MXR_VER_128_0_0_184) {
+   /* choosing between proper HD and SD mode */
+   if (height = 480)
+   val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+   else if (height = 576)
+   val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+   else if (height = 720)
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   else if (height = 1080)
+   val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+   else
+   val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+   }
 
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
 }
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data-fb_width);
 
+   /* setup display size */
+   if (ctx-mxr_ver == MXR_VER_128_0_0_184 
+   win == MIXER_DEFAULT_WIN) {
+   val  = MXR_MXR_RES_HEIGHT(win_data-fb_height);
+   val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
+   mixer_reg_write(res, MXR_RESOLUTION, val);
+   }
+
val  = MXR_GRP_WH_WIDTH(win_data-crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data-crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
int win)
mixer_cfg_layer(ctx, win, true);
 
/* layer update mandatory for mixer 16.0.33.0 */
-   if (ctx-mxr_ver == MXR_VER_16_0_33_0)
+   if (ctx-mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx-mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
 
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
 
 static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
 {
+   struct mixer_context *mixer_ctx = ctx;
u32 w, h;
 
w = mode-hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
drm_display_mode *mode)
mode-hdisplay, mode-vdisplay, mode-vrefresh,
(mode-flags  DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
 
+   if (mixer_ctx-mxr_ver == MXR_VER_0_0_0_16 ||
+   mixer_ctx-mxr_ver == MXR_VER_128_0_0_184)
+   return 0;
+
if ((w = 464  w = 720  h = 261  h = 576) ||
(w = 1024  w = 1280  h = 576  h = 720) ||
(w = 1664  w = 1920  h = 936  h = 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
exynos_drm_hdmi_context *ctx,
return 0;
 }
 
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+   .version = MXR_VER_128_0_0_184,
+   .is_vp_enabled = 0,
+};
+
 static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1145,6 +1167,9 @@ static struct of_device_id 

[PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Rahul Sharma]

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
 arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
 arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
 arch/arm/boot/dts/exynos5250.dtsi |4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi 
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq = 66000;
 
hdmiddc@50 {
-   compatible = samsung,exynos5-hdmiddc;
+   compatible = samsung,exynos4210-hdmiddc;
reg = 0x50;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq = 378000;
 
hdmiphy@38 {
-   compatible = samsung,exynos5-hdmiphy;
+   compatible = samsung,exynos4212-hdmiphy;
reg = 0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq = 66000;
 
hdmiddc@50 {
-   compatible = samsung,exynos5-hdmiddc;
+   compatible = samsung,exynos4210-hdmiddc;
reg = 0x50;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq = 66000;
 
hdmiphy@38 {
-   compatible = samsung,exynos5-hdmiphy;
+   compatible = samsung,exynos4212-hdmiphy;
reg = 0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
 
hdmi {
-   compatible = samsung,exynos5-hdmi;
+   compatible = samsung,exynos4212-hdmi;
reg = 0x1453 0x7;
interrupts = 0 95 0;
clocks = clock 333, clock 136, clock 137,
@@ -611,7 +611,7 @@
};
 
mixer {
-   compatible = samsung,exynos5-mixer;
+   compatible = samsung,exynos5250-mixer;
reg = 0x1445 0x1;
interrupts = 0 94 0;
};
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] ARM/dts: change compatible strings for hdmi subsystem

[Kukjin Kim]

On 06/19/13 22:50, Kukjin Kim wrote:

On 06/19/13 21:51, Rahul Sharma wrote:

This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.

Signed-off-by: Rahul Sharmarahul.sha...@samsung.com


Acked-by: Kukjin Kim kgene@samsung.com



Just one nit in subject:

[PATCH] ARM: dts: . for exynos5250

Thanks,
- Kukjin


---
arch/arm/boot/dts/cros5250-common.dtsi | 4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts | 4 ++--
arch/arm/boot/dts/exynos5250.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq =66000;

hdmiddc@50 {
- compatible = samsung,exynos5-hdmiddc;
+ compatible = samsung,exynos4210-hdmiddc;
reg =0x50;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq =378000;

hdmiphy@38 {
- compatible = samsung,exynos5-hdmiphy;
+ compatible = samsung,exynos4212-hdmiphy;
reg =0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq =66000;

hdmiddc@50 {
- compatible = samsung,exynos5-hdmiddc;
+ compatible = samsung,exynos4210-hdmiddc;
reg =0x50;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq =66000;

hdmiphy@38 {
- compatible = samsung,exynos5-hdmiphy;
+ compatible = samsung,exynos4212-hdmiphy;
reg =0x38;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};

hdmi {
- compatible = samsung,exynos5-hdmi;
+ compatible = samsung,exynos4212-hdmi;
reg =0x1453 0x7;
interrupts =0 95 0;
clocks =clock 333,clock 136,clock 137,
@@ -611,7 +611,7 @@
};

mixer {
- compatible = samsung,exynos5-mixer;
+ compatible = samsung,exynos5250-mixer;
reg =0x1445 0x1;
interrupts =0 94 0;
};

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem

[Kukjin Kim]

On 06/19/13 13:04, Rahul Sharma wrote:

+ mike

Mike, I'm waiting for your reply on this. If you're OK, let me take this 
series on top of exynos5420 stuff in samsung tree.


Of course, if any concerns, please let me know.

Thanks,
- Kukjin


On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharmarahul.sha...@samsung.com  wrote:

Add clock changes for hdmi subsystem for exynos5250 SoC. These
include addition of new clocks like mout_hdmi and smmu_tv, associating
ID to clk_hdmiphy and some essential corrections.

This set is based on kukjin's for-next branch at
http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

This set dependents on the following patches which add support for Exynos5420
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html

Rahul Sharma (5):
   clk/exynos5420: add sclk_hdmiphy to the list of special clocks
   clk/exynos5420: add gate clock for tv sysmmu
   clk/exynos5420: fix the order of parents of hdmi mux
   clk/exynos5420: add hdmi mux to change parents in hdmi driver
   clk/exynos5420: assign sclk_pixel id to pixel clock divider

  .../devicetree/bindings/clock/exynos5420-clock.txt   |7 +++
  drivers/clk/samsung/clk-exynos5420.c |   18 +++---
  2 files changed, 18 insertions(+), 7 deletions(-)

--
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework

[Russell King - ARM Linux]

On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
 On the other hand, the below shows how we could enhance the conventional
 way with my approach (just example):
 
 CPU - DMA,
 ioctl(qbuf command)  ioctl(streamon)
   |   |
   |   |
 qbuf  - dma_buf_sync_get   start streaming - syncpoint
 
 dma_buf_sync_get just registers a sync buffer(dmabuf) to sync object. And
 the syncpoint is performed by calling dma_buf_sync_lock(), and then DMA
 accesses the sync buffer.
 
 And DMA - CPU,
 ioctl(dqbuf command)
   |
   |
 dqbuf - nothing to do
 
 Actual syncpoint is when DMA operation is completed (in interrupt handler):
 the syncpoint is performed by calling dma_buf_sync_unlock().
 Hence,  my approach is to move the syncpoints into just before dma access
 as long as possible.

What you've just described does *not* work on architectures such as
ARMv7 which do speculative cache fetches from memory at any time that
that memory is mapped with a cacheable status, and will lead to data
corruption.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: add hotspot support for cursors.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

So it looks like for virtual hw cursors on QXL we need to inform
the hw device what the cursor hotspot parameters are. This
makes sense if you think the host has to draw the cursor and interpret
clicks from it. However the current modesetting interface doesn't support
passing the hotspot information from userspace.

This implements a new cursor ioctl, that takes the hotspot info as well,
userspace can try calling the new interface and if it -ENOSYS, can just
fallback to the old non-hotspot interface.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_crtc.c  | 35 +--
 drivers/gpu/drm/drm_drv.c   |  1 +
 include/drm/drm_crtc.h  |  5 +
 include/uapi/drm/drm.h  |  1 +
 include/uapi/drm/drm_mode.h | 13 +
 5 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e7e9242..cc9eada 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2099,10 +2099,10 @@ out:
return ret;
 }
 
-int drm_mode_cursor_ioctl(struct drm_device *dev,
-   void *data, struct drm_file *file_priv)
+static int drm_mode_cursor_common(struct drm_device *dev,
+ struct drm_mode_cursor2 *req,
+ struct drm_file *file_priv)
 {
-   struct drm_mode_cursor *req = data;
struct drm_mode_object *obj;
struct drm_crtc *crtc;
int ret = 0;
@@ -2122,13 +2122,17 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
 
mutex_lock(crtc-mutex);
if (req-flags  DRM_MODE_CURSOR_BO) {
-   if (!crtc-funcs-cursor_set) {
+   if (!crtc-funcs-cursor_set  !crtc-funcs-cursor_set2) {
ret = -ENXIO;
goto out;
}
/* Turns off the cursor if handle is 0 */
-   ret = crtc-funcs-cursor_set(crtc, file_priv, req-handle,
- req-width, req-height);
+   if (crtc-funcs-cursor_set2)
+   ret = crtc-funcs-cursor_set2(crtc, file_priv, 
req-handle,
+ req-width, req-height, 
req-hot_x, req-hot_y);
+   else
+   ret = crtc-funcs-cursor_set(crtc, file_priv, 
req-handle,
+ req-width, req-height);
}
 
if (req-flags  DRM_MODE_CURSOR_MOVE) {
@@ -2143,6 +2147,25 @@ out:
mutex_unlock(crtc-mutex);
 
return ret;
+
+}
+int drm_mode_cursor_ioctl(struct drm_device *dev,
+   void *data, struct drm_file *file_priv)
+{
+   struct drm_mode_cursor *req = data;
+   struct drm_mode_cursor2 new_req;
+
+   memcpy(new_req, req, sizeof(struct drm_mode_cursor));
+   new_req.hot_x = new_req.hot_y = 0;
+
+   return drm_mode_cursor_common(dev, new_req, file_priv);
+}
+
+int drm_mode_cursor2_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file_priv)
+{
+   struct drm_mode_cursor2 *req = data;
+   return drm_mode_cursor_common(dev, req, file_priv);
 }
 
 /* Original addfb only supported RGB formats, so figure out which one */
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9cc247f..99fcd7c 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -166,6 +166,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES, 
drm_mode_obj_get_properties_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY, 
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR2, drm_mode_cursor2_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adb3f9b..093c030 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -339,6 +339,9 @@ struct drm_crtc_funcs {
/* cursor controls */
int (*cursor_set)(struct drm_crtc *crtc, struct drm_file *file_priv,
  uint32_t handle, uint32_t width, uint32_t height);
+   int (*cursor_set2)(struct drm_crtc *crtc, struct drm_file *file_priv,
+  uint32_t handle, uint32_t width, uint32_t height,
+  int32_t hot_x, int32_t hot_y);
int (*cursor_move)(struct drm_crtc *crtc, int x, int y);
 
/* Set gamma on the CRTC */
@@ -1022,6 +1025,8 @@ extern int drm_mode_setplane(struct drm_device *dev,
   void *data, struct drm_file *file_priv);
 extern int 

[PATCH 2/2] drm/qxl: add support for cursor hotspot.

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This uses the cursor hotspot info from userspace and passes
it to the qxl hw layer.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/qxl/qxl_display.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 823d29e..489e879 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -255,11 +255,11 @@ qxl_hide_cursor(struct qxl_device *qdev)
qxl_release_unreserve(qdev, release);
 }
 
-static int qxl_crtc_cursor_set(struct drm_crtc *crtc,
-  struct drm_file *file_priv,
-  uint32_t handle,
-  uint32_t width,
-  uint32_t height)
+static int qxl_crtc_cursor_set2(struct drm_crtc *crtc,
+   struct drm_file *file_priv,
+   uint32_t handle,
+   uint32_t width,
+   uint32_t height, int32_t hot_x, int32_t hot_y)
 {
struct drm_device *dev = crtc-dev;
struct qxl_device *qdev = dev-dev_private;
@@ -315,8 +315,8 @@ static int qxl_crtc_cursor_set(struct drm_crtc *crtc,
cursor-header.type = SPICE_CURSOR_TYPE_ALPHA;
cursor-header.width = 64;
cursor-header.height = 64;
-   cursor-header.hot_spot_x = 0;
-   cursor-header.hot_spot_y = 0;
+   cursor-header.hot_spot_x = hot_x;
+   cursor-header.hot_spot_y = hot_y;
cursor-data_size = size;
cursor-chunk.next_chunk = 0;
cursor-chunk.prev_chunk = 0;
@@ -397,7 +397,7 @@ static int qxl_crtc_cursor_move(struct drm_crtc *crtc,
 
 
 static const struct drm_crtc_funcs qxl_crtc_funcs = {
-   .cursor_set = qxl_crtc_cursor_set,
+   .cursor_set2 = qxl_crtc_cursor_set2,
.cursor_move = qxl_crtc_cursor_move,
.gamma_set = qxl_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
-- 
1.8.2.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm/exynos: add support for exynos5420 mixer

[김승우]

Hello Rahul,

This patch is exactly same with v2 2/4 and only rebased on v3 1/3, so my
ack is valid for this patch.

On 2013년 06월 19일 21:51, Rahul Sharma wrote:
 Add support for exynos5420 mixer IP in the drm mixer driver.
 
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

Acked-by: Seung-Woo Kim sw0312@samsung.com

Anyway, this patch can be merged after merging [Patch v3 1/3] as like v2.

Best Regards,
- Seung-Woo Kim

 ---
  .../devicetree/bindings/video/exynos_mixer.txt |1 +
  drivers/gpu/drm/exynos/exynos_mixer.c  |   49 
 +++-
  drivers/gpu/drm/exynos/regs-mixer.h|7 +++
  3 files changed, 45 insertions(+), 12 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
 b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 index 9131b99..3334b0a 100644
 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
 @@ -5,6 +5,7 @@ Required properties:
   1) samsung,exynos5-mixer DEPRECATED
   2) samsung,exynos4210-mixer
   3) samsung,exynos5250-mixer
 + 4) samsung,exynos5420-mixer
  
  - reg: physical base address of the mixer and length of memory mapped
   region.
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 6225501..b1280b4 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -78,6 +78,7 @@ struct mixer_resources {
  enum mixer_version_id {
   MXR_VER_0_0_0_16,
   MXR_VER_16_0_33_0,
 + MXR_VER_128_0_0_184,
  };
  
  struct mixer_context {
 @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
 unsigned int height)
   val = (ctx-interlace ? MXR_CFG_SCAN_INTERLACE :
   MXR_CFG_SCAN_PROGRASSIVE);
  
 - /* choosing between porper HD and SD mode */
 - if (height = 480)
 - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
 - else if (height = 576)
 - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
 - else if (height = 720)
 - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 - else if (height = 1080)
 - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
 - else
 - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 + if (ctx-mxr_ver != MXR_VER_128_0_0_184) {
 + /* choosing between proper HD and SD mode */
 + if (height = 480)
 + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
 + else if (height = 576)
 + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
 + else if (height = 720)
 + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 + else if (height = 1080)
 + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
 + else
 + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
 + }
  
   mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
  }
 @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context 
 *ctx, int win)
   /* setup geometry */
   mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data-fb_width);
  
 + /* setup display size */
 + if (ctx-mxr_ver == MXR_VER_128_0_0_184 
 + win == MIXER_DEFAULT_WIN) {
 + val  = MXR_MXR_RES_HEIGHT(win_data-fb_height);
 + val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
 + mixer_reg_write(res, MXR_RESOLUTION, val);
 + }
 +
   val  = MXR_GRP_WH_WIDTH(win_data-crtc_width);
   val |= MXR_GRP_WH_HEIGHT(win_data-crtc_height);
   val |= MXR_GRP_WH_H_SCALE(x_ratio);
 @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
 int win)
   mixer_cfg_layer(ctx, win, true);
  
   /* layer update mandatory for mixer 16.0.33.0 */
 - if (ctx-mxr_ver == MXR_VER_16_0_33_0)
 + if (ctx-mxr_ver == MXR_VER_16_0_33_0 ||
 + ctx-mxr_ver == MXR_VER_128_0_0_184)
   mixer_layer_update(ctx);
  
   mixer_run(ctx);
 @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
  
  static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
  {
 + struct mixer_context *mixer_ctx = ctx;
   u32 w, h;
  
   w = mode-hdisplay;
 @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct 
 drm_display_mode *mode)
   mode-hdisplay, mode-vdisplay, mode-vrefresh,
   (mode-flags  DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
  
 + if (mixer_ctx-mxr_ver == MXR_VER_0_0_0_16 ||
 + mixer_ctx-mxr_ver == MXR_VER_128_0_0_184)
 + return 0;
 +
   if ((w = 464  w = 720  h = 261  h = 576) ||
   (w = 1024  w = 1280  h = 576  h = 720) ||
   (w = 1664  w = 1920  h = 936  h = 1080))
 @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct 
 exynos_drm_hdmi_context *ctx,
   return 0;
  }