[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

[Inki Dae]

Hi Javier,

2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas :
> Hello Inki,
>
> On 12/04/2015 06:00 AM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
>>> Hello Inki,
>>>
>>> I found that v2 of this patch is alredy in your exynos-drm for-next branch 
>>> so
>>> so I had to revert it in linux-next to apply this one to test. You shouldn't
>>> push patches that were still not reviewed (specially the ones that weren't
>>> tested like this one) to your branch that gets pulled by -next. The idea of
>>> -next is to have some test coverage but it should be as stable as possible.
>>
>> exynos-drm/for-next branch is not really for-next branch. This branch is used
>
> Well, it is a for-next branch because is pulled by -next. It is listed in:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees
>
> drm-exynos  git 
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next
>
>> only for integration test. As you know, there are many exynos maintainers
>> and they have their own repository. So we would need to test the integration.
>
> Integration testing is of course very needed and linux-next is for that but
> what should be tested are the patches that are targeted to mainline.
>
>> For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
>> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed 
>> and
>> tested patches will be merged to exynos-drm-next.
>>
>
> In that case, exynos-drm-next is what should be pulled by linux-next, no the
> for-next branch. Linux-next is a simulation of what Torvalds would do next
> so problems are found earlier, ideally before the patches land into mainline.

Seems I didn't comment enough. exynos-drm/for-next branch includes all
patches of exynos-drm-next
and actually, they keep same patches for most time but sometimes, I
merge additional patches only to
exynos-drm/for-next, which should be more tested with other trees
before going to Dave's tree.

One more thing, there is other difference between exynos-drm-next and
exynos-drm/for-next.
That is all patches of exynos-drm-next are merged on top of based on
Dave's drm-next branch.
On the other hand, all of exynos-drm/for-next are merged on top of
mainline. So if exynos-drm-next
is merged to linux-next then all patches will be conflicted with
Dave's tree because his branch
is also merged to linux-next.

I'm not sure that other maintainers always keep only the for-next
branch in their repository but
in my case, I use exynos-drm/for-next branch for the test before going
to drm-next.
Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree
will also be pulled by
linux-next, which would allow exynos-drm-next to be tested altogether
again before going to mainline.

Thanks,
Inki Dae

>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] radeon: Fix VCE IB test on Big-Endian systems

[Oded Gabbay]

This patch makes the VCE IB test pass on Big-Endian systems. It converts
to little-endian the contents of the VCE message.

Signed-off-by: Oded Gabbay 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_vce.c | 68 ++---
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index 86f57e4..7eb1ae7 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -361,31 +361,31 @@ int radeon_vce_get_create_msg(struct radeon_device *rdev, 
int ring,

/* stitch together an VCE create msg */
ib.length_dw = 0;
-   ib.ptr[ib.length_dw++] = 0x000c; /* len */
-   ib.ptr[ib.length_dw++] = 0x0001; /* session cmd */
-   ib.ptr[ib.length_dw++] = handle;
-
-   ib.ptr[ib.length_dw++] = 0x0030; /* len */
-   ib.ptr[ib.length_dw++] = 0x0101; /* create cmd */
-   ib.ptr[ib.length_dw++] = 0x;
-   ib.ptr[ib.length_dw++] = 0x0042;
-   ib.ptr[ib.length_dw++] = 0x000a;
-   ib.ptr[ib.length_dw++] = 0x0001;
-   ib.ptr[ib.length_dw++] = 0x0080;
-   ib.ptr[ib.length_dw++] = 0x0060;
-   ib.ptr[ib.length_dw++] = 0x0100;
-   ib.ptr[ib.length_dw++] = 0x0100;
-   ib.ptr[ib.length_dw++] = 0x000c;
-   ib.ptr[ib.length_dw++] = 0x;
-
-   ib.ptr[ib.length_dw++] = 0x0014; /* len */
-   ib.ptr[ib.length_dw++] = 0x0505; /* feedback buffer */
-   ib.ptr[ib.length_dw++] = upper_32_bits(dummy);
-   ib.ptr[ib.length_dw++] = dummy;
-   ib.ptr[ib.length_dw++] = 0x0001;
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x000c); /* len */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0001); /* session cmd */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(handle);
+
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0030); /* len */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0101); /* create cmd */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0042);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x000a);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0001);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0080);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0060);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0100);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0100);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x000c);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x);
+
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0014); /* len */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0505); /* feedback buffer */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(upper_32_bits(dummy));
+   ib.ptr[ib.length_dw++] = cpu_to_le32(dummy);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0001);

for (i = ib.length_dw; i < ib_size_dw; ++i)
-   ib.ptr[i] = 0x0;
+   ib.ptr[i] = cpu_to_le32(0x0);

r = radeon_ib_schedule(rdev, &ib, NULL, false);
if (r) {
@@ -428,21 +428,21 @@ int radeon_vce_get_destroy_msg(struct radeon_device 
*rdev, int ring,

/* stitch together an VCE destroy msg */
ib.length_dw = 0;
-   ib.ptr[ib.length_dw++] = 0x000c; /* len */
-   ib.ptr[ib.length_dw++] = 0x0001; /* session cmd */
-   ib.ptr[ib.length_dw++] = handle;
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x000c); /* len */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0001); /* session cmd */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(handle);

-   ib.ptr[ib.length_dw++] = 0x0014; /* len */
-   ib.ptr[ib.length_dw++] = 0x0505; /* feedback buffer */
-   ib.ptr[ib.length_dw++] = upper_32_bits(dummy);
-   ib.ptr[ib.length_dw++] = dummy;
-   ib.ptr[ib.length_dw++] = 0x0001;
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0014); /* len */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0505); /* feedback buffer */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(upper_32_bits(dummy));
+   ib.ptr[ib.length_dw++] = cpu_to_le32(dummy);
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0001);

-   ib.ptr[ib.length_dw++] = 0x0008; /* len */
-   ib.ptr[ib.length_dw++] = 0x0201; /* destroy cmd */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0008); /* len */
+   ib.ptr[ib.length_dw++] = cpu_to_le32(0x0201); /* destroy cmd */

for (i = ib.length_dw; i < ib_size_dw; ++i)
-   ib.ptr[i] = 0x0;
+   ib.ptr[i] = cpu_to_le32(0x0);

r = radeon_ib_schedule(rdev, &ib, NULL, false);
if (r) {
-- 
2.5.0

[PATCH 2/3] radeon: Fix VCE ring test for Big-Endian systems

[Oded Gabbay]

This patch fixes the VCE ring test when running on Big-Endian machines.
Every write to the ring needs to be translated to little-endian.

Signed-off-by: Oded Gabbay 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_vce.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vce.c 
b/drivers/gpu/drm/radeon/radeon_vce.c
index 574f62b..86f57e4 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -699,12 +699,12 @@ bool radeon_vce_semaphore_emit(struct radeon_device *rdev,
 {
uint64_t addr = semaphore->gpu_addr;

-   radeon_ring_write(ring, VCE_CMD_SEMAPHORE);
-   radeon_ring_write(ring, (addr >> 3) & 0x000F);
-   radeon_ring_write(ring, (addr >> 23) & 0x000F);
-   radeon_ring_write(ring, 0x01003000 | (emit_wait ? 1 : 0));
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_SEMAPHORE));
+   radeon_ring_write(ring, cpu_to_le32((addr >> 3) & 0x000F));
+   radeon_ring_write(ring, cpu_to_le32((addr >> 23) & 0x000F));
+   radeon_ring_write(ring, cpu_to_le32(0x01003000 | (emit_wait ? 1 : 0)));
if (!emit_wait)
-   radeon_ring_write(ring, VCE_CMD_END);
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_END));

return true;
 }
@@ -719,10 +719,10 @@ bool radeon_vce_semaphore_emit(struct radeon_device *rdev,
 void radeon_vce_ib_execute(struct radeon_device *rdev, struct radeon_ib *ib)
 {
struct radeon_ring *ring = &rdev->ring[ib->ring];
-   radeon_ring_write(ring, VCE_CMD_IB);
-   radeon_ring_write(ring, ib->gpu_addr);
-   radeon_ring_write(ring, upper_32_bits(ib->gpu_addr));
-   radeon_ring_write(ring, ib->length_dw);
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_IB));
+   radeon_ring_write(ring, cpu_to_le32(ib->gpu_addr));
+   radeon_ring_write(ring, cpu_to_le32(upper_32_bits(ib->gpu_addr)));
+   radeon_ring_write(ring, cpu_to_le32(ib->length_dw));
 }

 /**
@@ -738,12 +738,12 @@ void radeon_vce_fence_emit(struct radeon_device *rdev,
struct radeon_ring *ring = &rdev->ring[fence->ring];
uint64_t addr = rdev->fence_drv[fence->ring].gpu_addr;

-   radeon_ring_write(ring, VCE_CMD_FENCE);
-   radeon_ring_write(ring, addr);
-   radeon_ring_write(ring, upper_32_bits(addr));
-   radeon_ring_write(ring, fence->seq);
-   radeon_ring_write(ring, VCE_CMD_TRAP);
-   radeon_ring_write(ring, VCE_CMD_END);
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_FENCE));
+   radeon_ring_write(ring, cpu_to_le32(addr));
+   radeon_ring_write(ring, cpu_to_le32(upper_32_bits(addr)));
+   radeon_ring_write(ring, cpu_to_le32(fence->seq));
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_TRAP));
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_END));
 }

 /**
@@ -765,7 +765,7 @@ int radeon_vce_ring_test(struct radeon_device *rdev, struct 
radeon_ring *ring)
  ring->idx, r);
return r;
}
-   radeon_ring_write(ring, VCE_CMD_END);
+   radeon_ring_write(ring, cpu_to_le32(VCE_CMD_END));
radeon_ring_unlock_commit(rdev, ring, false);

for (i = 0; i < rdev->usec_timeout; i++) {
-- 
2.5.0

[PATCH 1/3] radeon/cik: Fix GFX IB test on Big-Endian

[Oded Gabbay]

This patch makes the IB test on the GFX ring pass for CI-based cards
installed in Big-Endian machines.

Signed-off-by: Oded Gabbay 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 248953d..05d43a0 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4173,11 +4173,7 @@ void cik_ring_ib_execute(struct radeon_device *rdev, 
struct radeon_ib *ib)
control |= ib->length_dw | (vm_id << 24);

radeon_ring_write(ring, header);
-   radeon_ring_write(ring,
-#ifdef __BIG_ENDIAN
- (2 << 0) |
-#endif
- (ib->gpu_addr & 0xFFFC));
+   radeon_ring_write(ring, (ib->gpu_addr & 0xFFFC));
radeon_ring_write(ring, upper_32_bits(ib->gpu_addr) & 0x);
radeon_ring_write(ring, control);
 }
-- 
2.5.0

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>  wrote:
> > Moreover, DRI3 is not yet available for Gallium, so if we're talking
> > about Xorg, then functional DRI2 is a requirement, and that _needs_
> > to have a single device for the rendering instances.  Xorg has no way
> > to pass multiple render nodes to client over DRI2.
> 
> Just to correct... DRI3 has been available on gallium [at least in the
> context of st/mesa] basically since DRI3 was introduced. Not sure what
> issue you're fighting with, but it's definitely not a gallium
> limitation... could be something related to platform devices.

Well, my statement is based on the fact that there's nothing in
src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
implemented differently, I don't know.  I never wanted to hack MESA -
I'm supposed to be the ARM kernel maintainer - and I'm still very new
to MESA.

I think it's a DRI3 limitation.  The issue with the DRI3 design is that:

* The client has access to the GPU render nodes only, but not the
  corresponding KMS node.
* Buffers in DRI3 are allocated from the GPU render nodes.
* The Xorg Present protocol is then used to manage the vblank
  synchonisation and page flips.

Now, the KMS scanout hardware typically does not support any kind of
scatter-gather: the buffers it has must be contiguous.  These can be
allocated from the KMS DRM device.

However, the DRI3 client has no access to the KMS DRM device to allocate
linear buffers from, and GPUs typically don't have dumb buffer support.
Hence, the client can't pass a suitable buffer to the present layer.

Hence, I can see no way for the resource_create() to be able to allocate
any kind of scanout capable buffer.

That's a separate issue though: you've pointed out that you can select
which render node to use: what if we want to use multiple render nodes
simultaneously - eg, because we want to use multiple 3D GPU cores
together?  How does that work with stuff?

I think the idea that individual GPU cores should be exposed as
separate DRM devices is fundamentally flawed, and adds a hell of a
lot of complexity.

In any case, I've spent _way_ too much time on etnaviv during November -
quite literally almost every day (I worked out that I was producing 4.5
patches a day during November for Etnaviv MESA.)  I'm afraid that it's
now time that I switch my attention elsewhere, so if this means that
Etnaviv is rejected for merging, I'm afraid it'll be a few months before
I can get back to it.

It would have been nice if these issues had been brought up much earlier,
during the RFC posting of the patches.  These are nothing new, and I now
feel that this whole thing has been a total waste of time.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Daniel Vetter]

On Fri, Dec 04, 2015 at 08:31:01PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
> > On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach  
> > wrote:
> > > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> > >> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
> > >> wrote:
> > >> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > >> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > >> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
> > >> >> > master device node to bind all the individual GPU cores together
> > >> >> > into one DRM device.
> > >> >> >
> > >> >> > Signed-off-by: Lucas Stach 
> > >> >> > ---
> > >> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> > >> >> > ++
> > >> >> >  1 file changed, 46 insertions(+)
> > >> >> >  create mode 100644 
> > >> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > >> >> >
> > >> >> > diff --git 
> > >> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> > >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > >> >> > new file mode 100644
> > >> >> > index ..19fde29dc1d7
> > >> >> > --- /dev/null
> > >> >> > +++ 
> > >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > >> >> > @@ -0,0 +1,46 @@
> > >> >> > +Etnaviv DRM master device
> > >> >> > +
> > >> >> > +
> > >> >> > +The Etnaviv DRM master device is a virtual device needed to list 
> > >> >> > all
> > >> >> > +Vivante GPU cores that comprise the GPU subsystem.
> > >> >> > +
> > >> >> > +Required properties:
> > >> >> > +- compatible: Should be one of
> > >> >> > +"fsl,imx-gpu-subsystem"
> > >> >> > +"marvell,dove-gpu-subsystem"
> > >> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
> > >> >> > devices
> > >> >> > +
> > >> >> > +example:
> > >> >> > +
> > >> >> > +gpu-subsystem {
> > >> >> > +   compatible = "fsl,imx-gpu-subsystem";
> > >> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
> > >> >> > +};
> > >> >>
> > >> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
> > >> >> driver.
> > >> >>
> > >> > I'm aware of that, but I don't see much value in kicking this 
> > >> > discussion
> > >> > around for every DRM driver submission. This is the binding that has
> > >> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> > >> > allows us to standardize on _something_. Also ALSA does a similar thing
> > >> > to bind codecs and CPU interfaces together.
> > >>
> > >> This case is quite different though I think. The ALSA case and other
> > >> DRM cases are ones that have inter-dependencies between the blocks
> > >> (e.g. some sort of h/w connection). What is the inter-dependency here?
> > >>
> > >> Doing this way has also been found to be completely unnecessary and
> > >> removed in recent DRM driver reviews. Admittedly, those are cases
> > >> where one device can be the master of the others. For 2 parallel
> > >> devices, I don't have an alternative other than question why they need
> > >> to be a single driver.
> > >>
> > > If you insist on doing things differently for this driver, we could add
> > > a pass at driver registration that scans through the DT, looking for
> > > nodes matching the GPU core compatible.
> > 
> > I've not insisted on anything. I'm only asking a question which didn't
> > get answered. I'll ask another way. Why can't you have 2 instances of
> > the same driver given they are only rendering nodes?
> 
> Sorry, but it _did_ get answered - I answered that in my reply to you.
> I'll repeat it again, but more briefly, and then expand on it: it's what
> userspace like Xorg DRI2 and MESA want.
> 
> Yes, there's DRI3, which is more modern and in theory allows multiple
> renderers to be opened by the client, but so far I fail to see how that
> can work with a separate KMS DRM driver.  It _may_ be intended to, but
> the problem I see here is that when you have the KMS hardware only
> capable of scanning out linear buffers, but the GPU hardware is only
> capable of rendering to tiled buffers, there needs to be some way to
> allocate KMS buffers in the client, and right now I don't see any way
> to know what the KMS DRM device being used is in the DRI3/Present Xorg
> extensions.
> 
> Moreover, DRI3 is not yet available for Gallium, so if we're talking
> about Xorg, then functional DRI2 is a requirement, and that _needs_
> to have a single device for the rendering instances.  Xorg has no way
> to pass multiple render nodes to client over DRI2.

The only thing that DRI2 needs is that both client and X use the same
device. But you can just dma-buf share stuff in the client (e.g. we had
some code at intel to decode videos in libva with some code chip, then
dma-buf share to i915.ko for post-proc, then dri2 flink to the X server).
Same on the X server

[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"

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

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

--- Comment #18 from Dave Witbrodt  ---
(In reply to Mario Kleiner from comment #13)
> Created attachment 120350 [details] [review]
> v2 of the radeon-kms fix: Slightly more efficient.

Works very well on my hardware.  Thanks for "Tested By:"

Will wait to see if agd5f picks this up (then airlied), or if others will be
commenting/changing it first.

DW

-- 
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/20151204/6aee823c/attachment.html>

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach  
> wrote:
> > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> >> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
> >> wrote:
> >> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> >> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> >> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
> >> >> > master device node to bind all the individual GPU cores together
> >> >> > into one DRM device.
> >> >> >
> >> >> > Signed-off-by: Lucas Stach 
> >> >> > ---
> >> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> >> >> > ++
> >> >> >  1 file changed, 46 insertions(+)
> >> >> >  create mode 100644 
> >> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >> >
> >> >> > diff --git 
> >> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >> > new file mode 100644
> >> >> > index ..19fde29dc1d7
> >> >> > --- /dev/null
> >> >> > +++ 
> >> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >> > @@ -0,0 +1,46 @@
> >> >> > +Etnaviv DRM master device
> >> >> > +
> >> >> > +
> >> >> > +The Etnaviv DRM master device is a virtual device needed to list all
> >> >> > +Vivante GPU cores that comprise the GPU subsystem.
> >> >> > +
> >> >> > +Required properties:
> >> >> > +- compatible: Should be one of
> >> >> > +"fsl,imx-gpu-subsystem"
> >> >> > +"marvell,dove-gpu-subsystem"
> >> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
> >> >> > devices
> >> >> > +
> >> >> > +example:
> >> >> > +
> >> >> > +gpu-subsystem {
> >> >> > +   compatible = "fsl,imx-gpu-subsystem";
> >> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
> >> >> > +};
> >> >>
> >> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
> >> >> driver.
> >> >>
> >> > I'm aware of that, but I don't see much value in kicking this discussion
> >> > around for every DRM driver submission. This is the binding that has
> >> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> >> > allows us to standardize on _something_. Also ALSA does a similar thing
> >> > to bind codecs and CPU interfaces together.
> >>
> >> This case is quite different though I think. The ALSA case and other
> >> DRM cases are ones that have inter-dependencies between the blocks
> >> (e.g. some sort of h/w connection). What is the inter-dependency here?
> >>
> >> Doing this way has also been found to be completely unnecessary and
> >> removed in recent DRM driver reviews. Admittedly, those are cases
> >> where one device can be the master of the others. For 2 parallel
> >> devices, I don't have an alternative other than question why they need
> >> to be a single driver.
> >>
> > If you insist on doing things differently for this driver, we could add
> > a pass at driver registration that scans through the DT, looking for
> > nodes matching the GPU core compatible.
> 
> I've not insisted on anything. I'm only asking a question which didn't
> get answered. I'll ask another way. Why can't you have 2 instances of
> the same driver given they are only rendering nodes?

Sorry, but it _did_ get answered - I answered that in my reply to you.
I'll repeat it again, but more briefly, and then expand on it: it's what
userspace like Xorg DRI2 and MESA want.

Yes, there's DRI3, which is more modern and in theory allows multiple
renderers to be opened by the client, but so far I fail to see how that
can work with a separate KMS DRM driver.  It _may_ be intended to, but
the problem I see here is that when you have the KMS hardware only
capable of scanning out linear buffers, but the GPU hardware is only
capable of rendering to tiled buffers, there needs to be some way to
allocate KMS buffers in the client, and right now I don't see any way
to know what the KMS DRM device being used is in the DRI3/Present Xorg
extensions.

Moreover, DRI3 is not yet available for Gallium, so if we're talking
about Xorg, then functional DRI2 is a requirement, and that _needs_
to have a single device for the rendering instances.  Xorg has no way
to pass multiple render nodes to client over DRI2.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

dumb BOs and prime

[Martin Peres]

On 04/12/15 19:49, Rob Herring wrote:
> I'm working on getting Android working with DRM drivers. ATM, I'm
> using virtio-gpu as the driver and trying to get just KMS side working
> without rendering. I have it working with stock AOSP and the emulated
> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
> get things working with native KMS using drm_gralloc and
> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
> not sure how to solve without hacking around it.
>
> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
> allowed on render nodes and drmPrimeHandleToFD is not allowed on
> card0, so I'm stuck. I could open both nodes, but then I want the case
> of no render node to work. After some searching, I thought it was a
> matter of needing to do drmAuthMagic, but then found that is
> considered obsolete[2].

Obsolete when using render nodes, but still necessary on usual nodes 
(/dev/dri/cardX) as far as I remember. The usual nodes can do everything 
the render nodes can do.

Authentication should help! Please make sure you are master or 
authenticated before doing anything on the usual nodes.

>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4
> [2] 
> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #120310|0   |1
is obsolete||
 Attachment #120351|0   |1
is obsolete||

--- Comment #17 from Alex Deucher  ---
Created attachment 120356
  --> https://bugs.freedesktop.org/attachment.cgi?id=120356&action=edit
v3 for amdgpu

Fix a crash in the crtc disabled case.

-- 
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/20151204/df623cb4/attachment.html>

dumb BOs and prime

[Benjamin Gaignard]

Hi Rob,

I got the same problem today with sti drm/kms driver and dumb Bo.
The issue comes become hwcomposer because is the master and authenticated
on /dev/dri/cardX
Dumb allocation is done by gralloc which does a new open (so it is not
authenticated) on drm node the consequence is that we can't use prime
functions...
If you use render node you won't be able to call dumb functions.

To get out of this I think I will implement additional helpers in gem_cma
to have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP
and call them instead of dumb so be able to use render node.
Of course it is only for drivers which already use gem_cma helpers (like
sti)

Benjamin


Le vendredi 4 décembre 2015, Martin Peres  a
écrit :

> On 04/12/15 19:49, Rob Herring wrote:
>
>> I'm working on getting Android working with DRM drivers. ATM, I'm
>> using virtio-gpu as the driver and trying to get just KMS side working
>> without rendering. I have it working with stock AOSP and the emulated
>> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
>> get things working with native KMS using drm_gralloc and
>> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
>> not sure how to solve without hacking around it.
>>
>> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
>> allowed on render nodes and drmPrimeHandleToFD is not allowed on
>> card0, so I'm stuck. I could open both nodes, but then I want the case
>> of no render node to work. After some searching, I thought it was a
>> matter of needing to do drmAuthMagic, but then found that is
>> considered obsolete[2].
>>
>
> Obsolete when using render nodes, but still necessary on usual nodes
> (/dev/dri/cardX) as far as I remember. The usual nodes can do everything
> the render nodes can do.
>
> Authentication should help! Please make sure you are master or
> authenticated before doing anything on the usual nodes.
>
>
>> Rob
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>> android-4.4
>> [2]
>> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>

-- 

Benjamin Gaignard

Graphic Working Group

Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151204/8d53a325/attachment.html>

[Bug 92555] GPU lockup crashing the system on Cayman with HyperZ

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

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

Thomas Rohloff  changed:

   What|Removed |Added

Summary|GPU lockup crashing the |GPU lockup crashing the
   |system on Cayman|system on Cayman with
   ||HyperZ

-- 
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/20151204/61df05b9/attachment.html>

[Bug 92555] GPU lockup crashing the system on Cayman

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

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

--- Comment #5 from Thomas Rohloff  ---
Seems to be a problem with HyperZ. R600_DEBUG=nohyperz looks like a workaround.

-- 
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/20151204/fe28a028/attachment.html>

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Jon Nettleton]

On Fri, Dec 4, 2015 at 6:56 PM, Lucas Stach  wrote:
> Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
>> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
>> wrote:
>> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
>> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
>> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
>> >> > master device node to bind all the individual GPU cores together
>> >> > into one DRM device.
>> >> >
>> >> > Signed-off-by: Lucas Stach 
>> >> > ---
>> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
>> >> > ++
>> >> >  1 file changed, 46 insertions(+)
>> >> >  create mode 100644 
>> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> >
>> >> > diff --git 
>> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
>> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > new file mode 100644
>> >> > index ..19fde29dc1d7
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > @@ -0,0 +1,46 @@
>> >> > +Etnaviv DRM master device
>> >> > +
>> >> > +
>> >> > +The Etnaviv DRM master device is a virtual device needed to list all
>> >> > +Vivante GPU cores that comprise the GPU subsystem.
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible: Should be one of
>> >> > +"fsl,imx-gpu-subsystem"
>> >> > +"marvell,dove-gpu-subsystem"
>> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
>> >> > devices
>> >> > +
>> >> > +example:
>> >> > +
>> >> > +gpu-subsystem {
>> >> > +   compatible = "fsl,imx-gpu-subsystem";
>> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
>> >> > +};
>> >>
>> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
>> >> driver.
>> >>
>> > I'm aware of that, but I don't see much value in kicking this discussion
>> > around for every DRM driver submission. This is the binding that has
>> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
>> > allows us to standardize on _something_. Also ALSA does a similar thing
>> > to bind codecs and CPU interfaces together.
>>
>> This case is quite different though I think. The ALSA case and other
>> DRM cases are ones that have inter-dependencies between the blocks
>> (e.g. some sort of h/w connection). What is the inter-dependency here?
>>
>> Doing this way has also been found to be completely unnecessary and
>> removed in recent DRM driver reviews. Admittedly, those are cases
>> where one device can be the master of the others. For 2 parallel
>> devices, I don't have an alternative other than question why they need
>> to be a single driver.
>>
> If you insist on doing things differently for this driver, we could add
> a pass at driver registration that scans through the DT, looking for
> nodes matching the GPU core compatible.
>
> I'm not sure if that makes things cleaner though and might bite us later
> on. Also I'm not sure if moving away from the binding scheme already
> established for other DRM drivers makes things better from a DT
> perspective. Personally I would prefer DT binding consistency over
> perfection for single drivers, segmenting the DT binding space.
>

We should also keep in mind that Vivante is working on newer chipsets
that also include multiple independent 3d cores.  I am not even sure
how userspace would deal with this using the suggested changes.

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Lucas Stach]

Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
> wrote:
> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
> >> > master device node to bind all the individual GPU cores together
> >> > into one DRM device.
> >> >
> >> > Signed-off-by: Lucas Stach 
> >> > ---
> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> >> > ++
> >> >  1 file changed, 46 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> > new file mode 100644
> >> > index ..19fde29dc1d7
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> >> > @@ -0,0 +1,46 @@
> >> > +Etnaviv DRM master device
> >> > +
> >> > +
> >> > +The Etnaviv DRM master device is a virtual device needed to list all
> >> > +Vivante GPU cores that comprise the GPU subsystem.
> >> > +
> >> > +Required properties:
> >> > +- compatible: Should be one of
> >> > +"fsl,imx-gpu-subsystem"
> >> > +"marvell,dove-gpu-subsystem"
> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
> >> > devices
> >> > +
> >> > +example:
> >> > +
> >> > +gpu-subsystem {
> >> > +   compatible = "fsl,imx-gpu-subsystem";
> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
> >> > +};
> >>
> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
> >> driver.
> >>
> > I'm aware of that, but I don't see much value in kicking this discussion
> > around for every DRM driver submission. This is the binding that has
> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> > allows us to standardize on _something_. Also ALSA does a similar thing
> > to bind codecs and CPU interfaces together.
> 
> This case is quite different though I think. The ALSA case and other
> DRM cases are ones that have inter-dependencies between the blocks
> (e.g. some sort of h/w connection). What is the inter-dependency here?
> 
> Doing this way has also been found to be completely unnecessary and
> removed in recent DRM driver reviews. Admittedly, those are cases
> where one device can be the master of the others. For 2 parallel
> devices, I don't have an alternative other than question why they need
> to be a single driver.
> 
If you insist on doing things differently for this driver, we could add
a pass at driver registration that scans through the DT, looking for
nodes matching the GPU core compatible.

I'm not sure if that makes things cleaner though and might bite us later
on. Also I'm not sure if moving away from the binding scheme already
established for other DRM drivers makes things better from a DT
perspective. Personally I would prefer DT binding consistency over
perfection for single drivers, segmenting the DT binding space.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH 13/13] ASoC: AMD: Manage ACP 2.x SRAM banks power

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

ACP SRAM banks gets turned on when ACP is powered on.
Not all banks are used for playback/capture. So, power on
required banks during audio device open and power off during
audio device close.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/acp-pcm-dma.c | 25 +++---
 sound/soc/amd/acp.c | 81 -
 sound/soc/amd/acp.h |  3 +-
 3 files changed, 103 insertions(+), 6 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 07a26e5..daba64a 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -133,6 +133,7 @@ static irqreturn_t dma_irq_handler(int irq, void *arg)

 static int acp_dma_open(struct snd_pcm_substream *substream)
 {
+   u32 bank;
int ret = 0;
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_soc_pcm_runtime *prtd = substream->private_data;
@@ -166,10 +167,17 @@ static int acp_dma_open(struct snd_pcm_substream 
*substream)
if (!intr_data->play_stream && !intr_data->capture_stream)
acp_enable_external_interrupts(adata->acp_mmio, 1);

-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
intr_data->play_stream = substream;
-   else
+   for (bank = 1; bank <= 4; bank++)
+   acp_turnonoff_lower_sram_bank(intr_data->acp_mmio, bank,
+   true);
+   } else {
intr_data->capture_stream = substream;
+   for (bank = 5; bank <= 8; bank++)
+   acp_turnonoff_lower_sram_bank(intr_data->acp_mmio, bank,
+   true);
+   }

return 0;
 }
@@ -201,6 +209,7 @@ static int acp_dma_hw_params(struct snd_pcm_substream 
*substream,
pg = virt_to_page(substream->dma_buffer.area);

if (pg != NULL) {
+   acp_turnonoff_lower_sram_bank(rtd->acp_mmio, 0, true);
/* Save for runtime private data */
rtd->pg = pg;
rtd->order = get_order(size);
@@ -364,6 +373,7 @@ static int acp_dma_new(struct snd_soc_pcm_runtime *rtd)

 static int acp_dma_close(struct snd_pcm_substream *substream)
 {
+   u32 bank;
struct snd_pcm_runtime *runtime = substream->runtime;
struct audio_substream_data *rtd = runtime->private_data;
struct snd_soc_pcm_runtime *prtd = substream->private_data;
@@ -371,10 +381,17 @@ static int acp_dma_close(struct snd_pcm_substream 
*substream)

kfree(rtd);

-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
adata->play_stream = NULL;
-   else
+   for (bank = 1; bank <= 4; bank++)
+   acp_turnonoff_lower_sram_bank(adata->acp_mmio, bank,
+   false);
+   } else {
adata->capture_stream = NULL;
+   for (bank = 5; bank <= 8; bank++)
+   acp_turnonoff_lower_sram_bank(adata->acp_mmio, bank,
+   false);
+   }

/* Disable ACP irq, when the current stream is being closed and
 * another stream is also not active.
diff --git a/sound/soc/amd/acp.c b/sound/soc/amd/acp.c
index 0d59be4..ed3f83f 100644
--- a/sound/soc/amd/acp.c
+++ b/sound/soc/amd/acp.c
@@ -462,10 +462,79 @@ int acp_dma_stop(void __iomem *acp_mmio, u8 ch_num)
return 0;
 }

+void acp_turnonoff_lower_sram_bank(void __iomem *acp_mmio, u16 bank,
+   bool turnon)
+{
+   u32 val;
+
+   val = acp_reg_read(acp_mmio, mmACP_MEM_SHUT_DOWN_REQ_LO);
+   if (val & (1 << bank)) {
+   /* bank is in off state */
+   if (turnon == true)
+   /* request to on */
+   val &= ~(1 << bank);
+   else
+   /* request to off */
+   return;
+   } else {
+   /* bank is in on state */
+   if (turnon == false)
+   /* request to off */
+   val |= 1 << bank;
+   else
+   /* request to on */
+   return;
+   }
+acp_reg_write(val, acp_mmio,
+  mmACP_MEM_SHUT_DOWN_REQ_LO);
+   /* If ACP_MEM_SHUT_DOWN_STS_LO is 0x, then
+* shutdown sequence is complete.
+*/
+while (acp_reg_read(acp_mmio,
+ mmACP_MEM_SHUT_DOWN_STS_LO)
+ != 0x)
+   cpu_relax();
+}
+
+void acp_turnonoff_higher_sram_bank(void __iomem *acp_mmio, u16 ba

[PATCH 12/13] ASoC: AMD: add pm ops

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

genpd will power off/on ACP to manage runtime ACP PM. ACP runtime PM
hooks are added to get it deinitialized and initialized respectively,
after it is powered off/on.

When system goes to suspend when audio usecase is active, ACP will
be powered off through genpd. When it resumes, ACP needs to be
initialized and reconfigured.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/acp-pcm-dma.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 9734f2e..07a26e5 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -447,6 +448,10 @@ static int acp_audio_probe(struct platform_device *pdev)
return status;
}

+   pm_runtime_set_autosuspend_delay(&pdev->dev, 1);
+   pm_runtime_use_autosuspend(&pdev->dev);
+   pm_runtime_enable(&pdev->dev);
+
return status;
 }

@@ -456,15 +461,77 @@ static int acp_audio_remove(struct platform_device *pdev)

acp_deinit(adata->acp_mmio);
snd_soc_unregister_platform(&pdev->dev);
+   pm_runtime_disable(&pdev->dev);
+
+   return 0;
+}
+
+static int acp_pcm_resume(struct device *dev)
+{
+   u16 bank;
+   struct snd_pcm_substream *stream;
+   struct snd_pcm_runtime *rtd;
+   struct audio_substream_data *sdata;
+   struct audio_drv_data *adata = dev_get_drvdata(dev);
+
+   acp_init(adata->acp_mmio);
+
+   stream = adata->play_stream;
+   rtd = stream ? stream->runtime : NULL;
+   if (rtd != NULL) {
+   /* Resume playback stream from a suspended state */
+   for (bank = 1; bank <= 4; bank++)
+   acp_turnonoff_lower_sram_bank(adata->acp_mmio, bank,
+   true);
+   sdata = rtd->private_data;
+   config_acp_dma(adata->acp_mmio, sdata);
+   }
+
+   stream = adata->capture_stream;
+   rtd =  stream ? stream->runtime : NULL;
+   if (rtd != NULL) {
+   /* Resume capture stream from a suspended state */
+   for (bank = 5; bank <= 8; bank++)
+   acp_turnonoff_lower_sram_bank(adata->acp_mmio, bank,
+   true);
+   sdata = rtd->private_data;
+   config_acp_dma(adata->acp_mmio, sdata);
+   }
+
+   acp_enable_external_interrupts(adata->acp_mmio, 1);
+   return 0;
+}
+
+static int acp_pcm_runtime_suspend(struct device *dev)
+{
+   struct audio_drv_data *adata = dev_get_drvdata(dev);

+   acp_deinit(adata->acp_mmio);
+   acp_enable_external_interrupts(adata->acp_mmio, 0);
return 0;
 }

+static int acp_pcm_runtime_resume(struct device *dev)
+{
+   struct audio_drv_data *adata = dev_get_drvdata(dev);
+
+   acp_init(adata->acp_mmio);
+   acp_enable_external_interrupts(adata->acp_mmio, 1);
+   return 0;
+}
+
+static const struct dev_pm_ops acp_pm_ops = {
+   .resume = acp_pcm_resume,
+   .runtime_suspend = acp_pcm_runtime_suspend,
+   .runtime_resume = acp_pcm_runtime_resume,
+};
+
 static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
.name = "acp_audio_dma",
+   .pm = &acp_pm_ops,
},
 };

-- 
1.8.3.1

[PATCH 11/13] ASoC: AMD: add AMD ASoC ACP 2.x DMA driver

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

ACP IP block consists of dedicated DMA and I2S blocks. The PCM
driver provides the platform DMA component to ALSA core.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Alex Deucher 
---
 sound/soc/Kconfig   |   1 +
 sound/soc/Makefile  |   1 +
 sound/soc/amd/Kconfig   |   4 +
 sound/soc/amd/Makefile  |   3 +
 sound/soc/amd/acp-pcm-dma.c | 476 
 5 files changed, 485 insertions(+)
 create mode 100644 sound/soc/amd/Kconfig
 create mode 100644 sound/soc/amd/Makefile
 create mode 100644 sound/soc/amd/acp-pcm-dma.c

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 7ff7d88..a34e9e9 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -38,6 +38,7 @@ config SND_SOC_TOPOLOGY

 # All the supported SoCs
 source "sound/soc/adi/Kconfig"
+source "sound/soc/amd/Kconfig"
 source "sound/soc/atmel/Kconfig"
 source "sound/soc/au1x/Kconfig"
 source "sound/soc/bcm/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 8eb06db..a79a4c7 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_SND_SOC) += snd-soc-core.o
 obj-$(CONFIG_SND_SOC)  += codecs/
 obj-$(CONFIG_SND_SOC)  += generic/
 obj-$(CONFIG_SND_SOC)  += adi/
+obj-$(CONFIG_SND_SOC)  += amd/
 obj-$(CONFIG_SND_SOC)  += atmel/
 obj-$(CONFIG_SND_SOC)  += au1x/
 obj-$(CONFIG_SND_SOC)  += bcm/
diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig
new file mode 100644
index 000..78187eb
--- /dev/null
+++ b/sound/soc/amd/Kconfig
@@ -0,0 +1,4 @@
+config SND_SOC_AMD_ACP
+   tristate "AMD Audio Coprocessor support"
+   help
+This option enables ACP DMA support on AMD platform.
diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
new file mode 100644
index 000..62648cb
--- /dev/null
+++ b/sound/soc/amd/Makefile
@@ -0,0 +1,3 @@
+snd-soc-acp-pcm-objs   := acp-pcm-dma.o acp.o
+
+obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
new file mode 100644
index 000..9734f2e
--- /dev/null
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -0,0 +1,476 @@
+/*
+ * AMD ALSA SoC PCM Driver
+ *
+ * Copyright 2014-2015 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "acp.h"
+
+#define PLAYBACK_MIN_NUM_PERIODS2
+#define PLAYBACK_MAX_NUM_PERIODS2
+#define PLAYBACK_MAX_PERIOD_SIZE16384
+#define PLAYBACK_MIN_PERIOD_SIZE1024
+#define CAPTURE_MIN_NUM_PERIODS 2
+#define CAPTURE_MAX_NUM_PERIODS 2
+#define CAPTURE_MAX_PERIOD_SIZE 16384
+#define CAPTURE_MIN_PERIOD_SIZE 1024
+
+#define NUM_DSCRS_PER_CHANNEL 2
+
+#define MAX_BUFFER (PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
+#define MIN_BUFFER MAX_BUFFER
+
+static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+   .channels_max = 8,
+   .rates = SNDRV_PCM_RATE_8000_96000,
+   .rate_min = 8000,
+   .rate_max = 96000,
+   .buffer_bytes_max = PLAYBACK_MAX_NUM_PERIODS * PLAYBACK_MAX_PERIOD_SIZE,
+   .period_bytes_min = PLAYBACK_MIN_PERIOD_SIZE,
+   .period_bytes_max = PLAYBACK_MAX_PERIOD_SIZE,
+   .periods_min = PLAYBACK_MIN_NUM_PERIODS,
+   .periods_max = PLAYBACK_MAX_NUM_PERIODS,
+};
+
+static const struct snd_pcm_hardware acp_pcm_hardware_capture = {
+   .info = SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH |
+   SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE |
+   SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE,
+   .channels_min = 1,
+   .channels_max = 2,
+   .rates = SNDRV_PCM_RATE_8000_48000,
+   .rate_min = 8000,
+   .rate_max = 48000,
+   .buffer_bytes_max = CAPTURE_MAX_NUM_PERIODS * CAPTURE_MAX_PERIOD_SIZE,
+   .period_bytes_min = CAPTURE_MIN_PERIOD_SIZE,
+   .period_by

[PATCH 10/13] ASoC: AMD: add ACP 2.x IP DMA abstraction layer

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

ACP IP has internal DMA controller with multiple channels which
can be programmed in cyclic/non cyclic manner. ACP can generate
interrupt upon completion of DMA transfer, if required.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/acp.c | 587 
 sound/soc/amd/acp.h | 139 +
 2 files changed, 726 insertions(+)
 create mode 100644 sound/soc/amd/acp.c
 create mode 100644 sound/soc/amd/acp.h

diff --git a/sound/soc/amd/acp.c b/sound/soc/amd/acp.c
new file mode 100644
index 000..0d59be4
--- /dev/null
+++ b/sound/soc/amd/acp.c
@@ -0,0 +1,587 @@
+/*
+ * AMD ACP module
+ *
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "acp.h"
+
+u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
+{
+   return readl(acp_mmio + (reg * 4));
+}
+
+void acp_reg_write(u32 val, void __iomem *acp_mmio, u32 reg)
+{
+   writel(val, acp_mmio + (reg * 4));
+}
+
+/* Configure a given dma channel parameters - enable/disble,
+ * number of descriptors, priority
+ */
+void config_acp_dma_channel(void __iomem *acp_mmio, u8 ch_num,
+  u16 dscr_strt_idx, u16 num_dscrs,
+  enum acp_dma_priority_level priority_level)
+{
+   u32 dma_ctrl;
+
+   /* disable the channel run field */
+   dma_ctrl = acp_reg_read(acp_mmio, mmACP_DMA_CNTL_0 + ch_num);
+   dma_ctrl &= ~ACP_DMA_CNTL_0__DMAChRun_MASK;
+   acp_reg_write(dma_ctrl, acp_mmio, mmACP_DMA_CNTL_0 + ch_num);
+
+   /* program a DMA channel with first descriptor to be processed. */
+   acp_reg_write((ACP_DMA_DSCR_STRT_IDX_0__DMAChDscrStrtIdx_MASK
+   & dscr_strt_idx),
+   acp_mmio, mmACP_DMA_DSCR_STRT_IDX_0 + ch_num);
+
+   /* program a DMA channel with the number of descriptors to be
+* processed in the transfer
+   */
+   acp_reg_write(ACP_DMA_DSCR_CNT_0__DMAChDscrCnt_MASK & num_dscrs,
+   acp_mmio, mmACP_DMA_DSCR_CNT_0 + ch_num);
+
+   /* set DMA channel priority */
+   acp_reg_write(priority_level, acp_mmio, mmACP_DMA_PRIO_0 + ch_num);
+}
+
+/* Initialize the dma descriptors location in SRAM and page size */
+static void acp_dma_descr_init(void __iomem *acp_mmio)
+{
+   u32 sram_pte_offset = 0;
+
+   /* SRAM starts at 0x0400. From that offset one page (4KB) left for
+* filling DMA descriptors.sram_pte_offset = 0x04001000 , used for
+* filling system RAM's physical pages.
+* This becomes the ALSA's Ring buffer start address
+   */
+   sram_pte_offset = ACP_DAGB_GRP_SRAM_BASE_ADDRESS;
+
+   /* snoopable */
+   sram_pte_offset |= ACP_DAGB_BASE_ADDR_GRP_1__AXI2DAGBSnoopSel_MASK;
+   /* Memmory is system mmemory */
+   sram_pte_offset |= ACP_DAGB_BASE_ADDR_GRP_1__AXI2DAGBTargetMemSel_MASK;
+   /* Page Enabled */
+   sram_pte_offset |= ACP_DAGB_BASE_ADDR_GRP_1__AXI2DAGBGrpEnable_MASK;
+
+   acp_reg_write(sram_pte_offset,  acp_mmio, mmACP_DAGB_BASE_ADDR_GRP_1);
+   acp_reg_write(PAGE_SIZE_4K_ENABLE, acp_mmio,
+   mmACP_DAGB_PAGE_SIZE_GRP_1);
+}
+
+/* Initialize a dma descriptor in SRAM based on descritor information passed */
+static void config_dma_descriptor_in_sram(void __iomem *acp_mmio,
+ u16 descr_idx,
+ acp_dma_dscr_transfer_t *descr_info)
+{
+   u32 sram_offset;
+
+   sram_offset = (descr_idx * sizeof(acp_dma_dscr_transfer_t));
+
+   /* program the source base address. */
+   acp_reg_write(sram_offset, acp_mmio, mmACP_SRBM_Targ_Idx_Addr);
+   acp_reg_write(descr_info->src,  acp_mmio, mmACP_SRBM_Targ_Idx_Data);
+   /* program the destination base address. */
+   acp_reg_write(sram_offset + 4,  acp_mmio, mmACP_SRBM_Targ_Idx_Addr);
+   acp_reg_write(descr_info->dest, acp_mmio, mmACP_SRBM_Targ_Idx_Data);
+
+   /* program the number of bytes to be transferred for this descriptor. */
+   acp_reg_write(sram_offset + 8,  acp_mmio, mmACP_SRBM_Targ_Idx_Addr);
+   acp_reg_write(descr_info->xfer_val, acp_mmio, mmACP_SRBM_Targ_Idx_Data);
+}
+
+/* Initialize the DMA descriptor information for transfer between
+ * system memory <-> ACP SRAM
+ */
+static void set_acp_sysmem_dma_descriptors(void

[PATCH 08/13] drm/amd: add pm domain for ACP IP sub blocks

[Alex Deucher]

ACP IP have internal DMA controller, DW I2S controller and DSPs
as separate power tiles. DMA and I2S devices are added to generic
pm domain, so that entire IP can be powered off/on at appropriate
times. Unused DSPs are made to be powered off though they are powered
on during ACP pm domain power on sequence.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/acp/Kconfig |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 206 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h |   1 +
 3 files changed, 207 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig
index 28b5e70..2b07813 100644
--- a/drivers/gpu/drm/amd/acp/Kconfig
+++ b/drivers/gpu/drm/amd/acp/Kconfig
@@ -4,6 +4,7 @@ config DRM_AMD_ACP
bool "Enable ACP IP support"
default y
select MFD_CORE
+   select PM_GENERIC_DOMAINS if PM
help
Choose this option to enable ACP IP support for AMD SOCs.

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index eb5dc10..b425c44 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -24,6 +24,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -102,6 +103,155 @@ static int acp_sw_fini(void *handle)
return 0;
 }

+/* power off a tile/block within ACP */
+static int acp_suspend_tile(void *cgs_dev, int tile)
+{
+   u32 val = 0;
+   u32 count = 0;
+
+   if ((tile  < ACP_TILE_P1) || (tile > ACP_TILE_DSP2)) {
+   pr_err("Invalid ACP tile : %d to suspend\n", tile);
+   return -1;
+   }
+
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_READ_REG_0 + tile);
+   val &= ACP_TILE_ON_MASK;
+
+   if (val == 0x0) {
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_RETAIN_REG);
+   val = val | (1 << tile);
+   cgs_write_register(cgs_dev, mmACP_PGFSM_RETAIN_REG, val);
+   cgs_write_register(cgs_dev, mmACP_PGFSM_CONFIG_REG,
+   0x500 + tile);
+
+   count = ACP_TIMEOUT_LOOP;
+   while (true) {
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_READ_REG_0
+   + tile);
+   val = val & ACP_TILE_ON_MASK;
+   if (val == ACP_TILE_OFF_MASK)
+   break;
+   if (--count == 0) {
+   pr_err("Timeout reading ACP PGFSM status\n");
+   return -ETIMEDOUT;
+   }
+   udelay(100);
+   }
+
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_RETAIN_REG);
+
+   val |= ACP_TILE_OFF_RETAIN_REG_MASK;
+   cgs_write_register(cgs_dev, mmACP_PGFSM_RETAIN_REG, val);
+   }
+   return 0;
+}
+
+/* power on a tile/block within ACP */
+static int acp_resume_tile(void *cgs_dev, int tile)
+{
+   u32 val = 0;
+   u32 count = 0;
+
+   if ((tile  < ACP_TILE_P1) || (tile > ACP_TILE_DSP2)) {
+   pr_err("Invalid ACP tile to resume\n");
+   return -1;
+   }
+
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_READ_REG_0 + tile);
+   val = val & ACP_TILE_ON_MASK;
+
+   if (val != 0x0) {
+   cgs_write_register(cgs_dev, mmACP_PGFSM_CONFIG_REG,
+   0x600 + tile);
+   count = ACP_TIMEOUT_LOOP;
+   while (true) {
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_READ_REG_0
+   + tile);
+   val = val & ACP_TILE_ON_MASK;
+   if (val == 0x0)
+   break;
+   if (--count == 0) {
+   pr_err("Timeout reading ACP PGFSM status\n");
+   return -ETIMEDOUT;
+   }
+   udelay(100);
+   }
+   val = cgs_read_register(cgs_dev, mmACP_PGFSM_RETAIN_REG);
+   if (tile == ACP_TILE_P1)
+   val = val & (ACP_TILE_P1_MASK);
+   else if (tile == ACP_TILE_P2)
+   val = val & (ACP_TILE_P2_MASK);
+
+   cgs_write_register(cgs_dev, mmACP_PGFSM_RETAIN_REG, val);
+   }
+   return 0;
+}
+
+struct acp_pm_domain {
+   void *cgs_dev;
+   struct generic_pm_domain gpd;
+};
+
+static int acp_poweroff(struct generic_pm_domain *genpd)
+{
+   int i, ret;
+   struct acp_pm_domain *apd;
+
+   apd = container_of(genpd, struct acp_pm_domain, gpd);
+   if (apd != NULL) {
+   /* Donot return abruptly if any of power tile fails to suspend.
+   

[PATCH 07/13] drm/amd: add ACP driver support

[Alex Deucher]

From: Maruthi Bayyavarapu 

This adds the ACP (Audio CoProcessor) IP driver and wires
it up to the amdgpu driver.  The ACP block provides the DMA
engine for i2s based ALSA driver. This is required for audio
on APUs that utilize an i2s codec.

Reviewed-by: Jammy Zhou 
Reviewed-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Reviewed-by: Murali Krishna Vemuri 
Signed-off-by: Maruthi Bayyavarapu 
Signed-off-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---

v2: integrate i2s/az check patch
v3: s/amd_acp/amdgpu_acp/
v4: update copyright notice
v5: squash multiple patches, convert to mfd
v6: major changes as below :
1. Pass ACP register base to DMA and dw i2s drivers
   as IORESOURCE_MEM resources.
2. add dw i2s as a new mfd cell.
v7: specify broken out dw quirks that apply to AMD hardware
v8: Changes:
1. Select MFD_CORE
2. use genirq for ACP interrupt
3. Add separate cells for dws capture and playback

 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/amd/acp/Kconfig  |  10 +
 drivers/gpu/drm/amd/acp/Makefile |   9 +
 drivers/gpu/drm/amd/acp/acp_hw.c |  50 +
 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h |  34 +++
 drivers/gpu/drm/amd/amdgpu/Makefile  |  13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |  12 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c  | 297 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h  |  41 
 drivers/gpu/drm/amd/amdgpu/vi.c  |  12 ++
 drivers/gpu/drm/amd/include/amd_shared.h |   1 +
 11 files changed, 480 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/amd/acp/Kconfig
 create mode 100644 drivers/gpu/drm/amd/acp/Makefile
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c
 create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4bf9a1..b7add15 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -161,6 +161,8 @@ config DRM_AMDGPU

 source "drivers/gpu/drm/amd/amdgpu/Kconfig"

+source "drivers/gpu/drm/amd/acp/Kconfig"
+
 source "drivers/gpu/drm/nouveau/Kconfig"

 config DRM_I810
diff --git a/drivers/gpu/drm/amd/acp/Kconfig b/drivers/gpu/drm/amd/acp/Kconfig
new file mode 100644
index 000..28b5e70
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Kconfig
@@ -0,0 +1,10 @@
+menu "ACP Configuration"
+
+config DRM_AMD_ACP
+   bool "Enable ACP IP support"
+   default y
+   select MFD_CORE
+   help
+   Choose this option to enable ACP IP support for AMD SOCs.
+
+endmenu
diff --git a/drivers/gpu/drm/amd/acp/Makefile b/drivers/gpu/drm/amd/acp/Makefile
new file mode 100644
index 000..c8c3303
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the ACP, which is a sub-component
+# of AMDSOC/AMDGPU drm driver.
+# It provides the HW control for ACP related functionalities.
+
+ccflags-y += -Idrivers/gpu/drm/amd/include/asic_reg/acp
+subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include
+
+AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o
diff --git a/drivers/gpu/drm/amd/acp/acp_hw.c b/drivers/gpu/drm/amd/acp/acp_hw.c
new file mode 100644
index 000..7af83f1
--- /dev/null
+++ b/drivers/gpu/drm/amd/acp/acp_hw.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2015 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "acp_gfx_if.h"
+
+#define ACP_MODE_I2S   0
+#define ACP_MODE_AZ1
+
+#define mmACP_AZALIA_I2S_SELECT 0x51d4
+
+int amd_acp_hw_init(void *cgs_device,
+   unsigned acp_version_major, unsigned acp_version_minor)
+{
+   unsigned int acp_mode = ACP_MODE_I2S;
+
+   if ((acp_version_major == 2) && (acp_version_minor == 2))
+   

[PATCH 06/13] PM / Domains: export symbols to add/remove devices from genpd

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

Drivers which can be built as loadable module needs symbols
- pm_genpd_add_device/pm_genpd_remove_device to add/remove devices
to/from genpd. Those drivers create platform devices, which comes
under a powerdomain.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/base/power/domain.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e03b1ad..8fe6e70 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1252,6 +1252,7 @@ int __pm_genpd_add_device(struct generic_pm_domain 
*genpd, struct device *dev,

return ret;
 }
+EXPORT_SYMBOL_GPL(__pm_genpd_add_device);

 /**
  * pm_genpd_remove_device - Remove a device from an I/O PM domain.
@@ -1302,6 +1303,7 @@ int pm_genpd_remove_device(struct generic_pm_domain 
*genpd,

return ret;
 }
+EXPORT_SYMBOL_GPL(pm_genpd_remove_device);

 /**
  * pm_genpd_add_subdomain - Add a subdomain to an I/O PM domain.
-- 
1.8.3.1

[PATCH 05/13] ASoC: dwc: reconfigure dwc in 'resume' from 'suspend'

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

DWC IP can be powered off during system suspend in some platforms.
After system is resumed, dwc needs to be programmed again to continue
audio use case.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 sound/soc/dwc/designware_i2s.c | 70 ++
 1 file changed, 43 insertions(+), 27 deletions(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 940c881..825a1f4 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -98,6 +98,8 @@ struct dw_i2s_dev {
unsigned int i2s_reg_comp1;
unsigned int i2s_reg_comp2;
struct device *dev;
+   u32 ccr;
+   u32 xfer_resolution;

/* data related to DMA transfers b/w i2s and DMAC */
union dw_i2s_snd_dma_data play_dma_data;
@@ -217,31 +219,58 @@ static int dw_i2s_startup(struct snd_pcm_substream 
*substream,
return 0;
 }

+static void dw_i2s_config(struct dw_i2s_dev *dev, int stream)
+{
+   u32 ch_reg, irq;
+   struct i2s_clk_config_data *config = &dev->config;
+
+
+   i2s_disable_channels(dev, stream);
+
+   for (ch_reg = 0; ch_reg < (config->chan_nr / 2); ch_reg++) {
+   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   i2s_write_reg(dev->i2s_base, TCR(ch_reg),
+ dev->xfer_resolution);
+   i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
+   irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
+   i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
+   i2s_write_reg(dev->i2s_base, TER(ch_reg), 1);
+   } else {
+   i2s_write_reg(dev->i2s_base, RCR(ch_reg),
+ dev->xfer_resolution);
+   i2s_write_reg(dev->i2s_base, RFCR(ch_reg), 0x07);
+   irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
+   i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x03);
+   i2s_write_reg(dev->i2s_base, RER(ch_reg), 1);
+   }
+
+   }
+}
+
 static int dw_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
 {
struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
struct i2s_clk_config_data *config = &dev->config;
-   u32 ccr, xfer_resolution, ch_reg, irq;
int ret;

switch (params_format(params)) {
case SNDRV_PCM_FORMAT_S16_LE:
config->data_width = 16;
-   ccr = 0x00;
-   xfer_resolution = 0x02;
+   dev->ccr = 0x00;
+   dev->xfer_resolution = 0x02;
break;

case SNDRV_PCM_FORMAT_S24_LE:
config->data_width = 24;
-   ccr = 0x08;
-   xfer_resolution = 0x04;
+   dev->ccr = 0x08;
+   dev->xfer_resolution = 0x04;
break;

case SNDRV_PCM_FORMAT_S32_LE:
config->data_width = 32;
-   ccr = 0x10;
-   xfer_resolution = 0x05;
+   dev->ccr = 0x10;
+   dev->xfer_resolution = 0x05;
break;

default:
@@ -262,27 +291,9 @@ static int dw_i2s_hw_params(struct snd_pcm_substream 
*substream,
return -EINVAL;
}

-   i2s_disable_channels(dev, substream->stream);
+   dw_i2s_config(dev, substream->stream);

-   for (ch_reg = 0; ch_reg < (config->chan_nr / 2); ch_reg++) {
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   i2s_write_reg(dev->i2s_base, TCR(ch_reg),
- xfer_resolution);
-   i2s_write_reg(dev->i2s_base, TFCR(ch_reg), 0x02);
-   irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
-   i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x30);
-   i2s_write_reg(dev->i2s_base, TER(ch_reg), 1);
-   } else {
-   i2s_write_reg(dev->i2s_base, RCR(ch_reg),
- xfer_resolution);
-   i2s_write_reg(dev->i2s_base, RFCR(ch_reg), 0x07);
-   irq = i2s_read_reg(dev->i2s_base, IMR(ch_reg));
-   i2s_write_reg(dev->i2s_base, IMR(ch_reg), irq & ~0x03);
-   i2s_write_reg(dev->i2s_base, RER(ch_reg), 1);
-   }
-   }
-
-   i2s_write_reg(dev->i2s_base, CCR, ccr);
+   i2s_write_reg(dev->i2s_base, CCR, dev->ccr);

config->sample_rate = params_rate(params);

@@ -431,6 +442,11 @@ static int dw_i2s_resume(struct snd_soc_dai *dai)

if (dev->capability & DW_I2S_MASTER)
clk_enable(dev->clk);
+
+   if (dai->playback_active)
+   dw_i

[PATCH 04/13] ASoC: dwc: add quirk for different register offset

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

DWC in ACP 2.x IP has different offsets for I2S_COMP_PARAM_* registers.
Added a quirk to support the same.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 include/sound/designware_i2s.h |  5 +
 sound/soc/dwc/designware_i2s.c | 17 ++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/include/sound/designware_i2s.h b/include/sound/designware_i2s.h
index 8966ba7..e0bb458 100644
--- a/include/sound/designware_i2s.h
+++ b/include/sound/designware_i2s.h
@@ -45,6 +45,11 @@ struct i2s_platform_data {
u32 snd_fmts;
u32 snd_rates;

+   #define DW_I2S_QUIRK_COMP_REG_OFFSET(1 << 0)
+   unsigned int quirks;
+   unsigned int i2s_reg_comp1;
+   unsigned int i2s_reg_comp2;
+
void *play_dma_data;
void *capture_dma_data;
bool (*filter)(struct dma_chan *chan, void *slave);
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 3d7754c..940c881 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -94,6 +94,9 @@ struct dw_i2s_dev {
struct clk *clk;
int active;
unsigned int capability;
+   unsigned int quirks;
+   unsigned int i2s_reg_comp1;
+   unsigned int i2s_reg_comp2;
struct device *dev;

/* data related to DMA transfers b/w i2s and DMAC */
@@ -477,8 +480,8 @@ static int dw_configure_dai(struct dw_i2s_dev *dev,
 * Read component parameter registers to extract
 * the I2S block's configuration.
 */
-   u32 comp1 = i2s_read_reg(dev->i2s_base, I2S_COMP_PARAM_1);
-   u32 comp2 = i2s_read_reg(dev->i2s_base, I2S_COMP_PARAM_2);
+   u32 comp1 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp1);
+   u32 comp2 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp2);
u32 idx;

if (COMP1_TX_ENABLED(comp1)) {
@@ -521,7 +524,7 @@ static int dw_configure_dai_by_pd(struct dw_i2s_dev *dev,
   struct resource *res,
   const struct i2s_platform_data *pdata)
 {
-   u32 comp1 = i2s_read_reg(dev->i2s_base, I2S_COMP_PARAM_1);
+   u32 comp1 = i2s_read_reg(dev->i2s_base, dev->i2s_reg_comp1);
u32 idx = COMP1_APB_DATA_WIDTH(comp1);
int ret;

@@ -625,6 +628,14 @@ static int dw_i2s_probe(struct platform_device *pdev)
if (pdata) {
dev->capability = pdata->cap;
clk_id = NULL;
+   dev->quirks = pdata->quirks;
+   if (dev->quirks & DW_I2S_QUIRK_COMP_REG_OFFSET) {
+   dev->i2s_reg_comp1 = pdata->i2s_reg_comp1;
+   dev->i2s_reg_comp2 = pdata->i2s_reg_comp2;
+   } else {
+   dev->i2s_reg_comp1 = I2S_COMP_PARAM_1;
+   dev->i2s_reg_comp2 = I2S_COMP_PARAM_2;
+   }
ret = dw_configure_dai_by_pd(dev, dw_i2s_dai, res, pdata);
} else {
clk_id = "i2sclk";
-- 
1.8.3.1

[PATCH 03/13] ASoC: dwc: add runtime suspend/resume functionality

[Alex Deucher]

From: Maruthi Srinivas Bayyavarapu 

When DW controller is in master mode, it can disable/enable clock
during the device runtime suspend/resume sequence.

Signed-off-by: Maruthi Bayyavarapu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 sound/soc/dwc/designware_i2s.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 6e6a70c..3d7754c 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -394,6 +395,23 @@ static const struct snd_soc_component_driver 
dw_i2s_component = {
 };

 #ifdef CONFIG_PM
+static int dw_i2s_runtime_suspend(struct device *dev)
+{
+   struct dw_i2s_dev *dw_dev = dev_get_drvdata(dev);
+
+   if (dw_dev->capability & DW_I2S_MASTER)
+   clk_disable(dw_dev->clk);
+   return 0;
+}
+
+static int dw_i2s_runtime_resume(struct device *dev)
+{
+   struct dw_i2s_dev *dw_dev = dev_get_drvdata(dev);
+
+   if (dw_dev->capability & DW_I2S_MASTER)
+   clk_enable(dw_dev->clk);
+   return 0;
+}

 static int dw_i2s_suspend(struct snd_soc_dai *dai)
 {
@@ -649,7 +667,7 @@ static int dw_i2s_probe(struct platform_device *pdev)
goto err_clk_disable;
}
}
-
+   pm_runtime_enable(&pdev->dev);
return 0;

 err_clk_disable:
@@ -665,6 +683,7 @@ static int dw_i2s_remove(struct platform_device *pdev)
if (dev->capability & DW_I2S_MASTER)
clk_disable_unprepare(dev->clk);

+   pm_runtime_disable(&pdev->dev);
return 0;
 }

@@ -677,12 +696,17 @@ static const struct of_device_id dw_i2s_of_match[] = {
 MODULE_DEVICE_TABLE(of, dw_i2s_of_match);
 #endif

+static const struct dev_pm_ops dwc_pm_ops = {
+   SET_RUNTIME_PM_OPS(dw_i2s_runtime_suspend, dw_i2s_runtime_resume, NULL)
+};
+
 static struct platform_driver dw_i2s_driver = {
.probe  = dw_i2s_probe,
.remove = dw_i2s_remove,
.driver = {
.name   = "designware-i2s",
.of_match_table = of_match_ptr(dw_i2s_of_match),
+   .pm = &dwc_pm_ops,
},
 };

-- 
1.8.3.1

[PATCH 02/13] drm/amdgpu: add irq domain support

[Alex Deucher]

Hardware blocks on the GPU like ACP generate interrupts in
the GPU interrupt controller, but are driven by a separate
driver.  Add an irq domain to the GPU driver so that
blocks like ACP can register a Linux interrupt.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 108 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h |   9 +++
 drivers/gpu/drm/amd/amdgpu/cik_ih.c |   6 ++
 drivers/gpu/drm/amd/amdgpu/cz_ih.c  |   7 +++
 drivers/gpu/drm/amd/amdgpu/iceland_ih.c |   7 +++
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c   |   7 +++
 6 files changed, 136 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 7c42ff6..3006182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -312,6 +312,7 @@ int amdgpu_irq_add_id(struct amdgpu_device *adev, unsigned 
src_id,
}

adev->irq.sources[src_id] = source;
+
return 0;
 }

@@ -335,15 +336,19 @@ void amdgpu_irq_dispatch(struct amdgpu_device *adev,
return;
}

-   src = adev->irq.sources[src_id];
-   if (!src) {
-   DRM_DEBUG("Unhandled interrupt src_id: %d\n", src_id);
-   return;
-   }
+   if (adev->irq.virq[src_id]) {
+   generic_handle_irq(irq_find_mapping(adev->irq.domain, src_id));
+   } else {
+   src = adev->irq.sources[src_id];
+   if (!src) {
+   DRM_DEBUG("Unhandled interrupt src_id: %d\n", src_id);
+   return;
+   }

-   r = src->funcs->process(adev, src, entry);
-   if (r)
-   DRM_ERROR("error processing interrupt (%d)\n", r);
+   r = src->funcs->process(adev, src, entry);
+   if (r)
+   DRM_ERROR("error processing interrupt (%d)\n", r);
+   }
 }

 /**
@@ -461,3 +466,90 @@ bool amdgpu_irq_enabled(struct amdgpu_device *adev, struct 
amdgpu_irq_src *src,

return !!atomic_read(&src->enabled_types[type]);
 }
+
+/* gen irq */
+static void amdgpu_irq_mask(struct irq_data *irqd)
+{
+   /* XXX */
+}
+
+static void amdgpu_irq_unmask(struct irq_data *irqd)
+{
+   /* XXX */
+}
+
+static struct irq_chip amdgpu_irq_chip = {
+   .name = "amdgpu-ih",
+   .irq_mask = amdgpu_irq_mask,
+   .irq_unmask = amdgpu_irq_unmask,
+};
+
+static int amdgpu_irqdomain_map(struct irq_domain *d,
+   unsigned int irq, irq_hw_number_t hwirq)
+{
+   if (hwirq >= AMDGPU_MAX_IRQ_SRC_ID)
+   return -EPERM;
+
+   irq_set_chip_and_handler(irq,
+&amdgpu_irq_chip, handle_simple_irq);
+   return 0;
+}
+
+static struct irq_domain_ops amdgpu_hw_irqdomain_ops = {
+   .map = amdgpu_irqdomain_map,
+};
+
+/**
+ * amdgpu_irq_add_domain - create a linear irq domain
+ *
+ * @adev: amdgpu device pointer
+ *
+ * Create an irq domain for GPU interrupt sources
+ * that may be driven by another driver (e.g., ACP).
+ */
+int amdgpu_irq_add_domain(struct amdgpu_device *adev)
+{
+   adev->irq.domain = irq_domain_add_linear(NULL, AMDGPU_MAX_IRQ_SRC_ID,
+&amdgpu_hw_irqdomain_ops, 
adev);
+   if (!adev->irq.domain) {
+   DRM_ERROR("GPU irq add domain failed\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+/**
+ * amdgpu_irq_remove_domain - remove the irq domain
+ *
+ * @adev: amdgpu device pointer
+ *
+ * Remove the irq domain for GPU interrupt sources
+ * that may be driven by another driver (e.g., ACP).
+ */
+void amdgpu_irq_remove_domain(struct amdgpu_device *adev)
+{
+   if (adev->irq.domain) {
+   irq_domain_remove(adev->irq.domain);
+   adev->irq.domain = NULL;
+   }
+}
+
+/**
+ * amdgpu_irq_create_mapping - create a mapping between a domain irq and a
+ * Linux irq
+ *
+ * @adev: amdgpu device pointer
+ * @src_id: IH source id
+ *
+ * Create a mapping between a domain irq (GPU IH src id) and a Linux irq
+ * Use this for components that generate a GPU interrupt, but are driven
+ * by a different driver (e.g., ACP).
+ * Returns the Linux irq.
+ */
+unsigned amdgpu_irq_create_mapping(struct amdgpu_device *adev, unsigned src_id)
+{
+   adev->irq.virq[src_id] = irq_create_mapping(adev->irq.domain, src_id);
+
+   return adev->irq.virq[src_id];
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
index 17b01aef..e124b59 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h
@@ -24,6 +24,7 @@
 #ifndef __AMDGPU_IRQ_H__
 #define __AMDGPU_IRQ_H__

+#include 
 #include "amdgpu_ih.h"

 #define AMDGPU_MAX_IRQ_SRC_ID  0x100
@@ -65,6 +66,10 @@ struct amdgpu_irq {
/* interrupt ring */
struct amdgpu_ih_ring   ih;
const stru

[PATCH 01/13] drm/amdgpu/cgs: add an interface to access PCI resources

[Alex Deucher]

This provides an interface to get access to the base address
of PCI resources (MMIO, DOORBELL, etc.).  Only MMIO and
DOORBELL are implemented right now.  This is necessary to
properly utilize shared drivers on platform devices.  IP
modules can use this interface to get the base address
of the resource and add any additional offset and set the
size when setting up the platform driver(s).

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  | 36 
 drivers/gpu/drm/amd/include/cgs_common.h | 34 ++
 2 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 8e99514..7949927 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -398,6 +398,41 @@ static void amdgpu_cgs_write_pci_config_dword(void 
*cgs_device, unsigned addr,
WARN(ret, "pci_write_config_dword error");
 }

+
+static int amdgpu_cgs_get_pci_resource(void *cgs_device,
+  enum cgs_resource_type resource_type,
+  uint64_t size,
+  uint64_t offset,
+  uint64_t *resource_base)
+{
+   CGS_FUNC_ADEV;
+
+   if (resource_base == NULL)
+   return -EINVAL;
+
+   switch (resource_type) {
+   case CGS_RESOURCE_TYPE_MMIO:
+   if (adev->rmmio_size == 0)
+   return -ENOENT;
+   if ((offset + size) > adev->rmmio_size)
+   return -EINVAL;
+   *resource_base = adev->rmmio_base;
+   return 0;
+   case CGS_RESOURCE_TYPE_DOORBELL:
+   if (adev->doorbell.size == 0)
+   return -ENOENT;
+   if ((offset + size) > adev->doorbell.size)
+   return -EINVAL;
+   *resource_base = adev->doorbell.base;
+   return 0;
+   case CGS_RESOURCE_TYPE_FB:
+   case CGS_RESOURCE_TYPE_IO:
+   case CGS_RESOURCE_TYPE_ROM:
+   default:
+   return -EINVAL;
+   }
+}
+
 static const void *amdgpu_cgs_atom_get_data_table(void *cgs_device,
  unsigned table, uint16_t 
*size,
  uint8_t *frev, uint8_t *crev)
@@ -756,6 +791,7 @@ static const struct cgs_ops amdgpu_cgs_ops = {
amdgpu_cgs_write_pci_config_byte,
amdgpu_cgs_write_pci_config_word,
amdgpu_cgs_write_pci_config_dword,
+   amdgpu_cgs_get_pci_resource,
amdgpu_cgs_atom_get_data_table,
amdgpu_cgs_atom_get_cmd_table_revs,
amdgpu_cgs_atom_exec_cmd_table,
diff --git a/drivers/gpu/drm/amd/include/cgs_common.h 
b/drivers/gpu/drm/amd/include/cgs_common.h
index 992dcd8..646ebb7 100644
--- a/drivers/gpu/drm/amd/include/cgs_common.h
+++ b/drivers/gpu/drm/amd/include/cgs_common.h
@@ -105,6 +105,17 @@ enum cgs_ucode_id {
CGS_UCODE_ID_MAXIMUM,
 };

+/*
+ * enum cgs_resource_type - GPU resource type
+ */
+enum cgs_resource_type {
+   CGS_RESOURCE_TYPE_MMIO = 0,
+   CGS_RESOURCE_TYPE_FB,
+   CGS_RESOURCE_TYPE_IO,
+   CGS_RESOURCE_TYPE_DOORBELL,
+   CGS_RESOURCE_TYPE_ROM,
+};
+
 /**
  * struct cgs_clock_limits - Clock limits
  *
@@ -355,6 +366,23 @@ typedef void (*cgs_write_pci_config_word_t)(void 
*cgs_device, unsigned addr,
 typedef void (*cgs_write_pci_config_dword_t)(void *cgs_device, unsigned addr,
 uint32_t value);

+
+/**
+ * cgs_get_pci_resource() - provide access to a device resource (PCI BAR)
+ * @cgs_device:opaque device handle
+ * @resource_type: Type of Resource (MMIO, IO, ROM, FB, DOORBELL)
+ * @size:  size of the region
+ * @offset:offset from the start of the region
+ * @resource_base: base address (not including offset) returned
+ *
+ * Return: 0 on success, -errno otherwise
+ */
+typedef int (*cgs_get_pci_resource_t)(void *cgs_device,
+ enum cgs_resource_type resource_type,
+ uint64_t size,
+ uint64_t offset,
+ uint64_t *resource_base);
+
 /**
  * cgs_atom_get_data_table() - Get a pointer to an ATOM BIOS data table
  * @cgs_device:opaque device handle
@@ -516,6 +544,8 @@ struct cgs_ops {
cgs_write_pci_config_byte_t write_pci_config_byte;
cgs_write_pci_config_word_t write_pci_config_word;
cgs_write_pci_config_dword_t write_pci_config_dword;
+   /* PCI resources */
+   cgs_get_pci_resource_t get_pci_resource;
/* ATOM BIOS */
cgs_atom_get_data_table_t atom_get_data_table;
cgs_atom_get_cmd_table_revs_t atom_get_cmd_table_revs;
@@ -620,5 +650,9 @@ struct cgs_device
CGS_CALL(set_powergating_state, dev, block_type, st

[PATCH 00/13] Add ASoC support for AMD APUs [v5]

[Alex Deucher]

This patch set implements support for i2s audio and new AMD GPUs.
The i2s codec is fed by a DMA engine on the GPU.  To handle this
we create mfd cells which we hang the i2s codec and DMA engine on.
Because of this, this patch set covers two subsystems: drm and alsa.
The drm patches add support for the ACP hw block which provides the
DMA engine for the i2s codec.  The alsa patches add the ASoC driver
for the i2s codec.  Since the alsa changes depend on the drm changes,
I'd like to take the alsa patches in via the drm tree.

V2 changes:
- Use the MFD subsystem rather than adding our own bus
- Squash all sub-feature patches together
- fix comments mentioned in previous review

V3 changes:
- Update the designware driver to handle slave mode, amd specific
  features
- Use the designware driver directly for i2s
- Move the DMA handling from the GPU driver into the AMD ASoC
  driver
- Change the license on the ASoC driver to GPL

v4 changes:
- patch "ASoC : dwc : support dw i2s in slave mode" accepted
- Add a _dai_fmt() operation that checks to make sure that the mode
  we're setting corresponds to what we read back from the hardware.
- Split specific quirks into separate patches
- Set the specific quirks that apply to AMD chips in the acp driver

v5 changes:
- patch "ASoC : dwc : add check for master/slave format" accepted
- Fix MFD_CORE selection in ACP Kconfig
- Add irq domain support to amdgpu driver
- Use genirq in ACP DMA driver
- Export some genpd symbols to support ACP powergating (Acked by PM maintainer)
- Use genpd for ACP powergating
- add separate capture and playback instances of dws in ACP init
- add runtime suspend support for dws in master mode

Patch 9 adds the register headers for the ACP block which is a
pretty big patch so I've excluded it from email.  The entire patch
set can be viewed here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=acp-upstream8

Thanks,

Alex

Alex Deucher (3):
  drm/amdgpu/cgs: add an interface to access PCI resources
  drm/amdgpu: add irq domain support
  drm/amd: add pm domain for ACP IP sub blocks

Maruthi Bayyavarapu (1):
  drm/amd: add ACP driver support

Maruthi Srinivas Bayyavarapu (9):
  ASoC: dwc: add runtime suspend/resume functionality
  ASoC: dwc: add quirk for different register offset
  ASoC: dwc: reconfigure dwc in 'resume' from 'suspend'
  PM / Domains: export symbols to add/remove devices from genpd
  ASoC : AMD : add ACP 2.2 register headers
  ASoC: AMD: add ACP 2.x IP DMA abstraction layer
  ASoC: AMD: add AMD ASoC ACP 2.x DMA driver
  ASoC: AMD: add pm ops
  ASoC: AMD: Manage ACP 2.x SRAM banks power

 drivers/base/power/domain.c  |2 +
 drivers/gpu/drm/Kconfig  |2 +
 drivers/gpu/drm/amd/acp/Kconfig  |   11 +
 drivers/gpu/drm/amd/acp/Makefile |9 +
 drivers/gpu/drm/amd/acp/acp_hw.c |   50 +
 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h |   34 +
 drivers/gpu/drm/amd/amdgpu/Makefile  |   13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  |   12 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c  |  501 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h  |   42 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c  |   36 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c  |  108 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h  |9 +
 drivers/gpu/drm/amd/amdgpu/cik_ih.c  |6 +
 drivers/gpu/drm/amd/amdgpu/cz_ih.c   |7 +
 drivers/gpu/drm/amd/amdgpu/iceland_ih.c  |7 +
 drivers/gpu/drm/amd/amdgpu/tonga_ih.c|7 +
 drivers/gpu/drm/amd/amdgpu/vi.c  |   12 +
 drivers/gpu/drm/amd/include/amd_shared.h |1 +
 drivers/gpu/drm/amd/include/cgs_common.h |   34 +
 include/sound/designware_i2s.h   |5 +
 sound/soc/Kconfig|1 +
 sound/soc/Makefile   |1 +
 sound/soc/amd/Kconfig|4 +
 sound/soc/amd/Makefile   |3 +
 sound/soc/amd/acp-pcm-dma.c  |  560 +++
 sound/soc/amd/acp.c  |  666 
 sound/soc/amd/acp.h  |  140 ++
 sound/soc/amd/include/acp_2_2_d.h|  609 +++
 sound/soc/amd/include/acp_2_2_enum.h | 1068 
 sound/soc/amd/include/acp_2_2_sh_mask.h  | 2292 ++
 sound/soc/dwc/designware_i2s.c   |  113 +-
 32 files changed, 6325 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/acp/Kconfig
 create mode 100644 drivers/gpu/drm/amd/acp/Makefile
 create mode 100644 drivers/gpu/drm/amd/acp/acp_hw.c
 create mode 100644 drivers/gpu/drm/amd/acp/include/acp_gfx_if.h
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_acp.h
 create mode 100644 sound/soc/amd/Kconfig
 create mode 100644 sound/soc/amd/Makefile
 create mode 100644 sound/soc/amd/acp-pcm-dma.c
 create mode 100644 sound/soc/amd/acp.

[PATCH] nouveau/nvkm/subdev/clk/gk20a.c: fix wrong do_div() usage

[Thierry Reding]

On Tue, Nov 03, 2015 at 05:01:46PM -0500, Nicolas Pitre wrote:
> do_div() must only be used with a u64 dividend.
> 
> Signed-off-by: Nicolas Pitre 
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> index 254094ab7f..5da2aa8cc3 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> @@ -141,9 +141,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk *clk)
>  
>   rate = clk->parent_rate * clk->n;
>   divider = clk->m * pl_to_div[clk->pl];
> - do_div(rate, divider);
>  
> - return rate / 2;
> + return rate / divider / 2;
>  }
>  
>  static int

This causes build breakage on 32-bit ARM. I'm also confused by the
commit message because the code that I'm looking at has u64 rate and u32
divider, which matches the types given in include/asm-generic/div64.h:

 * The semantics of do_div() are:
 *
 * uint32_t do_div(uint64_t *n, uint32_t base)
 * {
 *  uint32_t remainder = *n % base;
 *  *n = *n / base;
 *  return remainder;
 * }

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151204/f67eefbf/attachment.sig>

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Marc Kleine-Budde]

On 12/04/2015 06:07 PM, Russell King - ARM Linux wrote:
> On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
>> Signed-off-by: Lucas Stach 
> 
> Acked-by: Russell King 
> 
> Although, I would like to be copied on patches, I don't think we
> have a way to encode that information in MAINTAINERS.

I think you can just add another
"M: Russell King " next to Lucas. We have this
for the CAN drivers and it seems to work.

> 
>> ---
>>  MAINTAINERS | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e9caa4b28828..1c69563c61ed 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -3741,6 +3741,13 @@ S:Maintained
>>  F:  drivers/gpu/drm/sti
>>  F:  Documentation/devicetree/bindings/display/st,stih4xx.txt
>>  
>> +DRM DRIVERS FOR VIVANTE GPU IP
>> +M:  Lucas Stach 
>> +L:  dri-devel at lists.freedesktop.org
>> +S:  Maintained
>> +F:  drivers/gpu/drm/etnaviv
>> +F:  Documentation/devicetree/bindings/display/etnaviv
>> +
>>  DSBR100 USB FM RADIO DRIVER
>>  M:  Alexey Klimov 
>>  L:  linux-media at vger.kernel.org
>> -- 
>> 2.6.2
>>
> 

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151204/6e853db6/attachment-0001.sig>

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Lucas Stach]

Am Freitag, den 04.12.2015, 17:13 + schrieb Russell King - ARM
Linux:
> On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
> > On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
> >  wrote:
> > > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> > >> Signed-off-by: Lucas Stach 
> > >
> > > Acked-by: Russell King 
> > >
> > > Although, I would like to be copied on patches, I don't think we
> > > have a way to encode that information in MAINTAINERS.
> > 
> > >From the top of the MAINTAINERS file:
> > 
> > Descriptions of section entries:
> > 
> > P: Person (obsolete)
> > M: Mail patches to: FullName 
> > R: Designated reviewer: FullName 
> >These reviewers should be CCed on patches.
> > 
> > So I guess that'd mean you want to be a reviewer?
> 
> Oh, that got agreed upon?  I thought there was pushback against that
> idea.
> 
There was pushback to change random people in MAINTAINERS from
maintainer to reviewer just because they don't manage a git tree on
their own. The reviewer tag itself was agreed upon.

If you want to be CC'ed on patches we should definitely add you as a
reviewer.

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Christian Gmeiner]

2015-12-04 18:13 GMT+01:00 Russell King - ARM Linux :
> On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
>>  wrote:
>> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
>> >> Signed-off-by: Lucas Stach 
>> >
>> > Acked-by: Russell King 
>> >
>> > Although, I would like to be copied on patches, I don't think we
>> > have a way to encode that information in MAINTAINERS.
>>
>> >From the top of the MAINTAINERS file:
>>
>> Descriptions of section entries:
>>
>> P: Person (obsolete)
>> M: Mail patches to: FullName 
>> R: Designated reviewer: FullName 
>>These reviewers should be CCed on patches.
>>
>> So I guess that'd mean you want to be a reviewer?
>
> Oh, that got agreed upon?  I thought there was pushback against that
> idea.
>
> You are correct.
>

Put me on the reviewer list too.

greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

[PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel

[Inki Dae]

Hi Rob,

2015년 12월 04일 08:38에 Rob Herring 이(가) 쓴 글:
> On Thu, Dec 03, 2015 at 06:30:10PM +0900, Inki Dae wrote:
>> This patch updates a ports node binding for panel.
>>
>> With this, dp node can have a ports node which describes
>> a remote endpoint node that can be connected to panel or bridge
>> node.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  .../bindings/display/exynos/exynos_dp.txt  | 28 
>> ++
>>  1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
>> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> index 64693f2..15b52cb 100644
>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>>  Hotplug detect GPIO.
>>  Indicates which GPIO should be used for hotplug
>>  detection
>> --video interfaces: Device node can contain video interface port
>> -nodes according to [1].
>> +Video interfaces:
>> +  Device node can contain video interface port nodes according to [1].
>> +  The following are properties specific to those nodes:
>> +
>> +  endpoint node connected to bridge or panel node:
>> +   - remote-endpoint: specifies the endpoint in panel or bridge node.
>> +  This node is required in all kinds of exynos dp
>> +  to represent the connection between dp and bridge
>> +  ,or dp and panel.
> 
> Fix your punctuation.

Right. 

> 
>>  
>>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>  
>> @@ -111,9 +118,22 @@ Board Specific portion:
>>  };
>>  
>>  ports {
>> -port at 0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
> 
> You don't need these.

Ditto.

> 
>> +
>> +port {
>>  dp_out: endpoint {
>> -remote-endpoint = <&bridge_in>;
>> +remote-endpoint = <&dp_in>;
>> +};
>> +};
>> +};
>> +
>> +panel at 0 {
>> +reg = <0>;
> 
> Drop the @0 and reg as you only have 1.

Ditto.

Thanks,
Inki Dae

> 
>> +...
>> +port {
>> +dp_in: endpoint {
>> +remote-endpoint = <&dp_out>;
>>  };
>>  };
>>  };
>> -- 
>> 1.9.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

dumb BOs and prime

[Daniel Stone]

Hi Rob,

On 4 December 2015 at 17:49, Rob Herring  wrote:
> I'm working on getting Android working with DRM drivers. ATM, I'm
> using virtio-gpu as the driver and trying to get just KMS side working
> without rendering. I have it working with stock AOSP and the emulated
> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
> get things working with native KMS using drm_gralloc and
> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
> not sure how to solve without hacking around it.
>
> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
> allowed on render nodes and drmPrimeHandleToFD is not allowed on
> card0, so I'm stuck. I could open both nodes, but then I want the case
> of no render node to work. After some searching, I thought it was a
> matter of needing to do drmAuthMagic, but then found that is
> considered obsolete[2].

drmPrimeHandleToFD definitely is allowed on card0; does the driver set
the DRIVER_PRIME cap, and have a prime_handle_to_fd hook?

Cheers,
Daniel

[PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel

[Inki Dae]

Hi Javier,

2015년 12월 03일 22:29에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> On 12/03/2015 06:30 AM, Inki Dae wrote:
>> This patch updates a ports node binding for panel.
>>
>> With this, dp node can have a ports node which describes
>> a remote endpoint node that can be connected to panel or bridge
>> node.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  .../bindings/display/exynos/exynos_dp.txt  | 28 
>> ++
>>  1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
>> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> index 64693f2..15b52cb 100644
>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>>  Hotplug detect GPIO.
>>  Indicates which GPIO should be used for hotplug
>>  detection
>> --video interfaces: Device node can contain video interface port
>> -nodes according to [1].
>> +Video interfaces:
>> +  Device node can contain video interface port nodes according to [1].
>> +  The following are properties specific to those nodes:
>> +
>> +  endpoint node connected to bridge or panel node:
>> +   - remote-endpoint: specifies the endpoint in panel or bridge node.
>> +  This node is required in all kinds of exynos dp
>> +  to represent the connection between dp and bridge
>> +  ,or dp and panel.
>>
> 
> This is nice but I think the DT binding should also document that it uses
> a phandle to define the connection with the panel (but explain that is
> deprecated). If only so people looking at a DTS and then going to the DT
> binding can understand why there is two ways to define the same.
>   
>>  [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>  
>> @@ -111,9 +118,22 @@ Board Specific portion:
>>  };
>>  
>>  ports {
>> -port at 0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
> 
> These two properties are only needed when there is more than 2 ports and
> a reg property is used to number the port nodes but I don't think that's
> the case for Exynos DP and certainly is not the case in this example so
> I think you should just remove them.

Right. I found out that the dp can have only one port outbound. Will remove 
them.

> 
>> +port {
>>  dp_out: endpoint {
>> -remote-endpoint = <&bridge_in>;
>> +remote-endpoint = <&dp_in>;
>> +};
>> +};
>> +};
>> +
>> +panel at 0 {
>> +reg = <0>;
>> +...
>> +port {
>> +dp_in: endpoint {
>> +remote-endpoint = <&dp_out>;
>>  };
>>  };
>>  };
>>
> 
> The rest looks good to me so with the two changes feel free to add:
> 
> Reviewed-by: Javier Martinez Canillas 

Thanks,
Inki Dae

> 
> Best regards,
> 

[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

[Inki Dae]

Hi Javier,

2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> I found that v2 of this patch is alredy in your exynos-drm for-next branch so
> so I had to revert it in linux-next to apply this one to test. You shouldn't
> push patches that were still not reviewed (specially the ones that weren't
> tested like this one) to your branch that gets pulled by -next. The idea of
> -next is to have some test coverage but it should be as stable as possible.

exynos-drm/for-next branch is not really for-next branch. This branch is used
only for integration test. As you know, there are many exynos maintainers
and they have their own repository. So we would need to test the integration.
For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and
tested patches will be merged to exynos-drm-next.

> 
> On 12/03/2015 06:30 AM, Inki Dae wrote:
>> This patch adds of_graph dt binding support for panel device
>> and also keeps the backward compatibility.
>>
>> i.e.,
>> The dts file for Exynos5800 based peach pi board
>> has a panel property so we need to keep the backward compatibility.
>>
>> Changelog v3:
>> - bind only one of two nodes outbound - panel or bridge.
>>
> 
> This patch fixes one of the comments I had for v2 but I've another
> comment below.
>  
>> Changelog v2:
>> - return -EINVAL if getting a port node failed.
>>
>> Signed-off-by: Inki Dae 
>> ---
>>  drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 94f02a0..60260a0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
>>  static int exynos_dp_probe(struct platform_device *pdev)
>>  {
>>  struct device *dev = &pdev->dev;
>> -struct device_node *panel_node, *bridge_node, *endpoint;
>> +struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
>>  struct exynos_dp_device *dp;
>>  int ret;
>>  
>> @@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device 
>> *pdev)
>>  
>>  platform_set_drvdata(pdev, dp);
>>  
>> +/* This is for the backward compatibility. */
>>  panel_node = of_parse_phandle(dev->of_node, "panel", 0);
>>  if (panel_node) {
>>  dp->panel = of_drm_find_panel(panel_node);
>>  of_node_put(panel_node);
>>  if (!dp->panel)
>>  return -EPROBE_DEFER;
>> +} else {
>> +endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>> +if (endpoint) {
>> +panel_node = of_graph_get_remote_port_parent(endpoint);
> 
> Here is asssumed that the endpoint will be a panel but it could be that there
> is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so
> this assumption seems fragile to me.
> 
> That's what I meant when I said "Assuming you can make a distinction if the
> endpoint is a panel or a bridge" in the other thread.
> 
>> +if (panel_node) {
>> +dp->panel = of_drm_find_panel(panel_node);
>> +of_node_put(panel_node);
>> +if (!dp->panel)
>> +return -EPROBE_DEFER;
>> +} else {
>> +DRM_ERROR("no port node for panel device.\n");
>> +return -EINVAL;
>> +}
>> +}
>>  }
>>  
>> +if (endpoint)
>> +goto out;
>> +
> 
> Ok, so IIUC what's done here is to test if the panel lookup failed, then the
> endpoint is looked up again but this time a call to of_drm_find_bridge() is
> made instead of a call to of_drm_find_panel(). I wonder if there is a better
> way to do this...
> 
> In any case then I think you should test if (panel_node) instead of endpoint.
> 
>>  endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>>  if (endpoint) {
>>  bridge_node = of_graph_get_remote_port_parent(endpoint);
>> @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device 
>> *pdev)
>>  return -EPROBE_DEFER;
>>  }
>>  
>> +out:
>>  pm_runtime_enable(dev);
>>  
>>  ret = component_add(&pdev->dev, &exynos_dp_ops);
>>
> 
> I can't think of a better way to lookup either a panel or a bridge though
> and I'm not that familiar with DRM so with the correct check, the patch
> looks good to me.
> 
> Reviewed-by: Javier Martinez Canillas 
> 
> Also on an Exynos5800 Peach Pi with the DTS patch I shared, the display
> is working correctly and also I tested without the DTS patch to make
> sure that it does not cause a regression for older DTBs.
> 
> Tes

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 11:33:22AM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
> wrote:
> > I'm aware of that, but I don't see much value in kicking this discussion
> > around for every DRM driver submission. This is the binding that has
> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> > allows us to standardize on _something_. Also ALSA does a similar thing
> > to bind codecs and CPU interfaces together.
> 
> This case is quite different though I think. The ALSA case and other
> DRM cases are ones that have inter-dependencies between the blocks
> (e.g. some sort of h/w connection). What is the inter-dependency here?

Different GPU cores, where each GPU core is a separate device.  On iMX6,
we have three different GPU cores, two of which need to do cross-GPU
synchronisation for accesses to the buffers.

Sure, we could have decided to publish three entirely different DRM
devices, but that has serious implications: we would be highly non-
standard on the DRI and XF86 cases, to the point where it'd probably
be beyond any hope in getting it to work sanely.  DRI2 requires the
DRM device to be used by MESA to be passed across the X protocol to
authorise the MESA side.

It's already icky enough with the separate DRM device for KMS - which
having poked about with DRI3, I can't see really working at the moment.

> > Same as above really. Parts of the identification registers are
> > different for each SoC integration, even if it's the same IP core, so we
> > can just derive any needed driver behavior differences from that.
> 
> The h/w designers must have had a clue about s/w. First time for
> everything... ;)
> 
> Ok, please just add a note to the binding why a more specific
> compatible is not needed in this case.

If we did want to be safe, we _could_ require something like:

compatible = "vivante,gc320", "vivante,gc";

but I don't see much value to that, because, from what I can see if the
way the GPU numbering/versioning scheme works, the revision number is
the more important bit of information: I believe this started at 1 which
has been incremented ever since.

This can be seen as the GC600 is a much older core than the GC320.

The GC numbering tells you nothing (as far as can be worked out yet)
about what features, what kind of GPU, or anything like that.

Another example: the iMX6 S/DL has a GC880 instead of a GC2000.  While
both are a 3D GPU, they're not really "compatible" with each other -
GC880 has one pixel pipe which requires userspace buffers to be tiled
one way, vs GC2000 which has a different form of tiling to allow two
pixel pipes to operate efficiently.

The number of pixel pipes (and other features) comes from the feature/
specification registers embedded in the device - there's currently 6
32-bit registers, each containing 32 feature flags, describing what
features are present, and including what bugs are present and/or have
been fixed.

There have been one "slip-up" along the way, where the Vivante software
folk have comments in the code along the lines of "Hardware people should
talk to us!!!" which tends to suggest that they've hit the communication
problem, and as it's for very early stuff, and nothing later, it suggests
that they've learnt that lesson themselves already. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"

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

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

--- Comment #16 from Ernst Sjöstrand  ---
I tried the v2 amdgpu patch on top of agd5f/amdgpu-powerplay and my screens
never turn on with it.

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

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Ilia Mirkin]

On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
 wrote:
> On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>>  wrote:
>> > Moreover, DRI3 is not yet available for Gallium, so if we're talking
>> > about Xorg, then functional DRI2 is a requirement, and that _needs_
>> > to have a single device for the rendering instances.  Xorg has no way
>> > to pass multiple render nodes to client over DRI2.
>>
>> Just to correct... DRI3 has been available on gallium [at least in the
>> context of st/mesa] basically since DRI3 was introduced. Not sure what
>> issue you're fighting with, but it's definitely not a gallium
>> limitation... could be something related to platform devices.
>
> Well, my statement is based on the fact that there's nothing in
> src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
> implemented differently, I don't know.  I never wanted to hack MESA -
> I'm supposed to be the ARM kernel maintainer - and I'm still very new
> to MESA.
>
> I think it's a DRI3 limitation.  The issue with the DRI3 design is that:
>
> * The client has access to the GPU render nodes only, but not the
>   corresponding KMS node.
> * Buffers in DRI3 are allocated from the GPU render nodes.
> * The Xorg Present protocol is then used to manage the vblank
>   synchonisation and page flips.
>
> Now, the KMS scanout hardware typically does not support any kind of
> scatter-gather: the buffers it has must be contiguous.  These can be
> allocated from the KMS DRM device.
>
> However, the DRI3 client has no access to the KMS DRM device to allocate
> linear buffers from, and GPUs typically don't have dumb buffer support.
> Hence, the client can't pass a suitable buffer to the present layer.
>
> Hence, I can see no way for the resource_create() to be able to allocate
> any kind of scanout capable buffer.
>
> That's a separate issue though: you've pointed out that you can select
> which render node to use: what if we want to use multiple render nodes
> simultaneously - eg, because we want to use multiple 3D GPU cores
> together?  How does that work with stuff?

This is a bit like the SLI question -- let's say you have 2 pricey
desktop GPUs, with a fast interconnect between them, which lets them
know about each other, how do you make use of that. Solution: unsolved
:)

In an ideal world, you'd have a single driver that knows how to
interact with multiple devices and make them do cool things. However
this a completely untrodden path. (Not to mention the problem of *how*
to break up a workload across 2 GPUs.)

>
> I think the idea that individual GPU cores should be exposed as
> separate DRM devices is fundamentally flawed, and adds a hell of a
> lot of complexity.
>
> In any case, I've spent _way_ too much time on etnaviv during November -
> quite literally almost every day (I worked out that I was producing 4.5
> patches a day during November for Etnaviv MESA.)  I'm afraid that it's
> now time that I switch my attention elsewhere, so if this means that
> Etnaviv is rejected for merging, I'm afraid it'll be a few months before
> I can get back to it.
>
> It would have been nice if these issues had been brought up much earlier,
> during the RFC posting of the patches.  These are nothing new, and I now
> feel that this whole thing has been a total waste of time.

The whole multi-gpu thing is a bit of an open question right now. It
works in theory, but in practice nobody's done it. Maarten tried to
get nouveau/gk20a + tegra/drm on Jetson TK1 to play nice with, e.g., X
2d accel, and it was an exercise in pain. Not sure that he ever
succeeded.

I think it's unfair to try to make new hardware enablement the time to
attempt to heap extra work onto those authors unfortunate enough to
have slightly unorthodox hardware that maps nicely onto some
desired-but-not-quite-there-yet usage model -- they have enough
problems.

The way everything works is one drm node can do everything. PRIME is a
barely-functional way to offload some things onto a (single) secondary
GPU. Everything beyond that is purely theoretical.

None of what's being done now prevents some future where these things
are broken up. No need to force it now.

  -ilia

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Lucas Stach]

Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > Etnaviv follows the same priciple as imx-drm to have a virtual
> > master device node to bind all the individual GPU cores together
> > into one DRM device.
> > 
> > Signed-off-by: Lucas Stach 
> > ---
> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
> > ++
> >  1 file changed, 46 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > new file mode 100644
> > index ..19fde29dc1d7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
> > @@ -0,0 +1,46 @@
> > +Etnaviv DRM master device
> > +
> > +
> > +The Etnaviv DRM master device is a virtual device needed to list all
> > +Vivante GPU cores that comprise the GPU subsystem.
> > +
> > +Required properties:
> > +- compatible: Should be one of
> > +"fsl,imx-gpu-subsystem"
> > +"marvell,dove-gpu-subsystem"
> > +- cores: Should contain a list of phandles pointing to Vivante GPU devices
> > +
> > +example:
> > +
> > +gpu-subsystem {
> > +   compatible = "fsl,imx-gpu-subsystem";
> > +   cores = <&gpu_2d>, <&gpu_3d>;
> > +};
> 
> Yeah, I'm not really a fan of doing this simply because DRM wants 1 
> driver.
> 
I'm aware of that, but I don't see much value in kicking this discussion
around for every DRM driver submission. This is the binding that has
emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
allows us to standardize on _something_. Also ALSA does a similar thing
to bind codecs and CPU interfaces together.

> > +
> > +
> > +Vivante GPU core devices
> > +
> > +
> > +Required properties:
> > +- compatible: Should be "vivante,gc"
> 
> This should at least have the specific cores listed like gc-5000 or 
> whatever the numbering is. As is, I can't even tell if this a 2d or 3d 
> core.
> 
There is really no need for this. The cores have identification
registers that are much more accurate than what we could describe with a
compatible value. So using a more specific compatible just provides
redundant (and possibly wrong) information.

> Also, it probably should have an SOC specific property to deal with SOC 
> specific configuration or integration.
> 
Same as above really. Parts of the identification registers are
different for each SoC integration, even if it's the same IP core, so we
can just derive any needed driver behavior differences from that.

> > +- reg: should be register base and length as documented in the
> > +  datasheet
> > +- interrupts: Should contain the cores interrupt line
> > +- clocks: should contain one clock for entry in clock-names
> > +  see Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +- clock-names:
> > +   - "bus":AXI/register clock
> > +   - "core":   GPU core clock
> > +   - "shader": Shader clock (only required if GPU has feature PIPE_3D)
> > +
> > +example:
> > +
> > +gpu_3d: gpu at 0013 {
> > +   compatible = "vivante,gc";
> > +   reg = <0x0013 0x4000>;
> > +   interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
> > +<&clks IMX6QDL_CLK_GPU3D_CORE>,
> > +<&clks IMX6QDL_CLK_GPU3D_SHADER>;
> > +   clock-names = "bus", "core", "shader";
> > +};
> > -- 
> > 2.6.2
> > 

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 06:26:38PM +0100, Marc Kleine-Budde wrote:
> On 12/04/2015 06:07 PM, Russell King - ARM Linux wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach 
> > 
> > Acked-by: Russell King 
> > 
> > Although, I would like to be copied on patches, I don't think we
> > have a way to encode that information in MAINTAINERS.
> 
> I think you can just add another
> "M: Russell King " next to Lucas. We have this
> for the CAN drivers and it seems to work.

What I'm after avoiding is ending up having to look after this - I've
already enough things on my plate, and I'm not good at context switching
between them.

However, given that I have the ability to test changes on both Dove and
iMX6, that's why I'd like to be Cc'd, so that I can (when I have the
available time) test on Dove, but I don't want to be in the situation
where I'm being required to give acks etc.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 3/4] drm, ipu-v3: use https://linuxtv.org for LinuxTV URL

[Philipp Zabel]

Am Freitag, den 04.12.2015, 10:46 -0200 schrieb Mauro Carvalho Chehab:
> While https was always supported on linuxtv.org, only in
> Dec 3 2015 the website is using valid certificates.
> 
> As we're planning to drop pure http support on some
> future, change the references at DRM include and at
> the ipu-v3 driver to point to the https://linuxtv.org
> URL instead.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Philipp Zabel 

regards
Philipp

[Bug 92996] [Fiji/amdgpu/Powerplay] Problems with interactivity, performance, EQ overflow with Powerplay

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

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

Ernst Sjöstrand  changed:

   What|Removed |Added

Summary|[Fiji/amdgpu/Powerplay] |[Fiji/amdgpu/Powerplay]
   |Problems with vsync,|Problems with
   |interactivity, performance, |interactivity, performance,
   |EQ overflow with Powerplay  |EQ overflow with Powerplay

--- Comment #15 from Ernst Sjöstrand  ---
Ah, I had been running with LIBGL_DRI3_DISABLE=1 because of
https://bugs.freedesktop.org/show_bug.cgi?id=84252
https://bugzilla.mozilla.org/show_bug.cgi?id=1069523

So only applying that variable to Firefox it seems like I can't break vsync.
(This was OK before powerplay though?)

I saw a bunch of regressions when switching to the powerplay kernel so I listed
them here, thinking they were caused by "powerplay". The rest are still there.

-- 
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/20151204/3a3c6b0a/attachment.html>

[PATCH] drm: Move encoder->save/restore into nouveau

[Daniel Vetter]

Nouveau is the only user, and atomic drivers should do state
save/restoring differently. So move it into noveau.

Saves me typing some kerneldoc, too ;-)

v2: Move misplaced hunk into earlier nouveau patch.

Cc: Ilia Mirkin 
Cc: Ben Skeggs 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv04/dac.c|  7 +++
 drivers/gpu/drm/nouveau/dispnv04/dfp.c|  7 +++
 drivers/gpu/drm/nouveau/dispnv04/disp.c   | 32 ---
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c |  5 +++--
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c |  5 +++--
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  3 +++
 include/drm/drm_modeset_helper_vtables.h  |  4 
 7 files changed, 27 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c 
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 78cb033bc015..6c442def403d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -504,8 +504,6 @@ static void nv04_dac_destroy(struct drm_encoder *encoder)

 static const struct drm_encoder_helper_funcs nv04_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
-   .save = nv04_dac_save,
-   .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -515,8 +513,6 @@ static const struct drm_encoder_helper_funcs 
nv04_dac_helper_funcs = {

 static const struct drm_encoder_helper_funcs nv17_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
-   .save = nv04_dac_save,
-   .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -545,6 +541,9 @@ nv04_dac_create(struct drm_connector *connector, struct 
dcb_output *entry)
nv_encoder->dcb = entry;
nv_encoder->or = ffs(entry->or) - 1;

+   nv_encoder->enc_save = nv04_dac_save;
+   nv_encoder->enc_restore = nv04_dac_restore;
+
if (nv_gf4_disp_arch(dev))
helper = &nv17_dac_helper_funcs;
else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c 
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index 429ab5e3025a..4c5fb89d74db 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -652,8 +652,6 @@ static void nv04_tmds_slave_init(struct drm_encoder 
*encoder)

 static const struct drm_encoder_helper_funcs nv04_lvds_helper_funcs = {
.dpms = nv04_lvds_dpms,
-   .save = nv04_dfp_save,
-   .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -663,8 +661,6 @@ static const struct drm_encoder_helper_funcs 
nv04_lvds_helper_funcs = {

 static const struct drm_encoder_helper_funcs nv04_tmds_helper_funcs = {
.dpms = nv04_tmds_dpms,
-   .save = nv04_dfp_save,
-   .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -701,6 +697,9 @@ nv04_dfp_create(struct drm_connector *connector, struct 
dcb_output *entry)
if (!nv_encoder)
return -ENOMEM;

+   nv_encoder->enc_save = nv04_dfp_save;
+   nv_encoder->enc_restore = nv04_dfp_restore;
+
encoder = to_drm_encoder(nv_encoder);

nv_encoder->dcb = entry;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 59242ff767ea..b4a6bc433ef5 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,6 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
+   struct nouveau_encoder *nv_encoder;
struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -110,11 +111,8 @@ nv04_display_create(struct drm_device *dev)
list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
crtc->save(&crtc->base);

-   list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
-   const struct drm_encoder_helper_funcs *func = 
encoder->helper_private;
-
-   func->save(encoder);
-   }
+   list_for_each_entry(nv_encoder, &dev->mode_config.encoder_list, 
base.base.head)
+   nv_encoder->enc_save(&nv_encoder->base.base);

nouveau_overlay_init(dev);

@@ -126,7 +124,7 @@ nv04_display_destroy(struct drm_device *dev)
 {
struct nv04_display *disp = nv04_display(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
-   struct drm_encoder *encoder;
+   struct nouveau_encoder *encoder;
struct drm_crtc *crtc;
struct nouveau_crtc *nv_crtc;

@@ -140,11 +138,8 @@ nv04_display_destroy(struct drm_device *dev)
}

/* Restore state */
-   list_for_each_entry(encoder, &dev->mode

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
>  wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach 
> >
> > Acked-by: Russell King 
> >
> > Although, I would like to be copied on patches, I don't think we
> > have a way to encode that information in MAINTAINERS.
> 
> >From the top of the MAINTAINERS file:
> 
> Descriptions of section entries:
> 
> P: Person (obsolete)
> M: Mail patches to: FullName 
> R: Designated reviewer: FullName 
>These reviewers should be CCed on patches.
> 
> So I guess that'd mean you want to be a reviewer?

Oh, that got agreed upon?  I thought there was pushback against that
idea.

You are correct.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm/nouveau: Use private save/restore hooks for CRTCs

[Daniel Vetter]

I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(gma500 besides nouveau) really using them.

v2: Fixup bugs Ilia spotted.

Cc: Ben Skeggs 
Cc: Ilia Mirkin 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |  5 +++--
 drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++-
 drivers/gpu/drm/nouveau/nouveau_crtc.h  |  3 +++
 3 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index dab24066fa21..bb9e9cb14b9d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
 }

 static const struct drm_crtc_funcs nv04_crtc_funcs = {
-   .save = nv_crtc_save,
-   .restore = nv_crtc_restore,
.cursor_set = nv04_crtc_cursor_set,
.cursor_move = nv04_crtc_cursor_move,
.gamma_set = nv_crtc_gamma_set,
@@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
nv_crtc->index = crtc_num;
nv_crtc->last_dpms = NV_DPMS_CLEARED;

+   nv_crtc->save = nv_crtc_save;
+   nv_crtc->restore = nv_crtc_restore;
+
drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 9e650081c357..59242ff767ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
-   struct drm_crtc *crtc;
+   struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;

@@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
}

/* Save previous state */
-   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
-   crtc->funcs->save(crtc);
+   list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
+   crtc->save(&crtc->base);

list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
const struct drm_encoder_helper_funcs *func = 
encoder->helper_private;
@@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_encoder *encoder;
struct drm_crtc *crtc;
+   struct nouveau_crtc *nv_crtc;

/* Turn every CRTC off. */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
func->restore(encoder);
}

-   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
-   crtc->funcs->restore(crtc);
+   list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
+   nv_crtc->restore(&nv_crtc->base);

nouveau_hw_save_vga_fonts(dev, 0);

diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h 
b/drivers/gpu/drm/nouveau/nouveau_crtc.h
index f19cb1c5fc5a..863f10b8d818 100644
--- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
+++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
@@ -73,6 +73,9 @@ struct nouveau_crtc {
int (*set_dither)(struct nouveau_crtc *crtc, bool update);
int (*set_scale)(struct nouveau_crtc *crtc, bool update);
int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
+
+   void (*save)(struct drm_crtc *crtc);
+   void (*restore)(struct drm_crtc *crtc);
 };

 static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
-- 
2.5.1

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> Signed-off-by: Lucas Stach 

Acked-by: Russell King 

Although, I would like to be copied on patches, I don't think we
have a way to encode that information in MAINTAINERS.

> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9caa4b28828..1c69563c61ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3741,6 +3741,13 @@ S: Maintained
>  F:   drivers/gpu/drm/sti
>  F:   Documentation/devicetree/bindings/display/st,stih4xx.txt
>  
> +DRM DRIVERS FOR VIVANTE GPU IP
> +M:   Lucas Stach 
> +L:   dri-devel at lists.freedesktop.org
> +S:   Maintained
> +F:   drivers/gpu/drm/etnaviv
> +F:   Documentation/devicetree/bindings/display/etnaviv
> +
>  DSBR100 USB FM RADIO DRIVER
>  M:   Alexey Klimov 
>  L:   linux-media at vger.kernel.org
> -- 
> 2.6.2
> 

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 13/28] drm/nouveau: Use private save/restore hooks

[Daniel Vetter]

On Fri, Dec 04, 2015 at 09:31:01AM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter  
> wrote:
> > I want to remove the core ones since with atomic drivers system
> > suspend/resume is solved much differently. And there's only 2 drivers
> > (gma500 besides nouveau) really using them.
> >
> > Cc: Ben Skeggs 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  5 +++--
> >  drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++-
> >  drivers/gpu/drm/nouveau/nouveau_crtc.h  |  3 +++
> >  3 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > index dab24066fa21..bb9e9cb14b9d 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > @@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
> >  }
> >
> >  static const struct drm_crtc_funcs nv04_crtc_funcs = {
> > -   .save = nv_crtc_save,
> > -   .restore = nv_crtc_restore,
> > .cursor_set = nv04_crtc_cursor_set,
> > .cursor_move = nv04_crtc_cursor_move,
> > .gamma_set = nv_crtc_gamma_set,
> > @@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
> > nv_crtc->index = crtc_num;
> > nv_crtc->last_dpms = NV_DPMS_CLEARED;
> >
> > +   nv_crtc->save = nv_crtc_save;
> > +   nv_crtc->restore = nv_crtc_restore;
> > +
> > drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
> > drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
> > drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
> > b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > index 9e650081c357..ebd9430e0628 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > @@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
> > struct dcb_table *dcb = &drm->vbios.dcb;
> > struct drm_connector *connector, *ct;
> > struct drm_encoder *encoder;
> > -   struct drm_crtc *crtc;
> > +   struct nouveau_crtc *crtc;
> > struct nv04_display *disp;
> > int i, ret;
> >
> > @@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
> > }
> >
> > /* Save previous state */
> > -   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> > -   crtc->funcs->save(crtc);
> > +   list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> > +   crtc->save(crtc);
> 
> Won't this warn about incompatible types? (function wants drm_crtc,
> but you're giving it nouveau_crtc)?

Because I misapplied a hunk and it's in the next nouveau patch ;-)
> 
> >
> > list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
> > const struct drm_encoder_helper_funcs *func = 
> > encoder->helper_private;
> > @@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct drm_encoder *encoder;
> > struct drm_crtc *crtc;
> > +   struct nouveau_crtc *nv_crtc;
> >
> > /* Turn every CRTC off. */
> > list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > @@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
> > func->restore(encoder);
> > }
> >
> > -   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> > -   crtc->funcs->restore(crtc);
> > +   list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
> > +   nv_crtc->restore(crtc);
> 
> Why is this OK? Don't you want to use nv_crtc here as the function argument?

Total bullocks and embarrassing. Will resend both.
-Daniel

> 
> >
> > nouveau_hw_save_vga_fonts(dev, 0);
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h 
> > b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > index f19cb1c5fc5a..863f10b8d818 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > @@ -73,6 +73,9 @@ struct nouveau_crtc {
> > int (*set_dither)(struct nouveau_crtc *crtc, bool update);
> > int (*set_scale)(struct nouveau_crtc *crtc, bool update);
> > int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
> > +
> > +   void (*save)(struct drm_crtc *crtc);
> > +   void (*restore)(struct drm_crtc *crtc);
> >  };
> >
> >  static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
> > --
> > 2.5.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 05:41:45PM +0100, Lucas Stach wrote:
> Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > > +gpu-subsystem {
> > > + compatible = "fsl,imx-gpu-subsystem";
> > > + cores = <&gpu_2d>, <&gpu_3d>;
> > > +};
> > 
> > Yeah, I'm not really a fan of doing this simply because DRM wants 1 
> > driver.
> > 
> I'm aware of that, but I don't see much value in kicking this discussion
> around for every DRM driver submission. This is the binding that has
> emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
> allows us to standardize on _something_. Also ALSA does a similar thing
> to bind codecs and CPU interfaces together.

Absolutely, this is the interface and method that was discussed and
settled upon, and for DT folk to now start saying that they're not
fans of it is _far_ too late.  If they had concerns, they should have
been discussed during the submission of the first users of it, not
after the 4th or 5th user.

Sure, they may be having reservations about it, but then, I think,
it's up to them to come up with a better solution to this, and discuss
it over with the DRM people, remembering that the DRM people are very
adamant that they're not budging on the "not hotplugging bits" issue,
or if they do, it means _radically_ changing the DRM user API for
everything.

> > Also, it probably should have an SOC specific property to deal with SOC 
> > specific configuration or integration.
>
> Same as above really. Parts of the identification registers are
> different for each SoC integration, even if it's the same IP core,
> so we can just derive any needed driver behavior differences from
> that.

I agree.  There are some bugs in various cores (like the GC320) but
it's not clear whether that's a SoC specific issue or whether it's a
GPU core specific issue: all we know is that GC320 revision X suffers
from a certain bug, which we need to work around in userspace - and as
we pass all the GPU identifying information to userspace, adding such
stuff into DT, and then having to find some way to pass it through to
userspace would just add a whole new level of complexity that isn't
required.

It'd be a case of "okay, we know iMX6 has a GC320 with revision X,
so we better set DT flag Y to indicate that it has this bug" when we
already know in userspace that it's a GC320 revision X and userspace
needs to generate the command stream differently based on that.

So, it seems completely pointless to encode this information in DT.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 108901] amdgpu: corruption for R9 380X (Tonga XT)

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Fixed in my tree.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Russell King - ARM Linux]

On Fri, Dec 04, 2015 at 10:29:56AM -0600, Rob Herring wrote:
> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > +Vivante GPU core devices
> > +
> > +
> > +Required properties:
> > +- compatible: Should be "vivante,gc"
> 
> This should at least have the specific cores listed like gc-5000 or 
> whatever the numbering is. As is, I can't even tell if this a 2d or 3d 
> core.

Who cares whether it's a 2D or 3D core?  There are four options here:

2D
2D and 3D
3D
VG

All of these are determined by feature flags in the core - why should
DT have to specify this information when the hardware tells us, just
because we want something humanly visible?

> Also, it probably should have an SOC specific property to deal with SOC 
> specific configuration or integration.

Thus far, we're not aware of any SoC specific configuration of the
core.  Even if there was, I can't see it making much difference to
the DRM driver itself: the DRM driver mostly about command stream
queuing, GEM buffer management (both of which are independent of SoC
issues) and PM management, which is performed via runtime PM.

Where SoC specific integration would come in is the runtime PM, and
that goes as far as what clocks are present, which we already deal
with, power domains, which again we already deal with, and
interrupts - again, which are dealt with.

Given that this driver has been developed on two SoCs (Dove and iMX6)
which are radically different, I can't see any need for other SoC
specifics.

Did you have anything in mind?

Dove:
GC600 combined 2D and 3D GPU core, one clock, one interrupt, one PM
domain.

iMX6 S/DL/D/Q:
GC320 2D GPU core, GC880 or GC2000 3D GPU core, GC335 VG core, multiple
clocks, multiple interrupts, multiple PM domains.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 93236] Tonga garbled desktop since amdgpu/gfxv8: Cleanup of gfx_v8_0_tiling_mode_table_init()

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Alex Deucher  ---
Updated patch pushed.

-- 
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/20151204/52b5b7db/attachment-0001.html>

[PATCH v2 05/14] ALSA: pcm: Add DRM helper to set constraint for format

[Subhransu S. Prusty]

On Thu, Dec 03, 2015 at 04:57:14PM +0100, Takashi Iwai wrote:
> On Thu, 03 Dec 2015 22:08:53 +0100,
> Subhransu S. Prusty wrote:
> > 
> > Setting the constraint format based on ELD was missing bit in
> > the sound/core pcm drm. Added with this patch.
> 
> No, you can't define these here.  The format really depends on the
> hardware, while the rate and the channels are independent.

Probably then I will move this definition to driver.

> How do you know it's little-endian?  And why it must be S24_LE for
> 24bit, not S32_LE?

Regarding the little-endian, In the driver I think I should set the
constraint for both LE and BE. And the platform as it only supports LE alone
it will set the constraint accordingly and edianness will be taken care of.

Regarding the sample size, from short audio descriptor, the samples can be
one of 16/20/24 bit. I could use the format bits for 16 and 24 bits but
don't know which format bits macro is suitable for 20bits. So kept it as
S32_LE for 20bits. Should I fix the format bits for 20bits to use S24?

Regards,
Subhransu

> 
> 
> Takashi

-- 

[Bug 108901] New: amdgpu: corruption for R9 380X (Tonga XT)

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

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

Bug ID: 108901
   Summary: amdgpu: corruption for R9 380X (Tonga XT)
   Product: Drivers
   Version: 2.5
Kernel Version: amdgpu-powerplay
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: mustrumr97 at gmail.com
Regression: No

Looks like wrong tiling config. I bisected the issue to
3e199b1535a70d6169fd11ee309f8bc4c8ba5bb9. Reverting it after merging
amdgpu-powerplay fixes the problem for me.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 06/28] drm/bridge: Improve kerneldoc

[Archit Taneja]

On 12/04/2015 02:15 PM, Daniel Vetter wrote:
> Especially document the assumptions and semantics of the callbacks
> carefully. Just a warm-up excercise really.
>
> v2: Spelling fixes (Eric).
>
> v3: Consolidate more with existing docs:
>
> - Remove the overview section explaining the bridge funcs, that's
>now all in the drm_bridge_funcs kerneldoc in much more detail.
>
> - Use & to reference structs so that kerneldoc automatically inserts
>hyperlinks.

Reviewed-by: Archit Taneja 

>
> Cc: Eric Anholt 
> Cc: Archit Taneja 
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_bridge.c |  69 +++--
>   include/drm/drm_crtc.h   | 102 
> ---
>   2 files changed, 122 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 6b8f7211e543..26dd1cfb6078 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -31,14 +31,14 @@
>   /**
>* DOC: overview
>*
> - * drm_bridge represents a device that hangs on to an encoder. These are 
> handy
> - * when a regular drm_encoder entity isn't enough to represent the entire
> + * struct &drm_bridge represents a device that hangs on to an encoder. These 
> are
> + * handy when a regular &drm_encoder entity isn't enough to represent the 
> entire
>* encoder chain.
>*
> - * A bridge is always associated to a single drm_encoder at a time, but can 
> be
> + * A bridge is always associated to a single &drm_encoder at a time, but can 
> be
>* either connected to it directly, or through an intermediate bridge:
>*
> - * encoder ---> bridge B ---> bridge A
> + * encoder ---> bridge B ---> bridge A
>*
>* Here, the output of the encoder feeds to bridge B, and that furthers 
> feeds to
>* bridge A.
> @@ -46,11 +46,16 @@
>* The driver using the bridge is responsible to make the associations 
> between
>* the encoder and bridges. Once these links are made, the bridges will
>* participate along with encoder functions to perform 
> mode_set/enable/disable
> - * through the ops provided in drm_bridge_funcs.
> + * through the ops provided in &drm_bridge_funcs.
>*
>* drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
> - * crtcs, encoders or connectors. They just provide additional hooks to get 
> the
> - * desired output at the end of the encoder chain.
> + * crtcs, encoders or connectors and hence are not visible to userspace. They
> + * just provide additional hooks to get the desired output at the end of the
> + * encoder chain.
> + *
> + * Bridges can also be chained up using the next pointer in struct 
> &drm_bridge.
> + *
> + * Both legacy CRTC helpers and the new atomic modeset helpers support 
> bridges.
>*/
>
>   static DEFINE_MUTEX(bridge_lock);
> @@ -122,34 +127,12 @@ EXPORT_SYMBOL(drm_bridge_attach);
>   /**
>* DOC: bridge callbacks
>*
> - * The drm_bridge_funcs ops are populated by the bridge driver. The drm
> - * internals(atomic and crtc helpers) use the helpers defined in drm_bridge.c
> - * These helpers call a specific drm_bridge_funcs op for all the bridges
> + * The &drm_bridge_funcs ops are populated by the bridge driver. The drm
> + * internals (atomic and crtc helpers) use the helpers defined in 
> drm_bridge.c
> + * These helpers call a specific &drm_bridge_funcs op for all the bridges
>* during encoder configuration.
>*
> - * When creating a bridge driver, one can implement drm_bridge_funcs op with
> - * the help of these rough rules:
> - *
> - * pre_enable: this contains things needed to be done for the bridge before
> - * its clock and timings are enabled by its source. For a bridge, its source
> - * is generally the encoder or bridge just before it in the encoder chain.
> - *
> - * enable: this contains things needed to be done for the bridge once its
> - * source is enabled. In other words, enable is called once the source is
> - * ready with clock and timing needed by the bridge.
> - *
> - * disable: this contains things needed to be done for the bridge assuming
> - * that its source is still enabled, i.e. clock and timings are still on.
> - *
> - * post_disable: this contains things needed to be done for the bridge once
> - * its source is disabled, i.e. once clocks and timings are off.
> - *
> - * mode_fixup: this should fixup the given mode for the bridge. It is called
> - * after the encoder's mode fixup. mode_fixup can also reject a mode 
> completely
> - * if it's unsuitable for the hardware.
> - *
> - * mode_set: this sets up the mode for the bridge. It assumes that its source
> - * (an encoder or a bridge) has set the mode too.
> + * For detailed specification of the bridge callbacks see &drm_bridge_funcs.
>*/
>
>   /**
> @@ -159,7 +142,7 @@ EXPORT_SYMBOL(drm_bridge_attach);
>* @mode: desired mode to be set for the bridge
>* @adjusted_mode: updated mode that works for this brid

[PATCH 08/12] drm/etnaviv: add GPU MMU handling functionality

[Lucas Stach]

Hi Emil,

Am Freitag, den 04.12.2015, 14:59 + schrieb Emil Velikov:
> Hi Lucas,
> 
> On 4 December 2015 at 14:00, Lucas Stach  wrote:
> 
> > --- /dev/null
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
> 
> > +struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu)
> > +{
> > +   /* TODO */
> > +   return NULL;
> > +}
> 
> I thought you guys removed this since there is pretty much no
> implementation ? Note the duplicate function declaration in
> etnaviv_iommu.h and etnaviv_iommu_v2.h.
> 
I had nuked this from my tree, but since Russell had a stable tree with
this included I dropped the removal to keep the diff between the trees
down. If it bothers anyone I can remove this again, but I would still
hope that we can merge Christians implementation of IOMMUv2 pretty soon
after landing the initial set of patches.

Thanks for noting the duplicated declaration. I'll remove that.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH v2 12/14] ASoC: hdac_hdmi: Add infoframe support for dp audio

[Subhransu S. Prusty]

On Thu, Dec 03, 2015 at 05:13:16PM +, Daniel Stone wrote:
> Hi Subhransu,
> 
> On 3 December 2015 at 21:09, Subhransu S. Prusty
>  wrote:
> > +   if (conn_type == DRM_ELD_CONN_TYPE_HDMI) {
> > +   hdmi_audio_infoframe_init(&frame);
> > +
> > +   /* Default stereo for now */
> > +   frame.channels = channels;
> > +
> > +   ret = hdmi_audio_infoframe_pack(&frame, buffer, 
> > sizeof(buffer));
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   dip = (u8 *)&frame;
> > +
> > +   } else if (conn_type == DRM_ELD_CONN_TYPE_DP) {
> > +   memset(&dp_ai, 0, sizeof(dp_ai));
> > +   dp_ai.type  = 0x84;
> > +   dp_ai.len   = 0x1b;
> > +   dp_ai.ver   = 0x11 << 2;
> > +   dp_ai.CC02_CT47 = channels - 1;
> > +   dp_ai.CA= 0;
> > +
> > +   dip = (u8 *)&dip;
> 
> Surely this should be dip = (u8 *) &dp_ai, instead of pointing to itself?

Thanks for pointing. It's a mistake, will fix it.

Regards,
Subhansu
> 
> Cheers,
> Daniel
> 

-- 

[PATCH v2 11/14] drm/edid: Add API to help find connection type

[Subhransu S. Prusty]

On Thu, Dec 03, 2015 at 05:16:34PM +0100, Takashi Iwai wrote:
> On Thu, 03 Dec 2015 22:08:59 +0100,
> Subhransu S. Prusty wrote:
> > 
> > To fill the audio infoframe it is required to identify the
> > connection type as DP or HDMI. This patch adds an API which
> > parses ELD and returns the display type of connected.
> > 
> > Signed-off-by: Subhransu S. Prusty 
> > Signed-off-by: Vinod Koul 
> > Cc: David Airlie 
> > Cc: dri-devel at lists.freedesktop.org
> > Cc: Daniel Vetter 
> > ---
> >  include/drm/drm_edid.h | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 2af9769..072de90 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -403,6 +403,18 @@ static inline int drm_eld_size(const uint8_t *eld)
> > return DRM_ELD_HEADER_BLOCK_SIZE + eld[DRM_ELD_BASELINE_ELD_LEN] * 4;
> >  }
> >  
> > +/**
> > + * drm_eld_get_conn_type - Get device type hdmi/dp connected
> > + * @eld: pointer to an eld memory structure
> > + *
> > + * The caller need to use DRM_ELD_CONN_TYPE_HDMI or DRM_ELD_CONN_TYPE_DP to
> > + * identify the display type connected.
> 
> Constants should be marked with '%'.

Sure will add it. 

Regards,
Subhransu
> 
> 
> Takashi

-- 

[pull] radeon and amdgpu drm-fixes-4.4

[Alex Deucher]

Hi Dave,

A few more last minute fixes for 4.4 on top of my pull request from
earlier this week.  The big change here is a vblank regression fix due to
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks
were missed".  Beyond that, a hotplug fix and a few VM fixes.

The following changes since commit 07df04dfcfe51a45239d056d43cbc09702262c82:

  drm/amdgpu: fix race condition in amd_sched_entity_push_job (2015-12-02 
15:04:04 -0500)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.4

for you to fetch changes up to 8e36f9d33c134d5c6448ad65b423a9fd94e045cf:

  drm/amdgpu: Fixup hw vblank counter/ts for new drm_update_vblank_count() (v3) 
(2015-12-04 15:15:07 -0500)


Alex Deucher (1):
  drm/amdgpu: Fixup hw vblank counter/ts for new drm_update_vblank_count() 
(v3)

Christian König (4):
  drm/amdgpu: set snooped flags only on system addresses v2
  drm/amdgpu: take a BO reference in the display code
  drm/amdgpu: take a BO reference for the user fence
  drm/amdgpu: partially revert "drm/amdgpu: fix 
VM_CONTEXT*_PAGE_TABLE_END_ADDR" v2

Lyude (1):
  drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

Mario Kleiner (1):
  drm/radeon: Fixup hw vblank counter/ts for new drm_update_vblank_count() 
(v2)

jimqu (1):
  drm/amdgpu: add spin lock to protect freed list in vm (v2)

 drivers/gpu/drm/amd/amdgpu/amdgpu.h |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 108 
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  48 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   5 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  16 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |   5 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |   5 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |   5 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c   |   2 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c   |   2 +-
 drivers/gpu/drm/radeon/cik.c|   5 +-
 drivers/gpu/drm/radeon/evergreen.c  |   5 +-
 drivers/gpu/drm/radeon/r100.c   |  12 +++-
 drivers/gpu/drm/radeon/r600.c   |   2 +-
 drivers/gpu/drm/radeon/radeon.h |   2 +-
 drivers/gpu/drm/radeon/radeon_connectors.c  |  21 +-
 drivers/gpu/drm/radeon/radeon_display.c | 106 ---
 drivers/gpu/drm/radeon/radeon_irq_kms.c |   8 +--
 drivers/gpu/drm/radeon/radeon_kms.c |  50 -
 drivers/gpu/drm/radeon/radeon_mode.h|   5 ++
 drivers/gpu/drm/radeon/radeon_pm.c  |   4 +-
 drivers/gpu/drm/radeon/rs600.c  |   2 +-
 drivers/gpu/drm/radeon/rs690.c  |  10 +++
 drivers/gpu/drm/radeon/si.c |   5 +-
 26 files changed, 364 insertions(+), 84 deletions(-)

dumb BOs and prime

[Greg Hackmann]

On 12/04/2015 11:23 AM, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
>  wrote:
>> Hi Rob,
>>
>> I got the same problem today with sti drm/kms driver and dumb Bo.
>> The issue comes become hwcomposer because is the master and authenticated on
>> /dev/dri/cardX
>> Dumb allocation is done by gralloc which does a new open (so it is not
>> authenticated) on drm node the consequence is that we can't use prime
>> functions...
>> If you use render node you won't be able to call dumb functions.
>>
>> To get out of this I think I will implement additional helpers in gem_cma to
>> have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP
>> and call them instead of dumb so be able to use render node.
>> Of course it is only for drivers which already use gem_cma helpers (like
>> sti)
>
> That's only marginally better than per driver BO calls which is the
> whole thing I'm trying to avoid. There should be some way to pass the
> auth token to gralloc?
>
> Rob

Frankly, you probably want to approach this by allocating dma-bufs using 
something external to DRM (probably ion) and then have your hwcomposer 
import them into DRM when they're passed to the display.

Backing gralloc allocations with dumb BOs doesn't really fit the way 
gralloc is designed: like dma-buf, it's built around passing buffers 
between different hardware blocks, and some of those buffers may never 
even touch the display hardware.  You'll also run up against other 
(deliberate) limitations of dumb BOs like not being able to allocate YUV 
buffers.

Unfortunately this currently means adding some shim driver code to 
create the ion device.  (Device-Tree bindings for ion are on my long, 
long backlog of things to do.) It's not a lot of code, especially if all 
you need is a CMA heap, but it's still non-zero.

Note that supporting dumb BOs in your KMS driver is still useful, since 
the recovery console in AOSP has KMS support now.  In that case it's a 
single privileged process software-rendering everything, so it bypasses 
gralloc/hwcomposer and calls directly into libdrm.

[PATCH v2 04/14] ASoC: hdac_hdmi: Add hotplug notification and read eld

[Subhransu S. Prusty]

On Thu, Dec 03, 2015 at 04:51:37PM +0100, Takashi Iwai wrote:
> On Thu, 03 Dec 2015 22:08:52 +0100,
> Subhransu S. Prusty wrote:
> > 
> > This patch uses i915 component framework to register for hotplug
> > notification. And once it identifies valid pin sense and valid eld,
> > reads the eld into the corresponding pin map buffer. For now it
> > directly sends the verbs and reads the eld. Later this will use
> > the i915 framework to populate ELD buffer once available.
> > 
> > The eld reading APIs in legacy hda are required for ASoC skylake
> > hdmi driver as well. So keeping a copy here and will remove once
> > component ops for reading ELD are merged in hda core.
> > 
> > Also read the monitor present sense during resume and ignore the
> > ELD notify from graphics during PM as is done in legacy hda.
> > Reference commits:
> > 
> > git: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
> > 
> > commit 33d58f2bb446 ("ALSA: hda - Skip ELD notification during PM
> > process")
> 
> This one isn't merged yet, so the commit ID may be wrong.
> Maybe I'm going to merge this one at first to for-next branch,
> irrelevant from test/hdmi-jack branch.  So drop it from the
> description for now.

Ok.

> 
> > commit 8ae743e82f0b ("ALSA: hda - Skip ELD notification during
> > system suspend")
> 
> This one is already solid.
> 
> 
> Takashi

-- 

[PATCH v2 03/14] ASoC: hdac_hdmi - Use list to add pins and converters

[Subhransu S. Prusty]

On Thu, Dec 03, 2015 at 04:44:55PM +0100, Takashi Iwai wrote:
> On Thu, 03 Dec 2015 22:08:51 +0100,
> Subhransu S. Prusty wrote:
> >  static int hdac_hdmi_dev_remove(struct hdac_ext_device *edev)
> >  {
> > +   struct hdac_hdmi_priv *hdmi = edev->private_data;
> > +   struct hdac_hdmi_pin *pin;
> > +   struct hdac_hdmi_cvt *cvt;
> > +
> > snd_soc_unregister_codec(&edev->hdac.dev);
> >  
> > +   list_for_each_entry(cvt, &hdmi->cvt_list, head) {
> > +   list_del(&cvt->head);
> > +   kfree(cvt);
> > +   }
> > +
> > +   list_for_each_entry(pin, &hdmi->pin_list, head) {
> > +   list_del(&pin->head);
> > +   kfree(pin);
> > +   }
> 
> These must be list_for_each_entry_safe().

Sure. Will change it.

Regards,
Subhransu
> 
> 
> Takashi

-- 

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Ilia Mirkin]

On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
 wrote:
> Moreover, DRI3 is not yet available for Gallium, so if we're talking
> about Xorg, then functional DRI2 is a requirement, and that _needs_
> to have a single device for the rendering instances.  Xorg has no way
> to pass multiple render nodes to client over DRI2.

Just to correct... DRI3 has been available on gallium [at least in the
context of st/mesa] basically since DRI3 was introduced. Not sure what
issue you're fighting with, but it's definitely not a gallium
limitation... could be something related to platform devices.

It is also possible to use DRI_PRIME= to select which
device to use. Not sure whether that has been available since the
beginning or not.

That said e.g. st/vdpau still doesn't deal with DRI3 which is a bit
annoying. And your other points all still stand (buffer sharing =
pain, tiling = not figured out, etc).

  -ilia

Implementing Miracast?

[Martin Peres]

On 04/12/15 10:07, Daniel Vetter wrote:
>
> Hm for virtual devices like this I figured there's no point exporting the
> full kms api to userspace, but instead we'd just need a simple kms driver
> with just 1 crtc and 1 connector per drm_device.

Yes, we do not need anything more. But don't forget the requirement that 
we should be able to hotplug new gpus when new screens become available 
(there may be more than one). We thus need to create a node that when 
opened, would create a "screen" node that will be seen as a normal gpu 
by X and wayland compositors (cardX?). One userspace process will likely 
control all the miracast screens.

> Plus a special device
> node (v4l is probably inappropriate since it doesn't do damage) where the
> miracast userspace can receive events with just the following information:

Not sure it is a good idea as it would force compositors to learn about 
miracast, which is not necessary.

> - virtual screen size
> - fd to the underlying shmem node for the current fb. Or maybe a dma-buf
>(but then we'd need the dma-buf mmap stuff to land first).

Darn it, I was sure this had already landed. I guess it is OK as long as 
we expose a GEM interface that would allow us to import the dma-buf into 
a GEM buffer which we would then mmap through the usual API. Buffer 
allocation is not necessary though.

> - damage tracking
>
> If we want fancy, we could allow userspace to reply (through an ioctl)
> when it's done reading the previous image, which the kernel could then
> forward as vblank complete events.

Sounds good :)

>
> Connector configuration could be done by forcing the outputs (we'll send
> out uevents nowadays for that), so the only thing we need is some configfs
> to instantiate new copies of this.

Are you suggesting hotplugging connectors instead of GPUs? Not sure if 
compositors will like that :s

>
> At least for miracst (as opposed to full-blown hw drivers in userspace) I
> don't think we need to export everything.

We indeed do not need to export anything related to rendering!

> Cheers, Daniel
>

Thanks for your feedback Daniel!

Martin

[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"

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

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

--- Comment #15 from Mario Kleiner  ---
Thanks Dave for testing the v1 of the patch.

I think i'm done with these, v2 should be as good as it gets from my side.
-mario

-- 
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/20151204/e3dc8777/attachment.html>

[PATCH v2 5/7] drm: Only merge mode type bits between new probed modes

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

Currently most drivers request that any mode appearing on both the
old mode list and the new probed_modes list get their type bits ORed
together if the modes are deemed to otherwise match each other.

I don't know why anyone would want to merge in the mode type bits
from any mode left over from a previous probe. For instance, you
could never get rid of ther preferred bit if a matching non-preferred
mode is returned by the new probe. So let's not merge anything from
the stale old modes, and just replace them outright with matching new
modes.

If multiple matching modes are produced by the same probe, merging
the type bits between them would seem like a sensible thing to do.
For a bit of extra finesse if two modes are considered equal we can
pick the actual timings from the one marked as preferrred. And if
multiple preferred modes are produced by the same probe somehow, we
can just favor the first one added to the probed_modes list.

You may be asking yourself why we bother with the merging at all if
nothing from the old list survives in practice. The only answer I have
is "debug output". That is we want to print out a list of pruned modes,
which is why we still want to look for duplicates with the old modes.

There was a previous attempt to get rid of the mode type merging
entirely, but it caused some kind of regression on Daniels's G33
machine. Apparently the sdvo transcoder on said machine started to
die at around the same time and has since rotted away totally, so
it may have been a red herring. So we don't have to worry about
it anymore. The relevant commits are:
commit 3fbd6439e463 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9b08a ("Revert "drm: copy mode type in 
drm_mode_connector_list_update()"")

It was then decided in
commit b87577b7c768 ("drm: try harder to avoid regression when merging mode 
bits")
that just qxl virtio are excluded from the merging, while everyone
else does it. That is not changed, although now even qxl and virtio
will be subject to the previously mentioned logic to choose which
actual timings are picked for the new mode.

v2: Fix typos in commit message, and clarify the details on
the G33 regression from the previous attempt (Daniel)

Cc: Marc-André Lureau 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Adam Jackson 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_modes.c | 34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 2b94a5c661b0..8c803e3af1da 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1197,13 +1197,33 @@ void drm_mode_connector_list_update(struct 
drm_connector *connector,
continue;

found_it = true;
-   /* if equal delete the probed mode */
-   mode->status = pmode->status;
-   /* Merge type bits together */
-   if (merge_type_bits)
-   mode->type |= pmode->type;
-   else
-   mode->type = pmode->type;
+
+   /*
+* If the old matching mode is stale (ie. left over
+* from a previous probe) just replace it outright.
+* Otherwise just merge the type bits between all
+* equal probed modes.
+*
+* If two probed modes are considered equal, pick the
+* actual timings from the one that's marked as
+* preferred (in case the match isn't 100%). If
+* multiple or zero preferred modes are present, favor
+* the mode added to the probed_modes list first.
+*/
+   if (mode->status == MODE_STALE) {
+   drm_mode_copy(mode, pmode);
+   } else if ((mode->type & DRM_MODE_TYPE_PREFERRED) == 0 
&&
+  (pmode->type & DRM_MODE_TYPE_PREFERRED) != 
0) {
+   if (merge_type_bits)
+   pmode->type |= mode->type;
+   drm_mode_copy(mode, pmode);
+   } else {
+   if (merge_type_bits)
+   mode->type |= pmode->type;
+   else
+   mode->type = pmode->type;
+   }
+
list_del(&pmode->head);
drm_mode_destroy(connector->dev, pmode);
break;
-- 
2.4.10

[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"

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

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

--- Comment #14 from Mario Kleiner  ---
Created attachment 120351
  --> https://bugs.freedesktop.org/attachment.cgi?id=120351&action=edit
v2 of the amdgpu-kms fix: Slightly more efficient.

Like v2 of radeon-kms. Alex original port is R-b'ed by me.

-- 
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/20151204/c5193a70/attachment.html>

[Bug 93147] [regression bisected] Stuttering in games caused by commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many vblanks were missed"

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

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

--- Comment #13 from Mario Kleiner  ---
Created attachment 120350
  --> https://bugs.freedesktop.org/attachment.cgi?id=120350&action=edit
v2 of the radeon-kms fix: Slightly more efficient.

Same as original, but busy wait in flip_work_func replaced by hr-timer sleep
with event lock released, for more efficiency. Ditto for the following amdgpu
fix v2.

-- 
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/20151204/8a0b56e7/attachment-0001.html>

[PATCH 12/12] ARM: dts: imx6: add Vivante GPU nodes

[Lucas Stach]

This adds the device nodes for 2D, 3D and VG GPU cores.

Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 arch/arm/boot/dts/imx6dl.dtsi  |  5 +
 arch/arm/boot/dts/imx6q.dtsi   | 15 +++
 arch/arm/boot/dts/imx6qdl.dtsi | 22 ++
 3 files changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 4b0ec0703825..51c517a5cafd 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -104,6 +104,11 @@
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>;
};
+
+   gpu-subsystem {
+   compatible = "fsl,imx-gpu-subsystem";
+   cores = <&gpu_2d>, <&gpu_3d>;
+   };
 };

 &gpt {
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 399103b8e2c9..77d618b2870c 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -153,6 +153,16 @@
status = "disabled";
};

+   gpu_vg: gpu at 02204000 {
+   compatible = "vivante,gc";
+   reg = <0x02204000 0x4000>;
+   interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6QDL_CLK_OPENVG_AXI>,
+<&clks IMX6QDL_CLK_GPU2D_CORE>;
+   clock-names = "bus", "core";
+   power-domains = <&gpc 1>;
+   };
+
ipu2: ipu at 0280 {
#address-cells = <1>;
#size-cells = <0>;
@@ -225,6 +235,11 @@
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
};
+
+   gpu-subsystem {
+   compatible = "fsl,imx-gpu-subsystem";
+   cores = <&gpu_2d>, <&gpu_3d>, <&gpu_vg>;
+   };
 };

 &hdmi {
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 2b6cc8bf3c5c..018975b867e1 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -119,6 +119,28 @@
status = "disabled";
};

+
+   gpu_2d: gpu at 00134000 {
+   compatible = "vivante,gc";
+   reg = <0x00134000 0x4000>;
+   interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6QDL_CLK_GPU2D_AXI>,
+<&clks IMX6QDL_CLK_GPU2D_CORE>;
+   clock-names = "bus", "core";
+   power-domains = <&gpc 1>;
+   };
+
+   gpu_3d: gpu at 0013 {
+   compatible = "vivante,gc";
+   reg = <0x0013 0x4000>;
+   interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
+<&clks IMX6QDL_CLK_GPU3D_CORE>,
+<&clks IMX6QDL_CLK_GPU3D_SHADER>;
+   clock-names = "bus", "core", "shader";
+   power-domains = <&gpc 1>;
+   };
+
hdmi: hdmi at 012 {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.6.2

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Lucas Stach]

Signed-off-by: Lucas Stach 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b28828..1c69563c61ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3741,6 +3741,13 @@ S:   Maintained
 F: drivers/gpu/drm/sti
 F: Documentation/devicetree/bindings/display/st,stih4xx.txt

+DRM DRIVERS FOR VIVANTE GPU IP
+M: Lucas Stach 
+L: dri-devel at lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/etnaviv
+F: Documentation/devicetree/bindings/display/etnaviv
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov 
 L: linux-media at vger.kernel.org
-- 
2.6.2

[PATCH 10/12] drm/etnaviv: add master driver and hook up in Kconfig and Makefile

[Lucas Stach]

From: The etnaviv authors 

This adds the etnaviv DRM core driver and hooks it up in the Kconfig
and Makefile.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/etnaviv/Kconfig   |  20 +
 drivers/gpu/drm/etnaviv/Makefile  |  14 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c | 707 ++
 drivers/gpu/drm/etnaviv/etnaviv_drv.h | 161 
 6 files changed, 905 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/Kconfig
 create mode 100644 drivers/gpu/drm/etnaviv/Makefile
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_drv.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c4bf9a1cf4a6..b02ac62f5863 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig"
 source "drivers/gpu/drm/imx/Kconfig"

 source "drivers/gpu/drm/vc4/Kconfig"
+
+source "drivers/gpu/drm/etnaviv/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1e9ff4c3e3db..f858aa25fbb2 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -75,3 +75,4 @@ obj-y += i2c/
 obj-y  += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
+obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
new file mode 100644
index ..2cde7a5442fb
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -0,0 +1,20 @@
+
+config DRM_ETNAVIV
+   tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
+   depends on DRM
+   depends on ARCH_MXC || ARCH_DOVE
+   select SHMEM
+   select TMPFS
+   select IOMMU_API
+   select IOMMU_SUPPORT
+   select WANT_DEV_COREDUMP
+   help
+ DRM driver for Vivante GPUs.
+
+config DRM_ETNAVIV_REGISTER_LOGGING
+   bool "enable ETNAVIV register logging"
+   depends on DRM_ETNAVIV
+   help
+ Compile in support for logging register reads/writes in a format
+ that can be parsed by envytools demsm tool.  If enabled, register
+ logging can be switched on via etnaviv.reglog=y module param.
diff --git a/drivers/gpu/drm/etnaviv/Makefile b/drivers/gpu/drm/etnaviv/Makefile
new file mode 100644
index ..1086e9876f91
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/Makefile
@@ -0,0 +1,14 @@
+etnaviv-y := \
+   etnaviv_buffer.o \
+   etnaviv_cmd_parser.o \
+   etnaviv_drv.o \
+   etnaviv_dump.o \
+   etnaviv_gem_prime.o \
+   etnaviv_gem_submit.o \
+   etnaviv_gem.o \
+   etnaviv_gpu.o \
+   etnaviv_iommu_v2.o \
+   etnaviv_iommu.o \
+   etnaviv_mmu.o
+
+obj-$(CONFIG_DRM_ETNAVIV)  += etnaviv.o
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
new file mode 100644
index ..f9cb812750fc
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -0,0 +1,707 @@
+/*
+ * Copyright (C) 2015 Etnaviv Project
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+
+#include "etnaviv_drv.h"
+#include "etnaviv_gpu.h"
+#include "etnaviv_gem.h"
+#include "etnaviv_mmu.h"
+#include "etnaviv_gem.h"
+
+#ifdef CONFIG_DRM_ETNAVIV_REGISTER_LOGGING
+static bool reglog;
+MODULE_PARM_DESC(reglog, "Enable register read/write logging");
+module_param(reglog, bool, 0600);
+#else
+#define reglog 0
+#endif
+
+void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name,
+   const char *dbgname)
+{
+   struct resource *res;
+   void __iomem *ptr;
+
+   if (name)
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
+   else
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+   ptr = devm_ioremap_resource(&pdev->dev, res);
+   if (IS_ERR(ptr)) {
+   dev_err(&pdev->dev, "failed to ioremap %s: %ld\n", name,
+   PTR_ERR(ptr));
+   return ptr;
+   }
+
+   if (reglog)
+   dev_printk(KERN_DEBUG, &pdev->dev, "IO:region %s 0x%p %08zx\n",
+  dbgname, ptr, (size_t)resource_size(res));
+
+   return ptr;
+}
+
+void etnaviv_writel(u32 data, void __

[PATCH 09/12] drm/etnaviv: add GPU core dump functionality

[Lucas Stach]

From: The etnaviv authors 

This adds functionality to allow post-portem GPU analysis.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_dump.c | 227 +
 drivers/gpu/drm/etnaviv/etnaviv_dump.h |  54 
 2 files changed, 281 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_dump.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_dump.h

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c 
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
new file mode 100644
index ..bf8fa859e8be
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright (C) 2015 Etnaviv Project
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include "etnaviv_dump.h"
+#include "etnaviv_gem.h"
+#include "etnaviv_gpu.h"
+#include "etnaviv_mmu.h"
+#include "state.xml.h"
+#include "state_hi.xml.h"
+
+struct core_dump_iterator {
+   void *start;
+   struct etnaviv_dump_object_header *hdr;
+   void *data;
+};
+
+static const unsigned short etnaviv_dump_registers[] = {
+   VIVS_HI_AXI_STATUS,
+   VIVS_HI_CLOCK_CONTROL,
+   VIVS_HI_IDLE_STATE,
+   VIVS_HI_AXI_CONFIG,
+   VIVS_HI_INTR_ENBL,
+   VIVS_HI_CHIP_IDENTITY,
+   VIVS_HI_CHIP_FEATURE,
+   VIVS_HI_CHIP_MODEL,
+   VIVS_HI_CHIP_REV,
+   VIVS_HI_CHIP_DATE,
+   VIVS_HI_CHIP_TIME,
+   VIVS_HI_CHIP_MINOR_FEATURE_0,
+   VIVS_HI_CACHE_CONTROL,
+   VIVS_HI_AXI_CONTROL,
+   VIVS_PM_POWER_CONTROLS,
+   VIVS_PM_MODULE_CONTROLS,
+   VIVS_PM_MODULE_STATUS,
+   VIVS_PM_PULSE_EATER,
+   VIVS_MC_MMU_FE_PAGE_TABLE,
+   VIVS_MC_MMU_TX_PAGE_TABLE,
+   VIVS_MC_MMU_PE_PAGE_TABLE,
+   VIVS_MC_MMU_PEZ_PAGE_TABLE,
+   VIVS_MC_MMU_RA_PAGE_TABLE,
+   VIVS_MC_DEBUG_MEMORY,
+   VIVS_MC_MEMORY_BASE_ADDR_RA,
+   VIVS_MC_MEMORY_BASE_ADDR_FE,
+   VIVS_MC_MEMORY_BASE_ADDR_TX,
+   VIVS_MC_MEMORY_BASE_ADDR_PEZ,
+   VIVS_MC_MEMORY_BASE_ADDR_PE,
+   VIVS_MC_MEMORY_TIMING_CONTROL,
+   VIVS_MC_BUS_CONFIG,
+   VIVS_FE_DMA_STATUS,
+   VIVS_FE_DMA_DEBUG_STATE,
+   VIVS_FE_DMA_ADDRESS,
+   VIVS_FE_DMA_LOW,
+   VIVS_FE_DMA_HIGH,
+   VIVS_FE_AUTO_FLUSH,
+};
+
+static void etnaviv_core_dump_header(struct core_dump_iterator *iter,
+   u32 type, void *data_end)
+{
+   struct etnaviv_dump_object_header *hdr = iter->hdr;
+
+   hdr->magic = cpu_to_le32(ETDUMP_MAGIC);
+   hdr->type = cpu_to_le32(type);
+   hdr->file_offset = cpu_to_le32(iter->data - iter->start);
+   hdr->file_size = cpu_to_le32(data_end - iter->data);
+
+   iter->hdr++;
+   iter->data += hdr->file_size;
+}
+
+static void etnaviv_core_dump_registers(struct core_dump_iterator *iter,
+   struct etnaviv_gpu *gpu)
+{
+   struct etnaviv_dump_registers *reg = iter->data;
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(etnaviv_dump_registers); i++, reg++) {
+   reg->reg = etnaviv_dump_registers[i];
+   reg->value = gpu_read(gpu, etnaviv_dump_registers[i]);
+   }
+
+   etnaviv_core_dump_header(iter, ETDUMP_BUF_REG, reg);
+}
+
+static void etnaviv_core_dump_mmu(struct core_dump_iterator *iter,
+   struct etnaviv_gpu *gpu, size_t mmu_size)
+{
+   etnaviv_iommu_dump(gpu->mmu, iter->data);
+
+   etnaviv_core_dump_header(iter, ETDUMP_BUF_MMU, iter->data + mmu_size);
+}
+
+static void etnaviv_core_dump_mem(struct core_dump_iterator *iter, u32 type,
+   void *ptr, size_t size, u64 iova)
+{
+   memcpy(iter->data, ptr, size);
+
+   iter->hdr->iova = cpu_to_le64(iova);
+
+   etnaviv_core_dump_header(iter, type, iter->data + size);
+}
+
+void etnaviv_core_dump(struct etnaviv_gpu *gpu)
+{
+   struct core_dump_iterator iter;
+   struct etnaviv_vram_mapping *vram;
+   struct etnaviv_gem_object *obj;
+   struct etnaviv_cmdbuf *cmd;
+   unsigned int n_obj, n_bomap_pages;
+   size_t file_size, mmu_size;
+   __le64 *bomap, *bomap_start;
+
+   mmu_size = etnaviv_iommu_dump_size(gpu->mmu);
+
+   /* We always dump registers, mmu, ring and end marker */
+   n_obj = 4;
+   n_bomap_pages = 0;
+   file_size = ARRAY_SIZE(etnaviv_dump_registers) *
+   sizeof(struct etnaviv_dump_registers) +
+   mmu_size + gpu->buffer->size;
+
+   /

[PATCH 08/12] drm/etnaviv: add GPU MMU handling functionality

[Lucas Stach]

From: The etnaviv authors 

This adds the GPU MMU handling functionality, used to drive the MMUs
attached to each GPU core.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 240 +++
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h|  28 +++
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c |  33 
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h |  25 +++
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c  | 299 +
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h  |  71 +++
 6 files changed, 696 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu.h
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_mmu.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_mmu.h

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
new file mode 100644
index ..522cfd447892
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (C) 2014 Christian Gmeiner 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "etnaviv_gpu.h"
+#include "etnaviv_mmu.h"
+#include "etnaviv_iommu.h"
+#include "state_hi.xml.h"
+
+#define PT_SIZESZ_2M
+#define PT_ENTRIES (PT_SIZE / sizeof(u32))
+
+#define GPU_MEM_START  0x8000
+
+struct etnaviv_iommu_domain_pgtable {
+   u32 *pgtable;
+   dma_addr_t paddr;
+};
+
+struct etnaviv_iommu_domain {
+   struct iommu_domain domain;
+   struct device *dev;
+   void *bad_page_cpu;
+   dma_addr_t bad_page_dma;
+   struct etnaviv_iommu_domain_pgtable pgtable;
+   spinlock_t map_lock;
+};
+
+static struct etnaviv_iommu_domain *to_etnaviv_domain(struct iommu_domain 
*domain)
+{
+   return container_of(domain, struct etnaviv_iommu_domain, domain);
+}
+
+static int pgtable_alloc(struct etnaviv_iommu_domain_pgtable *pgtable,
+size_t size)
+{
+   pgtable->pgtable = dma_alloc_coherent(NULL, size, &pgtable->paddr, 
GFP_KERNEL);
+   if (!pgtable->pgtable)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static void pgtable_free(struct etnaviv_iommu_domain_pgtable *pgtable,
+size_t size)
+{
+   dma_free_coherent(NULL, size, pgtable->pgtable, pgtable->paddr);
+}
+
+static u32 pgtable_read(struct etnaviv_iommu_domain_pgtable *pgtable,
+  unsigned long iova)
+{
+   /* calcuate index into page table */
+   unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
+   phys_addr_t paddr;
+
+   paddr = pgtable->pgtable[index];
+
+   return paddr;
+}
+
+static void pgtable_write(struct etnaviv_iommu_domain_pgtable *pgtable,
+ unsigned long iova, phys_addr_t paddr)
+{
+   /* calcuate index into page table */
+   unsigned int index = (iova - GPU_MEM_START) / SZ_4K;
+
+   pgtable->pgtable[index] = paddr;
+}
+
+static int __etnaviv_iommu_init(struct etnaviv_iommu_domain *etnaviv_domain)
+{
+   u32 *p;
+   int ret, i;
+
+   etnaviv_domain->bad_page_cpu = dma_alloc_coherent(etnaviv_domain->dev,
+ SZ_4K,
+ &etnaviv_domain->bad_page_dma,
+ GFP_KERNEL);
+   if (!etnaviv_domain->bad_page_cpu)
+   return -ENOMEM;
+
+   p = etnaviv_domain->bad_page_cpu;
+   for (i = 0; i < SZ_4K / 4; i++)
+   *p++ = 0xdead55aa;
+
+   ret = pgtable_alloc(&etnaviv_domain->pgtable, PT_SIZE);
+   if (ret < 0) {
+   dma_free_coherent(etnaviv_domain->dev, SZ_4K,
+ etnaviv_domain->bad_page_cpu,
+ etnaviv_domain->bad_page_dma);
+   return ret;
+   }
+
+   for (i = 0; i < PT_ENTRIES; i++)
+   etnaviv_domain->pgtable.pgtable[i] =
+   etnaviv_domain->bad_page_dma;
+
+   spin_lock_init(&etnaviv_domain->map_lock);
+
+   return 0;
+}
+
+static void etnaviv_domain_free(struct iommu_domain *domain)
+{
+   struct e

[PATCH 07/12] drm/etnaviv: add GEM submit and cmdstream validation bits

[Lucas Stach]

From: The etnaviv authors 

This adds the GEM submit functionality and the needed commandstream
validation and GPU buffer handling bits to go with that.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 268 
 drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 209 +
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 438 +++
 3 files changed, 915 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_buffer.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
new file mode 100644
index ..332c55ebba6d
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -0,0 +1,268 @@
+/*
+ * Copyright (C) 2014 Etnaviv Project
+ * Author: Christian Gmeiner 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "etnaviv_gpu.h"
+#include "etnaviv_gem.h"
+#include "etnaviv_mmu.h"
+
+#include "common.xml.h"
+#include "state.xml.h"
+#include "cmdstream.xml.h"
+
+/*
+ * Command Buffer helper:
+ */
+
+
+static inline void OUT(struct etnaviv_cmdbuf *buffer, u32 data)
+{
+   u32 *vaddr = (u32 *)buffer->vaddr;
+
+   BUG_ON(buffer->user_size >= buffer->size);
+
+   vaddr[buffer->user_size / 4] = data;
+   buffer->user_size += 4;
+}
+
+static inline void CMD_LOAD_STATE(struct etnaviv_cmdbuf *buffer,
+   u32 reg, u32 value)
+{
+   u32 index = reg >> VIV_FE_LOAD_STATE_HEADER_OFFSET__SHR;
+
+   buffer->user_size = ALIGN(buffer->user_size, 8);
+
+   /* write a register via cmd stream */
+   OUT(buffer, VIV_FE_LOAD_STATE_HEADER_OP_LOAD_STATE |
+   VIV_FE_LOAD_STATE_HEADER_COUNT(1) |
+   VIV_FE_LOAD_STATE_HEADER_OFFSET(index));
+   OUT(buffer, value);
+}
+
+static inline void CMD_END(struct etnaviv_cmdbuf *buffer)
+{
+   buffer->user_size = ALIGN(buffer->user_size, 8);
+
+   OUT(buffer, VIV_FE_END_HEADER_OP_END);
+}
+
+static inline void CMD_WAIT(struct etnaviv_cmdbuf *buffer)
+{
+   buffer->user_size = ALIGN(buffer->user_size, 8);
+
+   OUT(buffer, VIV_FE_WAIT_HEADER_OP_WAIT | 200);
+}
+
+static inline void CMD_LINK(struct etnaviv_cmdbuf *buffer,
+   u16 prefetch, u32 address)
+{
+   buffer->user_size = ALIGN(buffer->user_size, 8);
+
+   OUT(buffer, VIV_FE_LINK_HEADER_OP_LINK |
+   VIV_FE_LINK_HEADER_PREFETCH(prefetch));
+   OUT(buffer, address);
+}
+
+static inline void CMD_STALL(struct etnaviv_cmdbuf *buffer,
+   u32 from, u32 to)
+{
+   buffer->user_size = ALIGN(buffer->user_size, 8);
+
+   OUT(buffer, VIV_FE_STALL_HEADER_OP_STALL);
+   OUT(buffer, VIV_FE_STALL_TOKEN_FROM(from) | VIV_FE_STALL_TOKEN_TO(to));
+}
+
+static void etnaviv_cmd_select_pipe(struct etnaviv_cmdbuf *buffer, u8 pipe)
+{
+   u32 flush;
+   u32 stall;
+
+   /*
+* This assumes that if we're switching to 2D, we're switching
+* away from 3D, and vice versa.  Hence, if we're switching to
+* the 2D core, we need to flush the 3D depth and color caches,
+* otherwise we need to flush the 2D pixel engine cache.
+*/
+   if (pipe == ETNA_PIPE_2D)
+   flush = VIVS_GL_FLUSH_CACHE_DEPTH | VIVS_GL_FLUSH_CACHE_COLOR;
+   else
+   flush = VIVS_GL_FLUSH_CACHE_PE2D;
+
+   stall = VIVS_GL_SEMAPHORE_TOKEN_FROM(SYNC_RECIPIENT_FE) |
+   VIVS_GL_SEMAPHORE_TOKEN_TO(SYNC_RECIPIENT_PE);
+
+   CMD_LOAD_STATE(buffer, VIVS_GL_FLUSH_CACHE, flush);
+   CMD_LOAD_STATE(buffer, VIVS_GL_SEMAPHORE_TOKEN, stall);
+
+   CMD_STALL(buffer, SYNC_RECIPIENT_FE, SYNC_RECIPIENT_PE);
+
+   CMD_LOAD_STATE(buffer, VIVS_GL_PIPE_SELECT,
+  VIVS_GL_PIPE_SELECT_PIPE(pipe));
+}
+
+static u32 gpu_va(struct etnaviv_gpu *gpu, struct etnaviv_cmdbuf *buf)
+{
+   return buf->paddr - gpu->memory_base;
+}
+
+static void etnaviv_buffer_dump(struct etnaviv_gpu *gpu,
+   struct etnaviv_cmdbuf *buf, u32 off, u32 len)
+{
+   u32 size = buf->size;
+   u32 *ptr = buf->vaddr + off;
+
+   dev_info(gpu->dev, "virt %p phys 0x%08x free 0x%08x\n",
+   ptr, gpu_va(gpu, buf) + off, size - len * 4 - off);
+
+   print_hex_dump(KERN_INFO, "cmd ", 

[PATCH 06/12] drm/etnaviv: add GEM core functionality

[Lucas Stach]

From: The etnaviv authors 

This adds the implementation for the GEM core functionality
for the etnaviv DRM driver.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem.c   | 897 
 drivers/gpu/drm/etnaviv/etnaviv_gem.h   | 117 
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 122 
 3 files changed, 1136 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_gem.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_gem.h
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
new file mode 100644
index ..8d6f859f8200
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -0,0 +1,897 @@
+/*
+ * Copyright (C) 2015 Etnaviv Project
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+
+#include "etnaviv_drv.h"
+#include "etnaviv_gem.h"
+#include "etnaviv_gpu.h"
+#include "etnaviv_mmu.h"
+
+static void etnaviv_gem_scatter_map(struct etnaviv_gem_object *etnaviv_obj)
+{
+   struct drm_device *dev = etnaviv_obj->base.dev;
+   struct sg_table *sgt = etnaviv_obj->sgt;
+
+   /*
+* For non-cached buffers, ensure the new pages are clean
+* because display controller, GPU, etc. are not coherent.
+*/
+   if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
+   dma_map_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+}
+
+static void etnaviv_gem_scatterlist_unmap(struct etnaviv_gem_object 
*etnaviv_obj)
+{
+   struct drm_device *dev = etnaviv_obj->base.dev;
+   struct sg_table *sgt = etnaviv_obj->sgt;
+
+   /*
+* For non-cached buffers, ensure the new pages are clean
+* because display controller, GPU, etc. are not coherent:
+*
+* WARNING: The DMA API does not support concurrent CPU
+* and device access to the memory area.  With BIDIRECTIONAL,
+* we will clean the cache lines which overlap the region,
+* and invalidate all cache lines (partially) contained in
+* the region.
+*
+* If you have dirty data in the overlapping cache lines,
+* that will corrupt the GPU-written data.  If you have
+* written into the remainder of the region, this can
+* discard those writes.
+*/
+   if (etnaviv_obj->flags & ETNA_BO_CACHE_MASK)
+   dma_unmap_sg(dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL);
+}
+
+/* called with etnaviv_obj->lock held */
+static int etnaviv_gem_shmem_get_pages(struct etnaviv_gem_object *etnaviv_obj)
+{
+   struct drm_device *dev = etnaviv_obj->base.dev;
+   struct page **p = drm_gem_get_pages(&etnaviv_obj->base);
+
+   if (IS_ERR(p)) {
+   dev_err(dev->dev, "could not get pages: %ld\n", PTR_ERR(p));
+   return PTR_ERR(p);
+   }
+
+   etnaviv_obj->pages = p;
+
+   return 0;
+}
+
+static void put_pages(struct etnaviv_gem_object *etnaviv_obj)
+{
+   if (etnaviv_obj->sgt) {
+   etnaviv_gem_scatterlist_unmap(etnaviv_obj);
+   sg_free_table(etnaviv_obj->sgt);
+   kfree(etnaviv_obj->sgt);
+   etnaviv_obj->sgt = NULL;
+   }
+   if (etnaviv_obj->pages) {
+   drm_gem_put_pages(&etnaviv_obj->base, etnaviv_obj->pages,
+ true, false);
+
+   etnaviv_obj->pages = NULL;
+   }
+}
+
+struct page **etnaviv_gem_get_pages(struct etnaviv_gem_object *etnaviv_obj)
+{
+   int ret;
+
+   lockdep_assert_held(&etnaviv_obj->lock);
+
+   if (!etnaviv_obj->pages) {
+   ret = etnaviv_obj->ops->get_pages(etnaviv_obj);
+   if (ret < 0)
+   return ERR_PTR(ret);
+   }
+
+   if (!etnaviv_obj->sgt) {
+   struct drm_device *dev = etnaviv_obj->base.dev;
+   int npages = etnaviv_obj->base.size >> PAGE_SHIFT;
+   struct sg_table *sgt;
+
+   sgt = drm_prime_pages_to_sg(etnaviv_obj->pages, npages);
+   if (IS_ERR(sgt)) {
+   dev_err(dev->dev, "failed to allocate sgt: %ld\n",
+   PTR_ERR(sgt));
+   return ERR_CAST(sgt);
+   }
+
+   etnaviv_obj->sgt = sgt;
+
+   etnaviv_ge

[PATCH 05/12] drm/etnaviv: add GPU core driver

[Lucas Stach]

From: The etnaviv authors 

This adds the GPU core driver part of the etnaviv DRM driver.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 1644 +
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  209 +
 2 files changed, 1853 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_gpu.c
 create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_gpu.h

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
new file mode 100644
index ..d39093dc37e6
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -0,0 +1,1644 @@
+/*
+ * Copyright (C) 2015 Etnaviv Project
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "etnaviv_dump.h"
+#include "etnaviv_gpu.h"
+#include "etnaviv_gem.h"
+#include "etnaviv_mmu.h"
+#include "etnaviv_iommu.h"
+#include "etnaviv_iommu_v2.h"
+#include "common.xml.h"
+#include "state.xml.h"
+#include "state_hi.xml.h"
+#include "cmdstream.xml.h"
+
+static const struct platform_device_id gpu_ids[] = {
+   { .name = "etnaviv-gpu,2d" },
+   { },
+};
+
+static bool etnaviv_dump_core = true;
+module_param_named(dump_core, etnaviv_dump_core, bool, 0600);
+
+/*
+ * Driver functions:
+ */
+
+int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32 param, u64 *value)
+{
+   switch (param) {
+   case ETNAVIV_PARAM_GPU_MODEL:
+   *value = gpu->identity.model;
+   break;
+
+   case ETNAVIV_PARAM_GPU_REVISION:
+   *value = gpu->identity.revision;
+   break;
+
+   case ETNAVIV_PARAM_GPU_FEATURES_0:
+   *value = gpu->identity.features;
+   break;
+
+   case ETNAVIV_PARAM_GPU_FEATURES_1:
+   *value = gpu->identity.minor_features0;
+   break;
+
+   case ETNAVIV_PARAM_GPU_FEATURES_2:
+   *value = gpu->identity.minor_features1;
+   break;
+
+   case ETNAVIV_PARAM_GPU_FEATURES_3:
+   *value = gpu->identity.minor_features2;
+   break;
+
+   case ETNAVIV_PARAM_GPU_FEATURES_4:
+   *value = gpu->identity.minor_features3;
+   break;
+
+   case ETNAVIV_PARAM_GPU_STREAM_COUNT:
+   *value = gpu->identity.stream_count;
+   break;
+
+   case ETNAVIV_PARAM_GPU_REGISTER_MAX:
+   *value = gpu->identity.register_max;
+   break;
+
+   case ETNAVIV_PARAM_GPU_THREAD_COUNT:
+   *value = gpu->identity.thread_count;
+   break;
+
+   case ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE:
+   *value = gpu->identity.vertex_cache_size;
+   break;
+
+   case ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT:
+   *value = gpu->identity.shader_core_count;
+   break;
+
+   case ETNAVIV_PARAM_GPU_PIXEL_PIPES:
+   *value = gpu->identity.pixel_pipes;
+   break;
+
+   case ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE:
+   *value = gpu->identity.vertex_output_buffer_size;
+   break;
+
+   case ETNAVIV_PARAM_GPU_BUFFER_SIZE:
+   *value = gpu->identity.buffer_size;
+   break;
+
+   case ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT:
+   *value = gpu->identity.instruction_count;
+   break;
+
+   case ETNAVIV_PARAM_GPU_NUM_CONSTANTS:
+   *value = gpu->identity.num_constants;
+   break;
+
+   default:
+   DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
+{
+   if (gpu->identity.minor_features0 &
+   chipMinorFeatures0_MORE_MINOR_FEATURES) {
+   u32 specs[2];
+
+   specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
+   specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
+
+   gpu->identity.stream_count =
+   (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
+   >> VIVS_HI_CHIP_SPECS_STREAM_COUNT__SHIFT;
+   gpu->identity.register_max =
+   (specs[0] & VIVS_HI_CHIP_SPECS_REGISTER_MAX__MASK)
+   >> VIVS_HI_CHIP_SPECS_REGISTER_MAX__SHIFT;
+

[PATCH 04/12] drm/etnaviv: add generated hardware description headers

[Lucas Stach]

From: The etnaviv authors 

This adds all the generated hardware description headers for the
etnaviv DRM driver.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/cmdstream.xml.h | 218 +
 drivers/gpu/drm/etnaviv/common.xml.h| 249 +++
 drivers/gpu/drm/etnaviv/state.xml.h | 351 +++
 drivers/gpu/drm/etnaviv/state_hi.xml.h  | 407 
 4 files changed, 1225 insertions(+)
 create mode 100644 drivers/gpu/drm/etnaviv/cmdstream.xml.h
 create mode 100644 drivers/gpu/drm/etnaviv/common.xml.h
 create mode 100644 drivers/gpu/drm/etnaviv/state.xml.h
 create mode 100644 drivers/gpu/drm/etnaviv/state_hi.xml.h

diff --git a/drivers/gpu/drm/etnaviv/cmdstream.xml.h 
b/drivers/gpu/drm/etnaviv/cmdstream.xml.h
new file mode 100644
index ..8c44ba9a694e
--- /dev/null
+++ b/drivers/gpu/drm/etnaviv/cmdstream.xml.h
@@ -0,0 +1,218 @@
+#ifndef CMDSTREAM_XML
+#define CMDSTREAM_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://0x04.net/cgit/index.cgi/rules-ng-ng
+git clone git://0x04.net/rules-ng-ng
+
+The rules-ng-ng source files this header was generated from are:
+- cmdstream.xml (  12589 bytes, from 2014-02-17 14:57:56)
+- common.xml(  18437 bytes, from 2015-03-25 11:27:41)
+
+Copyright (C) 2014
+*/
+
+
+#define FE_OPCODE_LOAD_STATE   0x0001
+#define FE_OPCODE_END  0x0002
+#define FE_OPCODE_NOP  0x0003
+#define FE_OPCODE_DRAW_2D  0x0004
+#define FE_OPCODE_DRAW_PRIMITIVES  0x0005
+#define FE_OPCODE_DRAW_INDEXED_PRIMITIVES  0x0006
+#define FE_OPCODE_WAIT 0x0007
+#define FE_OPCODE_LINK 0x0008
+#define FE_OPCODE_STALL
0x0009
+#define FE_OPCODE_CALL 0x000a
+#define FE_OPCODE_RETURN   0x000b
+#define FE_OPCODE_CHIP_SELECT  0x000d
+#define PRIMITIVE_TYPE_POINTS  0x0001
+#define PRIMITIVE_TYPE_LINES   0x0002
+#define PRIMITIVE_TYPE_LINE_STRIP  0x0003
+#define PRIMITIVE_TYPE_TRIANGLES   0x0004
+#define PRIMITIVE_TYPE_TRIANGLE_STRIP  0x0005
+#define PRIMITIVE_TYPE_TRIANGLE_FAN0x0006
+#define PRIMITIVE_TYPE_LINE_LOOP   0x0007
+#define PRIMITIVE_TYPE_QUADS   0x0008
+#define VIV_FE_LOAD_STATE  0x
+
+#define VIV_FE_LOAD_STATE_HEADER   0x
+#define VIV_FE_LOAD_STATE_HEADER_OP__MASK  0xf800
+#define VIV_FE_LOAD_STATE_HEADER_OP__SHIFT 27
+#define VIV_FE_LOAD_STATE_HEADER_OP_LOAD_STATE 0x0800
+#define VIV_FE_LOAD_STATE_HEADER_FIXP  0x0400
+#define VIV_FE_LOAD_STATE_HEADER_COUNT__MASK   0x03ff
+#define VIV_FE_LOAD_STATE_HEADER_COUNT__SHIFT  16
+#define VIV_FE_LOAD_STATE_HEADER_COUNT(x)  (((x) << 
VIV_FE_LOAD_STATE_HEADER_COUNT__SHIFT) & VIV_FE_LOAD_STATE_HEADER_COUNT__MASK)
+#define VIV_FE_LOAD_STATE_HEADER_OFFSET__MASK  0x
+#define VIV_FE_LOAD_STATE_HEADER_OFFSET__SHIFT 0
+#define VIV_FE_LOAD_STATE_HEADER_OFFSET(x) (((x) << 
VIV_FE_LOAD_STATE_HEADER_OFFSET__SHIFT) & VIV_FE_LOAD_STATE_HEADER_OFFSET__MASK)
+#define VIV_FE_LOAD_STATE_HEADER_OFFSET__SHR   2
+
+#define VIV_FE_END 0x
+
+#define VIV_FE_END_HEADER  0x
+#define VIV_FE_END_HEADER_EVENT_ID__MASK   0x001f
+#define VIV_FE_END_HEADER_EVENT_ID__SHIFT  0
+#define VIV_FE_END_HEADER_EVENT_ID(x)  (((x) << 
VIV_FE_END_HEADER_EVENT_ID__SHIFT) & VIV_FE_END_HEADER_EVENT_ID__MASK)
+#define VIV_FE_END_HEADER_EVENT_ENABLE 0x0100
+#define VIV_FE_END_HEADER_OP__MASK 0xf800
+#define VIV_FE_END_HEADER_OP__SHIFT27
+#define VIV_FE_END_HEADER_OP_END   0x1000
+
+#define VIV_FE_NOP 0x
+
+#define VIV_FE_NOP_HEADER  0x
+#define VIV_FE_NOP_HEADER_OP__

[PATCH 03/12] drm/etnaviv: add etnaviv UAPI header

[Lucas Stach]

From: The etnaviv authors 

This adds the header defining the user/kernel API for the
etnaviv DRM driver.

Signed-off-by: Christian Gmeiner 
Signed-off-by: Russell King 
Signed-off-by: Lucas Stach 
---
 include/uapi/drm/etnaviv_drm.h | 221 +
 1 file changed, 221 insertions(+)
 create mode 100644 include/uapi/drm/etnaviv_drm.h

diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
new file mode 100644
index ..0cce95efcd86
--- /dev/null
+++ b/include/uapi/drm/etnaviv_drm.h
@@ -0,0 +1,221 @@
+/*
+ * Copyright (C) 2015 Etnaviv Project
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#ifndef __ETNAVIV_DRM_H__
+#define __ETNAVIV_DRM_H__
+
+#include 
+
+/* Please note that modifications to all structs defined here are
+ * subject to backwards-compatibility constraints:
+ *  1) Do not use pointers, use __u64 instead for 32 bit / 64 bit
+ * user/kernel compatibility
+ *  2) Keep fields aligned to their size
+ *  3) Because of how drm_ioctl() works, we can add new fields at
+ * the end of an ioctl if some care is taken: drm_ioctl() will
+ * zero out the new fields at the tail of the ioctl, so a zero
+ * value should have a backwards compatible meaning.  And for
+ * output params, userspace won't see the newly added output
+ * fields.. so that has to be somehow ok.
+ */
+
+/* timeouts are specified in clock-monotonic absolute times (to simplify
+ * restarting interrupted ioctls).  The following struct is logically the
+ * same as 'struct timespec' but 32/64b ABI safe.
+ */
+struct drm_etnaviv_timespec {
+   __s64 tv_sec;  /* seconds */
+   __s64 tv_nsec; /* nanoseconds */
+};
+
+#define ETNAVIV_PARAM_GPU_MODEL 0x01
+#define ETNAVIV_PARAM_GPU_REVISION  0x02
+#define ETNAVIV_PARAM_GPU_FEATURES_00x03
+#define ETNAVIV_PARAM_GPU_FEATURES_10x04
+#define ETNAVIV_PARAM_GPU_FEATURES_20x05
+#define ETNAVIV_PARAM_GPU_FEATURES_30x06
+#define ETNAVIV_PARAM_GPU_FEATURES_40x07
+
+#define ETNAVIV_PARAM_GPU_STREAM_COUNT  0x10
+#define ETNAVIV_PARAM_GPU_REGISTER_MAX  0x11
+#define ETNAVIV_PARAM_GPU_THREAD_COUNT  0x12
+#define ETNAVIV_PARAM_GPU_VERTEX_CACHE_SIZE 0x13
+#define ETNAVIV_PARAM_GPU_SHADER_CORE_COUNT 0x14
+#define ETNAVIV_PARAM_GPU_PIXEL_PIPES   0x15
+#define ETNAVIV_PARAM_GPU_VERTEX_OUTPUT_BUFFER_SIZE 0x16
+#define ETNAVIV_PARAM_GPU_BUFFER_SIZE   0x17
+#define ETNAVIV_PARAM_GPU_INSTRUCTION_COUNT 0x18
+#define ETNAVIV_PARAM_GPU_NUM_CONSTANTS 0x19
+
+#define ETNA_MAX_PIPES 4
+
+struct drm_etnaviv_param {
+   __u32 pipe;   /* in */
+   __u32 param;  /* in, ETNAVIV_PARAM_x */
+   __u64 value;  /* out (get_param) or in (set_param) */
+};
+
+/*
+ * GEM buffers:
+ */
+
+#define ETNA_BO_CACHE_MASK   0x000f
+/* cache modes */
+#define ETNA_BO_CACHED   0x0001
+#define ETNA_BO_WC   0x0002
+#define ETNA_BO_UNCACHED 0x0004
+/* map flags */
+#define ETNA_BO_FORCE_MMU0x0010
+
+struct drm_etnaviv_gem_new {
+   __u64 size;   /* in */
+   __u32 flags;  /* in, mask of ETNA_BO_x */
+   __u32 handle; /* out */
+};
+
+struct drm_etnaviv_gem_info {
+   __u32 handle; /* in */
+   __u32 pad;
+   __u64 offset; /* out, offset to pass to mmap() */
+};
+
+#define ETNA_PREP_READ0x01
+#define ETNA_PREP_WRITE   0x02
+#define ETNA_PREP_NOSYNC  0x04
+
+struct drm_etnaviv_gem_cpu_prep {
+   __u32 handle; /* in */
+   __u32 op; /* in, mask of ETNA_PREP_x */
+   struct drm_etnaviv_timespec timeout;   /* in */
+};
+
+struct drm_etnaviv_gem_cpu_fini {
+   __u32 handle; /* in */
+   __u32 flags;  /* in, placeholder for now, no defined values */
+};
+
+/*
+ * Cmdstream Submission:
+ */
+
+/* The value written into the cmdstream is logically:
+ * relocbuf->gpuaddr + reloc_offset
+ *
+ * NOTE that reloc's must be sorted by order of increasing submit_offset,
+ * otherwise EINVAL.
+ */
+struct drm_etnaviv_gem_submit_reloc {
+   __u32 submit_offset;  /* in, offset from submit_bo */
+   __u32 reloc_idx;  /* in, index of reloc_bo buffer */
+   __u64 reloc_offset;   /* in, of

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Lucas Stach]

Etnaviv follows the same priciple as imx-drm to have a virtual
master device node to bind all the individual GPU cores together
into one DRM device.

Signed-off-by: Lucas Stach 
---
 .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt

diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
new file mode 100644
index ..19fde29dc1d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
@@ -0,0 +1,46 @@
+Etnaviv DRM master device
+
+
+The Etnaviv DRM master device is a virtual device needed to list all
+Vivante GPU cores that comprise the GPU subsystem.
+
+Required properties:
+- compatible: Should be one of
+"fsl,imx-gpu-subsystem"
+"marvell,dove-gpu-subsystem"
+- cores: Should contain a list of phandles pointing to Vivante GPU devices
+
+example:
+
+gpu-subsystem {
+   compatible = "fsl,imx-gpu-subsystem";
+   cores = <&gpu_2d>, <&gpu_3d>;
+};
+
+
+Vivante GPU core devices
+
+
+Required properties:
+- compatible: Should be "vivante,gc"
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain the cores interrupt line
+- clocks: should contain one clock for entry in clock-names
+  see Documentation/devicetree/bindings/clock/clock-bindings.txt
+- clock-names:
+   - "bus":AXI/register clock
+   - "core":   GPU core clock
+   - "shader": Shader clock (only required if GPU has feature PIPE_3D)
+
+example:
+
+gpu_3d: gpu at 0013 {
+   compatible = "vivante,gc";
+   reg = <0x0013 0x4000>;
+   interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
+<&clks IMX6QDL_CLK_GPU3D_CORE>,
+<&clks IMX6QDL_CLK_GPU3D_SHADER>;
+   clock-names = "bus", "core", "shader";
+};
-- 
2.6.2

[PATCH 01/12] devicetree: add vendor prefix for Vivante Corporation

[Lucas Stach]

From: Philipp Zabel 

Trivial patch to add Vivante Corporation to the list of
devicetree vendor prefixes.

Signed-off-by: Philipp Zabel 
Signed-off-by: Lucas Stach 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 55df1d444e9f..c2767a772650 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -238,6 +238,7 @@ v3  V3 Semiconductor
 variscite  Variscite Ltd.
 viaVIA Technologies, Inc.
 virtio Virtual I/O Device Specification, developed by the OASIS consortium
+vivanteVivante Corporation
 voipac Voipac Technologies s.r.o.
 wexler Wexler
 winbond Winbond Electronics corp.
-- 
2.6.2

[PATCH 08/12] drm/etnaviv: add GPU MMU handling functionality

[Emil Velikov]

Hi Lucas,

On 4 December 2015 at 14:00, Lucas Stach  wrote:

> --- /dev/null
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c

> +struct iommu_domain *etnaviv_iommu_v2_domain_alloc(struct etnaviv_gpu *gpu)
> +{
> +   /* TODO */
> +   return NULL;
> +}

I thought you guys removed this since there is pretty much no
implementation ? Note the duplicate function declaration in
etnaviv_iommu.h and etnaviv_iommu_v2.h.

-Emil

[PATCH 00/12] etnaviv DRM driver

[Lucas Stach]

Hi all,

this is the latest round of etnaviv DRM driver patches. Since RFCv2
we made some substantial changes and improvements. I'm confident
that the driver is in a state where it can go in now, so I removed
the RFC tag.

Most notable issues fixed:
- better input validation for all the ioctls in place
- basic command stream parsing and rejection of sensitive state loads
  has been implemented by Russell
- cross GPU synchronization fixed by Russell, so the GPUs cores don't
  trip over their feet when using 2D GPU for X.Xorg accel, while
  doing OpenGL rendering on the 3D core
- removed usage of deprecated DRM features, like driver load and
  unload callbacks, DRM_UNLOCKED
- reworked locking design to drop DRM struct_mutex usage in driver,
  switch to more fine grained locking, allowing for a lot more
  concurrency
- moved driver out of initial staging directory into proper
  DRM directory

As the original patchstack is now over 190 patches, some of which
totally rework some aspects of the driver, we've opted to not submit
it this way. Instead all the driver patches are squashed and reorganized
to add individual, logical groups of files. This should make review a
lot easier. As the driver is a collaborative effort of Christian Gmeiner,
Russell King and myself all of those patches have a fictive author, but
our signoff. Only the last commit of those wires the driver up in Kconfig
and Makefiles, so there should be no intermediate breakage.

First 2 patches need an Ack from the DT maintainers. The last patch adds
the necessary DT integration for i.MX6 and should either get an Ack from
Shawn to merge along with the DRM changes, or he could pick it up as an
individual patch, whatever suits better.

After everyone is happy with the driver and if that's preferred I can
also provide a proper pull request.

Happy reviewing!

Lucas

Lucas Stach (3):
  drm/etnaviv: add devicetree bindings
  MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver
  ARM: dts: imx6: add Vivante GPU nodes

Philipp Zabel (1):
  devicetree: add vendor prefix for Vivante Corporation

The etnaviv authors (8):
  drm/etnaviv: add etnaviv UAPI header
  drm/etnaviv: add generated hardware description headers
  drm/etnaviv: add GPU core driver
  drm/etnaviv: add GEM core functionality
  drm/etnaviv: add GEM submit and cmdstream validation bits
  drm/etnaviv: add GPU MMU handling functionality
  drm/etnaviv: add GPU core dump functionality
  drm/etnaviv: add master driver and hook up in Kconfig and Makefile

 .../bindings/display/etnaviv/etnaviv-drm.txt   |   46 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 MAINTAINERS|7 +
 arch/arm/boot/dts/imx6dl.dtsi  |5 +
 arch/arm/boot/dts/imx6q.dtsi   |   15 +
 arch/arm/boot/dts/imx6qdl.dtsi |   22 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/etnaviv/Kconfig|   20 +
 drivers/gpu/drm/etnaviv/Makefile   |   14 +
 drivers/gpu/drm/etnaviv/cmdstream.xml.h|  218 +++
 drivers/gpu/drm/etnaviv/common.xml.h   |  249 +++
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c   |  268 
 drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c   |  209 +++
 drivers/gpu/drm/etnaviv/etnaviv_drv.c  |  707 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.h  |  161 ++
 drivers/gpu/drm/etnaviv/etnaviv_dump.c |  227 +++
 drivers/gpu/drm/etnaviv/etnaviv_dump.h |   54 +
 drivers/gpu/drm/etnaviv/etnaviv_gem.c  |  897 +++
 drivers/gpu/drm/etnaviv/etnaviv_gem.h  |  117 ++
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c|  122 ++
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c   |  438 ++
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 1644 
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h  |  209 +++
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c|  240 +++
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h|   28 +
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c |   33 +
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.h |   25 +
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c  |  299 
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h  |   71 +
 drivers/gpu/drm/etnaviv/state.xml.h|  351 +
 drivers/gpu/drm/etnaviv/state_hi.xml.h |  407 +
 include/uapi/drm/etnaviv_drm.h |  221 +++
 33 files changed, 7328 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
 create mode 100644 drivers/gpu/drm/etnaviv/Kconfig
 create mode 100644 drivers/gpu/drm/etnaviv/Makefile
 create mode 100644 drivers/gpu/drm/etnaviv/cmdstream.xml.h
 create mode 100644 drivers/gpu/drm/etnaviv/common.xml.h
 create mode 100644 drivers/gpu/drm/etnav

[PATCH] nouveau/nvkm/subdev/clk/gk20a.c: fix wrong do_div() usage

[Nicolas Pitre]

On Fri, 4 Dec 2015, Thierry Reding wrote:

> On Tue, Nov 03, 2015 at 05:01:46PM -0500, Nicolas Pitre wrote:
> > do_div() must only be used with a u64 dividend.
> > 
> > Signed-off-by: Nicolas Pitre 
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c 
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > index 254094ab7f..5da2aa8cc3 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c
> > @@ -141,9 +141,8 @@ gk20a_pllg_calc_rate(struct gk20a_clk *clk)
> >  
> > rate = clk->parent_rate * clk->n;
> > divider = clk->m * pl_to_div[clk->pl];
> > -   do_div(rate, divider);
> >  
> > -   return rate / 2;
> > +   return rate / divider / 2;
> >  }
> >  
> >  static int
> 
> This causes build breakage on 32-bit ARM.

Funny, because the above _fixes_ build warnings on 32-bit ARM for me.

> I'm also confused by the commit message because the code that I'm 
> looking at has u64 rate and u32 divider,

If I look at drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c 
in v4.4-rc3 between line 137 and line 147, I see this:

gk20a_pllg_calc_rate(struct gk20a_clk *clk)
{
u32 rate;
u32 divider;

rate = clk->parent_rate * clk->n;
divider = clk->m * pl_to_div[clk->pl];
do_div(rate, divider);

return rate / 2;
}

So clearly both rate and divider are u32 variables and do_div() should 
not be used.

Here's the warning:

drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c: In function 
'gk20a_pllg_calc_rate':
include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer 
types lacks a cast
  (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gk20a.c:144:2: note: in expansion of 
macro 'do_div'
  do_div(rate, divider);
  ^

The corresponding line number in vanilla v4.4-rc3 for 
include/asm-generic/div64.h is line 43.


Nicolas

[PATCH 3/9] drm/vc4: Add create and map BO ioctls.

[Emil Velikov]

Hi Eric,

A couple of suggestions/requests on the UAPI header side

On 1 December 2015 at 20:35, Eric Anholt  wrote:

> --- /dev/null
> +++ b/include/uapi/drm/vc4_drm.h

> +#include 
> +
Can we make this a "drm.h" ?


> +struct drm_vc4_create_bo {
> +   uint32_t size;
> +   uint32_t flags;
> +   /** Returned GEM handle for the BO. */
> +   uint32_t handle;
> +   uint32_t pad;
... and not use the stdint.h types but __{s,u}* through the file.

I'd rather than not nag why we want/need those, but if you prefer I
can repeat myself/others.

Thanks
Emil

[PATCH 2/2] amdgpu: add amdgpu_find_bo_by_cpu_mapping interface

[Chunming Zhou]

userspace needs to know if the user memory is from BO or malloc.

Change-Id: Ie2dbc13f1c02bc0a996f64f9db83a21da63c1d70
Signed-off-by: Chunming Zhou 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu.h  | 24 
 amdgpu/amdgpu_bo.c   | 37 +
 include/drm/amdgpu_drm.h | 12 
 3 files changed, 73 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index baae113..4925056 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -672,6 +672,30 @@ int amdgpu_create_bo_from_user_mem(amdgpu_device_handle 
dev,
amdgpu_bo_handle *buf_handle);

 /**
+ * Validate if the user memory comes from BO
+ *
+ * \param dev - [in] Device handle. See #amdgpu_device_initialize()
+ * \param cpu - [in] CPU address of user allocated memory which we
+ * want to map to GPU address space (make GPU accessible)
+ * (This address must be correctly aligned).
+ * \param size - [in] Size of allocation (must be correctly aligned)
+ * \param buf_handle - [out] Buffer handle for the userptr memory
+ * if the user memory is not from BO, the buf_handle will be NULL.
+ * \param offset_in_bo - [out] offset in this BO for this user memory
+ *
+ *
+ * \return   0 on success\n
+ *  <0 - Negative POSIX Error code
+ *
+*/
+int amdgpu_find_bo_by_cpu_mapping(amdgpu_device_handle dev,
+ void *cpu,
+ uint64_t size,
+ amdgpu_bo_handle *buf_handle,
+ uint64_t *offset_in_bo);
+
+
+/**
  * Free previosuly allocated memory
  *
  * \param   dev   - \c [in] Device handle. See 
#amdgpu_device_initialize()
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 5a0f4ac..82659a4 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -528,6 +528,43 @@ int amdgpu_bo_wait_for_idle(amdgpu_bo_handle bo,
}
 }

+int amdgpu_find_bo_by_cpu_mapping(amdgpu_device_handle dev,
+ void *cpu,
+ uint64_t size,
+ amdgpu_bo_handle *buf_handle,
+ uint64_t *offset_in_bo)
+{
+   int r;
+   struct amdgpu_bo *bo;
+   struct drm_amdgpu_gem_find_bo args;
+
+   args.addr = (uintptr_t)cpu;
+   args.size = size;
+   r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_GEM_FIND_BO,
+   &args, sizeof(args));
+   if (r)
+   return r;
+   if (args.handle == 0)
+   return -EINVAL;
+   bo = util_hash_table_get(dev->bo_handles,
+(void*)(uintptr_t)args.handle);
+   if (!bo) {
+   bo = calloc(1, sizeof(struct amdgpu_bo));
+   if (!bo)
+   return -ENOMEM;
+   atomic_set(&bo->refcount, 1);
+   bo->dev = dev;
+   bo->alloc_size = size;
+   bo->handle = args.handle;
+   } else
+   atomic_inc(&bo->refcount);
+
+   *buf_handle = bo;
+   *offset_in_bo = args.offset;
+   return r;
+}
+
+
 int amdgpu_create_bo_from_user_mem(amdgpu_device_handle dev,
void *cpu,
uint64_t size,
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 050e7fe..e07904c 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -47,6 +47,7 @@
 #define DRM_AMDGPU_GEM_OP  0x10
 #define DRM_AMDGPU_GEM_USERPTR 0x11
 #define DRM_AMDGPU_WAIT_FENCES 0x12
+#define DRM_AMDGPU_GEM_FIND_BO  0x13

 #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
 #define DRM_IOCTL_AMDGPU_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -61,6 +62,7 @@
 #define DRM_IOCTL_AMDGPU_GEM_OPDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_OP, struct drm_amdgpu_gem_op)
 #define DRM_IOCTL_AMDGPU_GEM_USERPTR   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
 #define DRM_IOCTL_AMDGPU_WAIT_FENCES   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
+#define DRM_IOCTL_AMDGPU_GEM_FIND_BO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_FIND_BO, struct drm_amdgpu_gem_find_bo)

 #define AMDGPU_GEM_DOMAIN_CPU  0x1
 #define AMDGPU_GEM_DOMAIN_GTT  0x2
@@ -201,6 +203,16 @@ struct drm_amdgpu_gem_userptr {
uint32_thandle;
 };

+struct drm_amdgpu_gem_find_bo {
+   uint64_taddr;
+   uint64_tsize;
+   uint32_tflags;
+   /* Resulting GEM handle */
+   uint32_thandle;
+   /* offset in bo */
+   uint64_toffset;
+};
+
 /* same meaning as the GB_TILE_MODE and GL_MAC

[PATCH] drm/amdgpu: return bo itself if userptr is cpu addr of bo V2

[Chunming Zhou]

V2: get original gem handle from gobj

Change-Id: I705eadfe03cd85c75bff252563d69f3c8a536868
Signed-off-by: Chunming Zhou 
Reviewed-by: Christian König 
Reviewed-by: Jammy Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 59 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
 include/uapi/drm/amdgpu_drm.h   | 12 +++
 4 files changed, 74 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 5b4f39c..1ffcbc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1842,6 +1842,8 @@ int amdgpu_gem_info_ioctl(struct drm_device *dev, void 
*data,
  struct drm_file *filp);
 int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
 int amdgpu_gem_mmap_ioctl(struct drm_device *dev, void *data,
  struct drm_file *filp);
 int amdgpu_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index fc32fc0..e461357 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -216,6 +216,65 @@ error_unlock:
return r;
 }

+static int amdgpu_gem_get_handle_from_object(struct drm_file *filp,
+struct drm_gem_object *obj)
+{
+   int i;
+   struct drm_gem_object *tmp;
+   spin_lock(&filp->table_lock);
+   idr_for_each_entry(&filp->object_idr, tmp, i) {
+   if (obj == tmp) {
+   drm_gem_object_reference(obj);
+   spin_unlock(&filp->table_lock);
+   return i;
+   }
+   }
+   spin_unlock(&filp->table_lock);
+   return 0;
+}
+
+
+int amdgpu_gem_find_bo_by_cpu_mapping_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp)
+{
+   struct drm_amdgpu_gem_find_bo *args = data;
+   struct drm_gem_object *gobj;
+   struct amdgpu_bo *bo;
+   struct ttm_buffer_object *tbo;
+   struct vm_area_struct *vma;
+   uint32_t handle;
+   int r;
+
+   if (offset_in_page(args->addr | args->size))
+   return -EINVAL;
+
+   down_read(¤t->mm->mmap_sem);
+   vma = find_vma(current->mm, args->addr);
+   if (!vma || vma->vm_file != filp->filp ||
+   (args->size > (vma->vm_end - args->addr))) {
+   args->handle = 0;
+   up_read(¤t->mm->mmap_sem);
+   return -EINVAL;
+   }
+   tbo = vma->vm_private_data;
+   bo = container_of(tbo, struct amdgpu_bo, tbo);
+   amdgpu_bo_ref(bo);
+   gobj = &bo->gem_base;
+   handle = amdgpu_gem_get_handle_from_object(filp, gobj);
+   if (handle == 0) {
+   r = drm_gem_handle_create(filp, gobj, &handle);
+   if (r) {
+   DRM_ERROR("create gem handle failed\n");
+   up_read(¤t->mm->mmap_sem);
+   return r;
+   }
+   }
+   args->handle = handle;
+   args->offset = args->addr - vma->vm_start;
+   up_read(¤t->mm->mmap_sem);
+   return 0;
+}
+
 int amdgpu_gem_userptr_ioctl(struct drm_device *dev, void *data,
 struct drm_file *filp)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index ff8f099..2c4c059 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -709,5 +709,6 @@ const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_FIND_BO, 
amdgpu_gem_find_bo_by_cpu_mapping_ioctl, 
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 6dcaa79..c9c01d58 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -47,6 +47,7 @@
 #define DRM_AMDGPU_GEM_OP  0x10
 #define DRM_AMDGPU_GEM_USERPTR 0x11
 #define DRM_AMDGPU_WAIT_FENCES 0x12
+#define DRM_AMDGPU_GEM_FIND_BO 0x13

 #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
 #define DRM_IOCTL_AMDGPU_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMD

[PATCH 1/2] amdgpu: add bo handle to hash table when cpu mapping

[Chunming Zhou]

Change-Id: Id79d98877c61510a1986d65befec6ce6713edae7
Signed-off-by: Chunming Zhou 
Reviewed-by: Jammy Zhou 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu_bo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index e47410c..5a0f4ac 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -462,7 +462,7 @@ int amdgpu_bo_cpu_map(amdgpu_bo_handle bo, void **cpu)
pthread_mutex_unlock(&bo->cpu_access_mutex);
return -errno;
}
-
+   amdgpu_add_handle_to_table(bo);
bo->cpu_ptr = ptr;
bo->cpu_map_count = 1;
pthread_mutex_unlock(&bo->cpu_access_mutex);
-- 
1.9.1

[PATCH 03/12] drm/etnaviv: add etnaviv UAPI header

[Emil Velikov]

On 4 December 2015 at 13:59, Lucas Stach  wrote:
> From: The etnaviv authors 
>
> This adds the header defining the user/kernel API for the
> etnaviv DRM driver.
>
> Signed-off-by: Christian Gmeiner 
> Signed-off-by: Russell King 
> Signed-off-by: Lucas Stach 
> ---
>  include/uapi/drm/etnaviv_drm.h | 221 
> +
>  1 file changed, 221 insertions(+)
>  create mode 100644 include/uapi/drm/etnaviv_drm.h
>
> diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
> new file mode 100644
> index ..0cce95efcd86
> --- /dev/null
> +++ b/include/uapi/drm/etnaviv_drm.h
> @@ -0,0 +1,221 @@
> +/*
> + * Copyright (C) 2015 Etnaviv Project
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#ifndef __ETNAVIV_DRM_H__
> +#define __ETNAVIV_DRM_H__
> +
> +#include 
> +
Guys, if we get to another revision of the patch can we make this a
"drm.h" please ?

Thanks
Emil

[Mesa-dev] [PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)

[Michel Thierry]

On 11/18/2015 10:53 PM, Kristian Høgsberg wrote:
> On Wed, Oct 14, 2015 at 5:11 AM, Michel Thierry
>  wrote:
>> On 10/14/2015 8:19 AM, Daniel Vetter wrote:
>>>
>>> On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian Høgsberg wrote:

 On Tue, Oct 13, 2015 at 7:55 AM, Michel Thierry
  wrote:
>
> On 10/13/2015 3:13 PM, Emil Velikov wrote:
>>
>>
>> On 13 October 2015 at 13:16, Michel Thierry 
>> wrote:
>>>
>>>
>>> On 10/6/2015 2:12 PM, Michel Thierry wrote:



 On 10/5/2015 7:06 PM, Kristian Høgsberg wrote:
>
>
>
> On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
>  wrote:
>>
>>
>>
>> On 9/14/2015 2:54 PM, Michał Winiarski wrote:
>>>
>>>
>>>
>>>
>>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:




 Gen8+ supports 48-bit virtual addresses, but some objects must
 always be
 allocated inside the 32-bit address range.

 In specific, any resource used with flat/heapless
 (0x-0xf000)
 General State Heap (GSH) or Instruction State Heap (ISH) must be
 in
 a
 32-bit range, because the General State Offset and Instruction
 State
 Offset
 are limited to 32-bits.

 The i915 driver has been modified to provide a flag to set when
 the
 4GB
 limit is not necessary in a given bo
 (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
 48-bit range will only be used when explicitly requested.

 Callers to the existing drm_intel_bo_emit_reloc function should
 set
 the
 use_48b_address_range flag beforehand, in order to use full ppgtt
 range.

 v2: Make set/clear functions nops on pre-gen8 platforms, and use
 them
  internally in emit_reloc functions (Ben)
  s/48BADDRESS/48B_ADDRESS/ (Dave)
 v3: Keep set/clear functions internal, no-one needs to use them
 directly.
 v4: Don't set 48bit-support flag in emit reloc, check for ppgtt
 type
  before enabling set/clear function, print full offsets in
 debug
  statements, using port of lower_32_bits and upper_32_bits
 from linux
  kernel (Michał)

 References:


 http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
 Cc: Ben Widawsky 
 Cc: Michał Winiarski 
>>>
>>>
>>>
>>>
>>>
>>> +Kristian
>>>
>>> LGTM.
>>> Acked-by: Michał Winiarski 
>>>
 Signed-off-by: Michel Thierry 
>>
>>
>>
>>
>>
>>
>> Hi Kristian,
>>
>> More comments on this?
>> I've resent the mesa patch with the last changes
>>
>>
>>
>> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>>
>>
>> Michał has agreed with the interface and will use it for his work.
>> If mesa doesn't plan to use this for now, it's ok. The kernel
>> changes
>> have
>> been done to prevent any regressions when the support 48-bit flag
>> is
>> not
>> set.
>
>
>
>
> I didn't get any replies to my last comments on this:
>
>
> http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html
>
> Basically, I tried explicitly placing buffers above 8G and didn't
> see
> the HW problem described (ie it all worked fine).  I still think
> there's some confusion as to what the W/A is about.
>
> Here's my take: the W/A is a SW-only workaround to handle the cases
> where a driver uses heapless and 48-bit ppgtt. The problem is that
> the
> heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
> anywhere it the 48 bit address space. If that happens it's
> consideredd
> out-of-bounds for the heap and access fails. To prevent this we need
> to make sure the bos we address in a heapless fashion are placed
> below
> 4g.
>
> For mesa, we only configure general state base as heap-less, which
> affects scratch bos. What this boils down to is that we need the 4G
> restriction only for the scratch bos set up on 3DSTATE_VS,
> 3DSTATE_GS
> and 3DSTATE_PS (an

[PATCH 1/7] drm: Don't overwrite UNVERFIED mode status to OK

[Ville Syrjälä]

On Fri, Dec 04, 2015 at 09:17:28AM +0100, Daniel Vetter wrote:
> On Thu, Dec 03, 2015 at 11:14:09PM +0200, ville.syrjala at linux.intel.com 
> wrote:
> > From: Ville Syrjälä 
> > 
> > The way the mode probing works is this:
> > 1. All modes currently on the mode list are marked as UNVERIFIED
> > 2. New modes are on the probed_modes list (they start with
> >status OK)
> > 3. Modes are moved from the probed_modes list to the actual
> >mode list. If a mode already on the mode list is deemed
> >to match one of the probed modes, the duplicate is dropped
> >and the mode status updated to OK. After this the
> >probed_modes list will be empty.
> > 4. All modes on the mode list are verified to not violate any
> >constraints. Any that do are marked as such.
> > 5. Any mode left with a non-OK status is pruned from the list,
> >with an appropriate debug message.
> 
> This would look really pretty as a kerneldoc addition to
> probe_single_connector(). And with asciidoc we can even do pretty ordered
> lists like these. Can you please follow-up with a patch for that?

I can try.

> 
> > 
> > What all this means is that any mode on the original list that
> > didn't have a duplicate on the probed_modes list, should be left
> > with status UNVERFIED (or previously could have been left with
> > some other status, but never OK).
> > 
> > I broke that in
> > commit 05acaec334fc ("drm: Reorganize probed mode validation")
> > by always assigning something to the mode->status during the validation
> > step. So any mode from the old list that still passed the validation
> > would be left on the list with status OK in the end.
> > 
> > Fix this by not doing the basic mode validation unless the mode
> > already has status OK (meaning it came from the probed_modes list,
> > or at least a duplicate of it was on that list). This way we will
> > correctly prune away any mode from the old mode list that didn't
> > appear on the probed_modes list.
> > 
> > Cc: stable at vger.kernel.org
> > Cc: Adam Jackson 
> > Fixes: 05acaec334fc ("drm: Reorganize probed mode validation")
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Daniel Vetter 
> 
> > ---
> >  drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 94ba39e34299..b9b3bd9349ff 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -229,7 +229,8 @@ static int 
> > drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
> > mode_flags |= DRM_MODE_FLAG_3D_MASK;
> >  
> > list_for_each_entry(mode, &connector->modes, head) {
> > -   mode->status = drm_mode_validate_basic(mode);
> > +   if (mode->status == MODE_OK)
> > +   mode->status = drm_mode_validate_basic(mode);
> >  
> > if (mode->status == MODE_OK)
> > mode->status = drm_mode_validate_size(mode, maxX, maxY);
> > -- 
> > 2.4.10
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC

[PATCH 01/20] drm: use __u{32, 64} instead of uint{32, 64}_t in virtgpu_drm.h

[Emil Velikov]

On 30 November 2015 at 14:10, Gabriel Laskar  wrote:
> Signed-off-by: Gabriel Laskar 
> CC: Emil Velikov 
> CC: Mikko Rapeli 
>
> ---
>  include/uapi/drm/virtgpu_drm.h | 98 
> +-
>  1 file changed, 49 insertions(+), 49 deletions(-)
>
For the series
Reviewed-by: Emil Velikov 

Dave would you have any comments wrt this and the remainder of Mikko's
series ? Alternatively what can we do to get those merged (would you
like a branch/pull request) ?

Thanks
Emil

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Rob Herring]

On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach  wrote:
> Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
>> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach  
>> wrote:
>> > Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
>> >> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
>> >> > Etnaviv follows the same priciple as imx-drm to have a virtual
>> >> > master device node to bind all the individual GPU cores together
>> >> > into one DRM device.
>> >> >
>> >> > Signed-off-by: Lucas Stach 
>> >> > ---
>> >> >  .../bindings/display/etnaviv/etnaviv-drm.txt   | 46 
>> >> > ++
>> >> >  1 file changed, 46 insertions(+)
>> >> >  create mode 100644 
>> >> > Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> >
>> >> > diff --git 
>> >> > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt 
>> >> > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > new file mode 100644
>> >> > index ..19fde29dc1d7
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
>> >> > @@ -0,0 +1,46 @@
>> >> > +Etnaviv DRM master device
>> >> > +
>> >> > +
>> >> > +The Etnaviv DRM master device is a virtual device needed to list all
>> >> > +Vivante GPU cores that comprise the GPU subsystem.
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible: Should be one of
>> >> > +"fsl,imx-gpu-subsystem"
>> >> > +"marvell,dove-gpu-subsystem"
>> >> > +- cores: Should contain a list of phandles pointing to Vivante GPU 
>> >> > devices
>> >> > +
>> >> > +example:
>> >> > +
>> >> > +gpu-subsystem {
>> >> > +   compatible = "fsl,imx-gpu-subsystem";
>> >> > +   cores = <&gpu_2d>, <&gpu_3d>;
>> >> > +};
>> >>
>> >> Yeah, I'm not really a fan of doing this simply because DRM wants 1
>> >> driver.
>> >>
>> > I'm aware of that, but I don't see much value in kicking this discussion
>> > around for every DRM driver submission. This is the binding that has
>> > emerged from a lengthy discussion at KS 2013 in Edinburgh and at least
>> > allows us to standardize on _something_. Also ALSA does a similar thing
>> > to bind codecs and CPU interfaces together.
>>
>> This case is quite different though I think. The ALSA case and other
>> DRM cases are ones that have inter-dependencies between the blocks
>> (e.g. some sort of h/w connection). What is the inter-dependency here?
>>
>> Doing this way has also been found to be completely unnecessary and
>> removed in recent DRM driver reviews. Admittedly, those are cases
>> where one device can be the master of the others. For 2 parallel
>> devices, I don't have an alternative other than question why they need
>> to be a single driver.
>>
> If you insist on doing things differently for this driver, we could add
> a pass at driver registration that scans through the DT, looking for
> nodes matching the GPU core compatible.

I've not insisted on anything. I'm only asking a question which didn't
get answered. I'll ask another way. Why can't you have 2 instances of
the same driver given they are only rendering nodes?

> I'm not sure if that makes things cleaner though and might bite us later
> on. Also I'm not sure if moving away from the binding scheme already
> established for other DRM drivers makes things better from a DT
> perspective. Personally I would prefer DT binding consistency over
> perfection for single drivers, segmenting the DT binding space.

This is the least of our issues in terms of consistency among drivers,
but that is in fact what I'm pushing for. This is probably the first
case of a render only driver (at least for DT). So this isn't a case
of just follow what others are doing.

The h/w in this area can be quite different, so the DT bindings are
going to reflect that to some extent. A virtual node makes sense in
some cases, but for others it may not.

Rob

[PATCH] drm: Fix an unwanted master inheritance v2

[Emil Velikov]

On 2 December 2015 at 17:24, Thomas Hellstrom  wrote:
> A client calling drmSetMaster() using a file descriptor that was opened
> when another client was master would inherit the latter client's master
> object and all its authenticated clients.
>
> This is unwanted behaviour, and when this happens, instead allocate a
> brand new master object for the client calling drmSetMaster().
>
> Fixes a BUG() throw in vmw_master_set().
>
> Cc: 
> Signed-off-by: Thomas Hellstrom 
Looks a lot better thanks!

Fwiw
Reviewed-by: Emil Velikov 

-Emil

[Bug 93236] Tonga garbled desktop since amdgpu/gfxv8: Cleanup of gfx_v8_0_tiling_mode_table_init()

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

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

--- Comment #8 from Andy Furniss  ---
Created attachment 120343
  --> https://bugs.freedesktop.org/attachment.cgi?id=120343&action=edit
removes stray break

OK I think I've found it now.

There's a stray break in the TONGA bit of the new code.

After a quick search I can't find any others.

-- 
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/20151204/489e61de/attachment.html>

[PATCH] drm/amdgpu: set snooped flags only on system addresses v2

[Christian König]

From: Christian König 

Not necessary for VRAM.

v2: no need to check if ttm is NULL.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8051cb9..8a1752f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -801,11 +801,12 @@ uint32_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
*adev, struct ttm_tt *ttm,
if (mem && mem->mem_type != TTM_PL_SYSTEM)
flags |= AMDGPU_PTE_VALID;

-   if (mem && mem->mem_type == TTM_PL_TT)
+   if (mem && mem->mem_type == TTM_PL_TT) {
flags |= AMDGPU_PTE_SYSTEM;

-   if (!ttm || ttm->caching_state == tt_cached)
-   flags |= AMDGPU_PTE_SNOOPED;
+   if (ttm->caching_state == tt_cached)
+   flags |= AMDGPU_PTE_SNOOPED;
+   }

if (adev->asic_type >= CHIP_TOPAZ)
flags |= AMDGPU_PTE_EXECUTABLE;
-- 
2.5.0

[PATCH 1/3] drm/amdgpu: set snooped flags only on system addresses

[Christian König]

On 04.12.2015 03:50, Michel Dänzer wrote:
> On 04.12.2015 03:55, Christian König wrote:
>> From: Christian König 
>>
>> Not necessary for VRAM.
>>
>> Signed-off-by: Christian König 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
>>   1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> index 8051cb9..298fb10 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> @@ -801,11 +801,12 @@ uint32_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
>> *adev, struct ttm_tt *ttm,
>>  if (mem && mem->mem_type != TTM_PL_SYSTEM)
>>  flags |= AMDGPU_PTE_VALID;
>>   
>> -if (mem && mem->mem_type == TTM_PL_TT)
>> +if (mem && mem->mem_type == TTM_PL_TT) {
>>  flags |= AMDGPU_PTE_SYSTEM;
>>   
>> -if (!ttm || ttm->caching_state == tt_cached)
>> -flags |= AMDGPU_PTE_SNOOPED;
>> +if (!ttm || ttm->caching_state == tt_cached)
>> +flags |= AMDGPU_PTE_SNOOPED;
>> +}
> Can ttm be NULL here if mem->mem_type == TTM_PL_TT?

Good point, I think the answer is no. Update patch is on it's way to the 
list.

Christian.

>
>
> Patches 2 & 3 are
>
> Reviewed-by: Michel Dänzer 
>
>

dumb BOs and prime

[Rob Herring]

On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
 wrote:
> Hi Rob,
>
> I got the same problem today with sti drm/kms driver and dumb Bo.
> The issue comes become hwcomposer because is the master and authenticated on
> /dev/dri/cardX
> Dumb allocation is done by gralloc which does a new open (so it is not
> authenticated) on drm node the consequence is that we can't use prime
> functions...
> If you use render node you won't be able to call dumb functions.
>
> To get out of this I think I will implement additional helpers in gem_cma to
> have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP
> and call them instead of dumb so be able to use render node.
> Of course it is only for drivers which already use gem_cma helpers (like
> sti)

That's only marginally better than per driver BO calls which is the
whole thing I'm trying to avoid. There should be some way to pass the
auth token to gralloc?

Rob

>
> Benjamin
>
>
> Le vendredi 4 décembre 2015, Martin Peres  a
> écrit :
>>
>> On 04/12/15 19:49, Rob Herring wrote:
>>>
>>> I'm working on getting Android working with DRM drivers. ATM, I'm
>>> using virtio-gpu as the driver and trying to get just KMS side working
>>> without rendering. I have it working with stock AOSP and the emulated
>>> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
>>> get things working with native KMS using drm_gralloc and
>>> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
>>> not sure how to solve without hacking around it.
>>>
>>> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
>>> allowed on render nodes and drmPrimeHandleToFD is not allowed on
>>> card0, so I'm stuck. I could open both nodes, but then I want the case
>>> of no render node to work. After some searching, I thought it was a
>>> matter of needing to do drmAuthMagic, but then found that is
>>> considered obsolete[2].
>>
>>
>> Obsolete when using render nodes, but still necessary on usual nodes
>> (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the
>> render nodes can do.
>>
>> Authentication should help! Please make sure you are master or
>> authenticated before doing anything on the usual nodes.
>>
>>>
>>> Rob
>>>
>>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>>> android-4.4
>>> [2]
>>> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>
>
> --
>
> Benjamin Gaignard
>
> Graphic Working Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
>
>

[PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel

[Javier Martinez Canillas]

Hello Inki,

On 12/04/2015 11:57 AM, Inki Dae wrote:
> Hi Javier,
> 
> 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas  osg.samsung.com>:
>> Hello Inki,
>>
>> On 12/04/2015 06:00 AM, Inki Dae wrote:
>>> Hi Javier,
>>>
>>> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
 Hello Inki,

 I found that v2 of this patch is alredy in your exynos-drm for-next branch 
 so
 so I had to revert it in linux-next to apply this one to test. You 
 shouldn't
 push patches that were still not reviewed (specially the ones that weren't
 tested like this one) to your branch that gets pulled by -next. The idea of
 -next is to have some test coverage but it should be as stable as possible.
>>>
>>> exynos-drm/for-next branch is not really for-next branch. This branch is 
>>> used
>>
>> Well, it is a for-next branch because is pulled by -next. It is listed in:
>> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees
>>
>> drm-exynos  git 
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next
>>
>>> only for integration test. As you know, there are many exynos maintainers
>>> and they have their own repository. So we would need to test the 
>>> integration.
>>
>> Integration testing is of course very needed and linux-next is for that but
>> what should be tested are the patches that are targeted to mainline.
>>
>>> For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
>>> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed 
>>> and
>>> tested patches will be merged to exynos-drm-next.
>>>
>>
>> In that case, exynos-drm-next is what should be pulled by linux-next, no the
>> for-next branch. Linux-next is a simulation of what Torvalds would do next
>> so problems are found earlier, ideally before the patches land into mainline.
> 
> Seems I didn't comment enough. exynos-drm/for-next branch includes all
> patches of exynos-drm-next
> and actually, they keep same patches for most time but sometimes, I
> merge additional patches only to
> exynos-drm/for-next, which should be more tested with other trees
> before going to Dave's tree.
> 

Ok, but unreviewed and more importantly untested patches should not
go to to exynos-drm/for-next because those will be made available in
linux-next and can cause issues.

Only patches that are known to be good and have been reviewed/acked
should go there.

> One more thing, there is other difference between exynos-drm-next and
> exynos-drm/for-next.
> That is all patches of exynos-drm-next are merged on top of based on
> Dave's drm-next branch.
> On the other hand, all of exynos-drm/for-next are merged on top of
> mainline. So if exynos-drm-next

It's OK if you keep a different branch because you need a different
base before sending your pull request but IMHO the patches in both
branches should always be the same.

> is merged to linux-next then all patches will be conflicted with
> Dave's tree because his branch
> is also merged to linux-next.
>
> I'm not sure that other maintainers always keep only the for-next
> branch in their repository but
> in my case, I use exynos-drm/for-next branch for the test before going
> to drm-next.
> Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree
> will also be pulled by
> linux-next, which would allow exynos-drm-next to be tested altogether
> again before going to mainline.
>

This should be a common problem for subsystems with different levels
of maintainership. I'm not a subsystem maintainer so I don't know how
this should be solved but I thought that git merge would take care
of this when both trees are pulled by linux-next.

Maybe Krzysztof can comment on this since he has to do the same for
the Exynos SoC support? He maintains a for-next branch and has to
send pull request to Kukjin (and sometimes may need to rebase on top
of Kukjin's tree) but both trees are pulled by linux-next to test.

> Thanks,
> Inki Dae
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH v2] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

[Alex Deucher]

On Fri, Dec 4, 2015 at 3:53 AM, Christian König
 wrote:
> On 04.12.2015 00:26, cpaul at redhat.com wrote:
>>
>> From: Lyude 
>>
>> HPD signals on DVI ports can be fired off before the pins required for
>> DDC probing actually make contact, due to the pins for HPD making
>> contact first. This results in a HPD signal being asserted but DDC
>> probing failing, resulting in hotplugging occasionally failing.
>>
>> This is somewhat rare on most cards (depending on what angle you plug
>> the DVI connector in), but on some cards it happens constantly. The
>> Radeon R5 on the machine used for testing this patch for instance, runs
>> into this issue just about every time I try to hotplug a DVI monitor and
>> as a result hotplugging almost never works.
>>
>> Rescheduling the hotplug work for a second when we run into an HPD
>> signal with a failing DDC probe usually gives enough time for the rest
>> of the connector's pins to make contact, and fixes this issue.
>>
>> Signed-off-by: Lyude 
>
>
> I find a second a bit long, but if it works so what?
>
> Looks sane enough to me, patch is Reviewed-by: Christian König
> 

Applied.  thanks!

Alex

>
>
>> ---
>> Sending this version of the patch because Jerome says this will probably
>> be the
>> least controversial of the potential fixes. Instead of sending userspace
>> tons of
>> hotplug events, we just reschedule the hotplug work.
>>
>>   drivers/gpu/drm/radeon/cik.c   |  2 +-
>>   drivers/gpu/drm/radeon/evergreen.c |  2 +-
>>   drivers/gpu/drm/radeon/r100.c  |  2 +-
>>   drivers/gpu/drm/radeon/r600.c  |  2 +-
>>   drivers/gpu/drm/radeon/radeon.h|  2 +-
>>   drivers/gpu/drm/radeon/radeon_connectors.c | 21 -
>>   drivers/gpu/drm/radeon/radeon_irq_kms.c|  8 
>>   drivers/gpu/drm/radeon/radeon_mode.h   |  1 +
>>   drivers/gpu/drm/radeon/rs600.c |  2 +-
>>   drivers/gpu/drm/radeon/si.c|  2 +-
>>   10 files changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 248953d..6801a0c 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -8472,7 +8472,7 @@ restart_ih:
>> if (queue_dp)
>> schedule_work(&rdev->dp_work);
>> if (queue_hotplug)
>> -   schedule_work(&rdev->hotplug_work);
>> +   schedule_delayed_work(&rdev->hotplug_work, 0);
>> if (queue_reset) {
>> rdev->needs_reset = true;
>> wake_up_all(&rdev->fence_queue);
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c
>> b/drivers/gpu/drm/radeon/evergreen.c
>> index 0acde19..f8e4986 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -5368,7 +5368,7 @@ restart_ih:
>> if (queue_dp)
>> schedule_work(&rdev->dp_work);
>> if (queue_hotplug)
>> -   schedule_work(&rdev->hotplug_work);
>> +   schedule_delayed_work(&rdev->hotplug_work, 0);
>> if (queue_hdmi)
>> schedule_work(&rdev->audio_work);
>> if (queue_thermal && rdev->pm.dpm_enabled)
>> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
>> index 238b13f..2df3c86 100644
>> --- a/drivers/gpu/drm/radeon/r100.c
>> +++ b/drivers/gpu/drm/radeon/r100.c
>> @@ -806,7 +806,7 @@ int r100_irq_process(struct radeon_device *rdev)
>> status = r100_irq_ack(rdev);
>> }
>> if (queue_hotplug)
>> -   schedule_work(&rdev->hotplug_work);
>> +   schedule_delayed_work(&rdev->hotplug_work, 0);
>> if (rdev->msi_enabled) {
>> switch (rdev->family) {
>> case CHIP_RS400:
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 4ea5b10..cc2fdf0 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -4276,7 +4276,7 @@ restart_ih:
>> WREG32(IH_RB_RPTR, rptr);
>> }
>> if (queue_hotplug)
>> -   schedule_work(&rdev->hotplug_work);
>> +   schedule_delayed_work(&rdev->hotplug_work, 0);
>> if (queue_hdmi)
>> schedule_work(&rdev->audio_work);
>> if (queue_thermal && rdev->pm.dpm_enabled)
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index b6cbd81..87db649 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -2414,7 +2414,7 @@ struct radeon_device {
>> struct r600_ih ih; /* r6/700 interrupt ring */
>> struct radeon_rlc rlc;
>> struct radeon_mec mec;
>> -   struct work_struct hotplug_work;
>> +   struct delayed_work hotplug_work;
>> struct work_struct dp_work;
>> struct work_struct audio_work;
>> int num_crtc; /* number of crtcs */
>> diff --git a/drivers/gpu/d

[PATCH] drm/amdgpu: set snooped flags only on system addresses v2

[Alex Deucher]

On Fri, Dec 4, 2015 at 7:32 AM, Christian König  
wrote:
> From: Christian König 
>
> Not necessary for VRAM.
>
> v2: no need to check if ttm is NULL.
>
> Signed-off-by: Christian König 

Applied the series.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 8051cb9..8a1752f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -801,11 +801,12 @@ uint32_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
> *adev, struct ttm_tt *ttm,
> if (mem && mem->mem_type != TTM_PL_SYSTEM)
> flags |= AMDGPU_PTE_VALID;
>
> -   if (mem && mem->mem_type == TTM_PL_TT)
> +   if (mem && mem->mem_type == TTM_PL_TT) {
> flags |= AMDGPU_PTE_SYSTEM;
>
> -   if (!ttm || ttm->caching_state == tt_cached)
> -   flags |= AMDGPU_PTE_SNOOPED;
> +   if (ttm->caching_state == tt_cached)
> +   flags |= AMDGPU_PTE_SNOOPED;
> +   }
>
> if (adev->asic_type >= CHIP_TOPAZ)
> flags |= AMDGPU_PTE_EXECUTABLE;
> --
> 2.5.0
>