[PATCH] drm/dp: cancel any work on disconnect

[Dave Airlie]

From: Dave Airlie 

Since we might have queued work but it hasn't executed yet
this could cause an oops in drm_dp_check_and_send_link_address.

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

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fb65f5d..7678cb5 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1936,6 +1936,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms

ret = 0;
} else {
+   /* flush any pending work */
+   cancel_work_sync(&mgr->work);
/* disable MST on the device */
mstb = mgr->mst_primary;
mgr->mst_primary = NULL;
-- 
2.4.1

[PATCH] drm/dp: look up the mstb passed into work function

[Dave Airlie]

From: Dave Airlie 

We should validate the passed in mstb under the lock
this should stop us getting an invalid mstb here.

(first attempt with cancelling work has lockdep issues).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89366

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index fb65f5d..ad0d1bf 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1198,9 +1198,14 @@ static struct drm_dp_mst_branch 
*drm_dp_get_mst_branch_device(struct drm_dp_mst_
 }

 static void drm_dp_check_and_send_link_address(struct drm_dp_mst_topology_mgr 
*mgr,
-  struct drm_dp_mst_branch *mstb)
+  struct drm_dp_mst_branch 
*mstb_in)
 {
struct drm_dp_mst_port *port;
+   struct drm_dp_mst_branch *mstb;
+
+   mstb = drm_dp_get_validated_mstb_ref(mgr, mstb_in);
+   if (!mstb)
+   return;

if (!mstb->link_address_sent) {
drm_dp_send_link_address(mgr, mstb);
@@ -1219,6 +1224,7 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
if (port->mstb)
drm_dp_check_and_send_link_address(mgr, port->mstb);
}
+   drm_dp_put_mst_branch_device(mstb);
 }

 static void drm_dp_mst_link_probe_work(struct work_struct *work)
-- 
2.4.1

[PATCH] drm/dp: cancel any work on disconnect

[Dave Airlie]

On 19 June 2015 at 10:20, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Since we might have queued work but it hasn't executed yet
> this could cause an oops in drm_dp_check_and_send_link_address.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89366

Ignore this, it was lockdeppy.

the other fix is better.

Dave.

[PATCH] drm: bridge/dw_hdmi: Filter modes > 165MHz for DVI

[Yakir Yang]

Doug & Russell,

在 2015/6/19 0:10, Doug Anderson 写道:
> Russell,
>
> On Thu, Jun 18, 2015 at 8:55 AM, Russell King - ARM Linux
>  wrote:
>>> Perhaps you can try 
>> Something like that needs to be done, but let's get rid of the mdvi
>> thing in struct hdmi_vmode - it doesn't belong there, it isn't part
>> of the currently set video mode, but becomes a property of the
>> connected sink.
>>
>> I'd also prefer it to be called "is_dvi_sink", especially as its
>> function is changing from "is it a CEA mode" to "is the attached
>> device a DVI sink".
>>
>> Even better would be to call it "is_hdmi_sink" to maintain positive
>> logic with single-negation where required, rather than double-
>> negation in places.
> Yakir: sounds like you now have some feedback on your patch now.
> Perhaps you can spin it with Russell's feedback?
>
> When you send it next, please make sure you include Russell in the
> "To" line.  Based at looking at who committed things to dw_hdmi in the
> past, I've been sending my patches "To":
>  Philipp Zabel
>  Russell King
>  Thierry Reding
>
> ...so perhaps that would be good for you to do, too?

Okay,  thanks for your remind.

>>> I am nowhere near an HDMI expert.  If you have a better suggestion
>>> then I'm more than happy for you to post it and drop my patch.  In my
>>> non-expert opinion, it would seem awfully strange for an AV receiver
>>> to modify the EDID though unless it was actively interpreting the
>>> signal and generating a whole new signal on the other end.  In any
>>> case, perhaps you can find such a device and that will give insight to
>>> how we should deal with it.  Until such a device is found, it seems
>>> fruitless to speculate.
>> Neither am I, but I have had the ability to do some testing with AV
>> receivers in the path of a HDMI device, and I've seen how they behave.
>> (I made copious notes on this, which I intend to publish when I have
>> a round tuit.)  Unfortunately, I have no DVI devices to test with,
>> and DVI devices are a dying breed - most monitors today come with
>> HDMI sockets instead.
> Ah, OK.  Have you seen any that specifically confuse the DVI vs. HDMI bits?
>
> I still have copious DVI devices around, personally.  I could have
> sworn that supporting "older hardware" was actually pretty important
> in Linux.  ...and I can still buy plenty of DVI devices out there.
>
>
>> That's a shame... I'm not inclined to Ack it as-is - and I'd also like
>> to see Yakir's patch reworked as I mentioned above.
> Perhaps when Yakir spins his series he can include a patch like mine
> in it.  It doesn't make sense for me to re-spin it until his is
> resolved.
I will rebase on russell series and re-send my patch today.

- Yakir
> -Doug
>
>
>

[PATCH] drm/radeon: don't probe MST on hw we don't support it on

[Dave Airlie]

On 18 June 2015 at 23:12, Christian König  wrote:
> On 18.06.2015 10:31, Dave Airlie wrote:
>>
>> On 18 June 2015 at 17:39, Christian König  
>> wrote:
>>>
>>> On 18.06.2015 06:29, Dave Airlie wrote:

 From: Dave Airlie 

 If you do radeon.mst=1 on a gpu without mst hw, and then
 plug some mst hw it will oops instead of falling back.

 So check we have DCE5 at least before proceeding.

 Signed-off-by: Dave Airlie 
>>>
>>>
>>> Reviewed-by: Christian König 
>>>
>>> BTW: Since Alex is on vacation I'm managing drm-fixes for Radeon/Amdgpu
>>> for
>>> a while.
>>>
>>> Should I add that patch to my pull request on Friday or do you wan to add
>>> it
>>> directly?
>>>
>> Can you add it, and maybe send the fixes pull a bit earlier :-),
>
>
> Only when I have to, as usually I'm quite busy ;)
>
>> since Friday for you is my Saturday, and I don't always make it to the
>> laptop before Sunday.
>
>
> Hui? In what time zone are you? Keep in mind that unlike Alex I live and
> work from Germany, so I'm in CET as well.

UTC+10 (Brisbane) and Friday night is generally not when I pull stuff in,
so it usually means any attempts to send me stuff on Friday lead me to doing
stuff Saturday morning, and lots of times that just doesn't happen :-)

Dave.

[PATCH 1/6] drm/rockchip: import dma_buf to gem

[Mark yao]

Thanks Russell
On 2015年06月18日 18:57, Russell King - ARM Linux wrote:
> This is wrong.
>
> First, if you can only cope with a single scatterlist entry, you need to
> enforce that.  You can do that in your gem_prime_import_sg_table() method
> by checking sgt->nents.
I'm confuse that how to get coherent iova address from nocoherent 
scatterlist with iommu.
I saw the arm_iommu_map_sg, it says that:
 The scatter gather list elements are merged together (if 
possible) and
  tagged with the appropriate dma address and length.

I guess the map_sg maybe merge scatterlist into coherent iova address, 
but I don't know how to
check the "if possible", and the sgt->nents not be 1 when already map to 
coherent iova address.

checking sgt-nents = 1 can sure that iova is coherent, but when coherent 
iova address from
nocoherent scatterlist, I think sgt->nents maybe greater than 1, is 
there a method can deal it?

All above is my guess, maybe wrong, I only tested it with CMA buffer import.

> Secondly, you're mapping an already mapped scatterlist - scatterlists
> are mapped by the exporter inside dma_buf_map_attachment() for your
> device.

Right, found the dma_map_sg on dma_buf_map_attachment().

>
> Thirdly, I hate drm_gem_prime_import() being used on ARM... it forces
> drivers to do something very buggy: the DMA buffer is mapped for DMA
> when the buffer is imported.  If the buffer is a write-combine or cached
> buffer, writes to the buffer after the import will not become visible to
> the display hardware until sometime later (when they're evicted from the
> caches and/or pushed out of the bus structure.)  The DMA mapping should
> be performed as close to the start of DMA as possible.  However, this is
> a long-standing issue I have with dma_buf itself and is not something you
> should be too concerned with in your patch.  Just bear it in mind if you
> start to see corruption of imported buffers - the answer is not more
> dma_map_sg() calls, but to get dma_buf fixed.
Yeah, Got it.

-- 
ï¼­ark Yao

[PULL] drm-intel-next-fixes

[Dave Airlie]

On 18 June 2015 at 16:04, Jani Nikula  wrote:
>
> Hi Dave, i915 fixes for drm-next/v4.2.
>
> BR,
> Jani.

And my gcc says:

/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:
In function ‘__intel_set_mode’:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11850:14:
warning: ‘crtc_state’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  return state->mode_changed || state->active_changed;
  ^
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11860:25:
note: ‘crtc_state’ was declared here
  struct drm_crtc_state *crtc_state;
 ^
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11874:6:
warning: ‘crtc’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   if (crtc != intel_encoder->base.crtc)
  ^
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11859:19:
note: ‘crtc’ was declared here
  struct drm_crtc *crtc;
   ^

No idea if this is true, but I don't think I've seen it before now.

gcc 5.1.1 on fedora 22

Dave.

[Nouveau] [PATCH 1/6] gr: support for NVIDIA-provided firmwares

[Alexandre Courbot]

On Fri, Jun 19, 2015 at 12:57 AM, Ilia Mirkin  wrote:
> Why did you change request_firmware to request_firmware_direct?

request_firmware() outputs an error message if the firmware file does
not exist, whereas request_firmware_direct() doesn't. Since the
firmware file can be in one of two locations, that seems to be the
most appropriate behavior.

However, request_firmware_direct() also does not invoke the userspace
helper. In the case of Nouveau I don't believe we need this, but if I
overlooked something let me know and I will think of something else.

[PATCH] drm/atomic: Extract needs_modeset function

[Maarten Lankhorst]

Op 18-06-15 om 11:25 schreef Daniel Vetter:
> We use the same check already in the atomic core, so might as well
> make this official. And it's also reused in e.g. i915.
>
> Motivated by Maarten's idea to extract a connector_changed state out
> of mode_changed.
>
> Cc: Maarten Lankhorst 
> Signed-off-by: Daniel Vetter 
>
Reviewed-By: Maarten Lankhorst 

[PATCH 1/6] gr: support for NVIDIA-provided firmwares

[Ben Skeggs]

On 19 June 2015 at 00:47, Alexandre Courbot  wrote:
> NVIDIA will officially start providing signed firmwares through
> linux-firmware. Change the GR firmware lookup function to look them up
> in addition to the extracted firmwares.
I wonder if perhaps we should just replace the mechanism entirely, and
remove the support for nouveau/fuc* as we add "official" support for
NVIDIA's ucode.  The existing code is actually partially broken
anyway, and mostly works by luck and was intended as a development aid
/ workaround anyway.  There are no chipsets (aside from GM2xx...)
which we don't currently support using our own ucode, so the impact of
removing it will be very minimal.

Thoughts?

Ben.

>
> Signed-off-by: Alexandre Courbot 
> ---
>  drm/nouveau/nvkm/engine/gr/gf100.c | 66 
> +-
>  1 file changed, 51 insertions(+), 15 deletions(-)
>
> diff --git a/drm/nouveau/nvkm/engine/gr/gf100.c 
> b/drm/nouveau/nvkm/engine/gr/gf100.c
> index ca11ddb..39d482f 100644
> --- a/drm/nouveau/nvkm/engine/gr/gf100.c
> +++ b/drm/nouveau/nvkm/engine/gr/gf100.c
> @@ -1544,26 +1544,62 @@ gf100_gr_dtor_fw(struct gf100_gr_fuc *fuc)
> fuc->data = NULL;
>  }
>
> +/**
> + * gf100_gr_ctor_fw - helper for loading external GR firmwares
> + *
> + * A firmware can either be officially provided by NVIDIA (in which case it 
> will
> + * use a "NVIDIA name", or be extracted from the binary blob (and use a
> + * "Nouveau name". The fwname and nvfwname are to be given the Nouveau and
> + * NVIDIA names of a given firmware, respectively. This function will then
> + * try to load the NVIDIA firmware, then the extracted one, in that order.
> + *
> + */
>  int
>  gf100_gr_ctor_fw(struct gf100_gr_priv *priv, const char *fwname,
> -struct gf100_gr_fuc *fuc)
> +const char *nvfwname, struct gf100_gr_fuc *fuc)
>  {
> struct nvkm_device *device = nv_device(priv);
> const struct firmware *fw;
> -   char f[32];
> -   int ret;
> +   char f[64];
> +   int ret = -EINVAL;
> +   int i;
>
> -   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset, fwname);
> -   ret = request_firmware(&fw, f, nv_device_base(device));
> -   if (ret) {
> -   snprintf(f, sizeof(f), "nouveau/%s", fwname);
> -   ret = request_firmware(&fw, f, nv_device_base(device));
> -   if (ret) {
> -   nv_error(priv, "failed to load %s\n", fwname);
> -   return ret;
> +   /*
> +* NVIDIA firmware name provided - try to load it
> +* We try this first since most chips that require external firmware
> +* are supported by NVIDIA
> +*/
> +   if (nvfwname) {
> +   snprintf(f, sizeof(f), "nvidia/%s/%s.bin", device->cname,
> +nvfwname);
> +   i = strlen(f);
> +   while (i) {
> +   --i;
> +   f[i] = tolower(f[i]);
> }
> +   ret = request_firmware_direct(&fw, f, nv_device_base(device));
> +   if (!ret)
> +   goto found;
> +   }
> +
> +   /* Nouveau firmware name provided - try to load it */
> +   if (fwname) {
> +   snprintf(f, sizeof(f), "nouveau/nv%02x_%s", device->chipset,
> +fwname);
> +   ret = request_firmware_direct(&fw, f, nv_device_base(device));
> +   if (!ret)
> +   goto found;
> +
> +   snprintf(f, sizeof(f), "nouveau/%s", fwname);
> +   ret = request_firmware_direct(&fw, f, nv_device_base(device));
> +   if (!ret)
> +   goto found;
> }
>
> +   nv_error(priv, "failed to load %s / %s\n", fwname, nvfwname);
> +   return ret;
> +
> +found:
> fuc->size = fw->size;
> fuc->data = kmemdup(fw->data, fuc->size, GFP_KERNEL);
> release_firmware(fw);
> @@ -1615,10 +1651,10 @@ gf100_gr_ctor(struct nvkm_object *parent, struct 
> nvkm_object *engine,
>
> if (use_ext_fw) {
> nv_info(priv, "using external firmware\n");
> -   if (gf100_gr_ctor_fw(priv, "fuc409c", &priv->fuc409c) ||
> -   gf100_gr_ctor_fw(priv, "fuc409d", &priv->fuc409d) ||
> -   gf100_gr_ctor_fw(priv, "fuc41ac", &priv->fuc41ac) ||
> -   gf100_gr_ctor_fw(priv, "fuc41ad", &priv->fuc41ad))
> +   if (gf100_gr_ctor_fw(priv, "fuc409c", "fecs_inst", 
> &priv->fuc409c) ||
> +   gf100_gr_ctor_fw(priv, "fuc409d", "fecs_data", 
> &priv->fuc409d) ||
> +   gf100_gr_ctor_fw(priv, "fuc41ac", "gpccs_inst", 
> &priv->fuc41ac) ||
> +   gf100_gr_ctor_fw(priv, "fuc41ad", "gpccs_data", 
> &priv->fuc41ad))
> return -ENODEV;
> priv->firmware = true;
> }
> --
> 2.4.3
>
> _

[PATCH 1/6] gr: support for NVIDIA-provided firmwares

[Alexandre Courbot]

On Fri, Jun 19, 2015 at 1:40 PM, Ben Skeggs  wrote:
> On 19 June 2015 at 00:47, Alexandre Courbot  wrote:
>> NVIDIA will officially start providing signed firmwares through
>> linux-firmware. Change the GR firmware lookup function to look them up
>> in addition to the extracted firmwares.
> I wonder if perhaps we should just replace the mechanism entirely, and
> remove the support for nouveau/fuc* as we add "official" support for
> NVIDIA's ucode.  The existing code is actually partially broken
> anyway, and mostly works by luck and was intended as a development aid
> / workaround anyway.  There are no chipsets (aside from GM2xx...)
> which we don't currently support using our own ucode, so the impact of
> removing it will be very minimal.
>
> Thoughts?

I'm all for making things simpler, and if someone needs to use an
external firmware for a Nouveau-supported GPU they can always put it
under the nvidia/ firmware directory. So if you agree with it I will
remove support for firmwares in nouveau/ in GR. I am not sure whether
your statement also applies to other firmwares (falcon, xtensa)?

[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[Krzysztof Kozlowski]

The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is
not referenced anywhere.

One instance of 'exynos_drm_gem_obj' may be mapped to multiple
user-space VMAs so 'vma' field does not look useful anyway.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 308173cb4f0a..6f42e2248288 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
  * or at framebuffer creation.
  * @size: size requested from user, in bytes and this size is aligned
  * in page unit.
- * @vma: a pointer to vm_area.
  * @flags: indicate memory type to allocated buffer and cache attruibute.
  *
  * P.S. this object would be transferred to user as kms_bo.handle so
@@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
struct drm_gem_object   base;
struct exynos_drm_gem_buf   *buffer;
unsigned long   size;
-   struct vm_area_struct   *vma;
unsigned intflags;
 };

-- 
1.9.1

[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[Inki Dae]

On 2015년 06월 19일 14:23, Krzysztof Kozlowski wrote:
> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
> 2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is
> not referenced anywhere.
> 
> One instance of 'exynos_drm_gem_obj' may be mapped to multiple
> user-space VMAs so 'vma' field does not look useful anyway.

Krzysztof,

The vma member would be removed by below patch,
http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html

Thanks,
Inki Dae

> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index 308173cb4f0a..6f42e2248288 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
>   *   or at framebuffer creation.
>   * @size: size requested from user, in bytes and this size is aligned
>   *   in page unit.
> - * @vma: a pointer to vm_area.
>   * @flags: indicate memory type to allocated buffer and cache attruibute.
>   *
>   * P.S. this object would be transferred to user as kms_bo.handle so
> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
>   struct drm_gem_object   base;
>   struct exynos_drm_gem_buf   *buffer;
>   unsigned long   size;
> - struct vm_area_struct   *vma;
>   unsigned intflags;
>  };
>  
> 

[Nouveau] [PATCH v2 2/2] drm/nouveau: add GEM_SET_TILING staging ioctl

[Alexandre Courbot]

On Tue, Jun 16, 2015 at 7:07 PM, Daniel Vetter  wrote:
> On Mon, Jun 15, 2015 at 06:08:21PM +0900, Alexandre Courbot wrote:
>> On 06/15/2015 04:56 PM, Daniel Vetter wrote:
>> >On Mon, Jun 15, 2015 at 04:09:29PM +0900, Alexandre Courbot wrote:
>> >>From: Ari Hirvonen 
>> >>
>> >>Add new NOUVEAU_GEM_SET_TILING ioctl to set correct tiling
>> >>mode for imported dma-bufs. This ioctl is staging for now
>> >>and enabled with the "staging_tiling" module option.
>> >>
>> >>Signed-off-by: Ari Hirvonen 
>> >>[acourbot at nvidia.com: carry upstream, many fixes]
>> >>Signed-off-by: Alexandre Courbot 
>> >>---
>> >>  drm/nouveau/nouveau_bo.c   | 18 
>> >>  drm/nouveau/nouveau_bo.h   |  2 ++
>> >>  drm/nouveau/nouveau_drm.c  |  6 
>> >>  drm/nouveau/nouveau_gem.c  | 58 
>> >> ++
>> >>  drm/nouveau/nouveau_gem.h  |  2 ++
>> >>  drm/nouveau/nouveau_ttm.c  | 13 +
>> >>  drm/nouveau/uapi/drm/nouveau_drm.h |  8 ++
>> >>  7 files changed, 95 insertions(+), 12 deletions(-)
>> >>
>> >>diff --git a/drm/nouveau/nouveau_bo.c b/drm/nouveau/nouveau_bo.c
>> >>index 6edcce1658b7..2a2ebbeb4fc0 100644
>> >>--- a/drm/nouveau/nouveau_bo.c
>> >>+++ b/drm/nouveau/nouveau_bo.c
>> >>@@ -178,6 +178,24 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 
>> >>flags,
>> >>*size = roundup(*size, PAGE_SIZE);
>> >>  }
>> >>
>> >>+void
>> >>+nouveau_bo_update_tiling(struct nouveau_drm *drm, struct nouveau_bo *nvbo,
>> >>+struct nvkm_mem *mem)
>> >>+{
>> >>+   switch (drm->device.info.family) {
>> >>+   case NV_DEVICE_INFO_V0_TESLA:
>> >>+   if (drm->device.info.chipset != 0x50)
>> >>+   mem->memtype = (nvbo->tile_flags & 0x7f00) >> 8;
>> >>+   break;
>> >>+   case NV_DEVICE_INFO_V0_FERMI:
>> >>+   case NV_DEVICE_INFO_V0_KEPLER:
>> >>+   mem->memtype = (nvbo->tile_flags & 0xff00) >> 8;
>> >>+   break;
>> >>+   default:
>> >>+   break;
>> >>+   }
>> >>+}
>> >>+
>> >>  int
>> >>  nouveau_bo_new(struct drm_device *dev, int size, int align,
>> >>   uint32_t flags, uint32_t tile_mode, uint32_t tile_flags,
>> >>diff --git a/drm/nouveau/nouveau_bo.h b/drm/nouveau/nouveau_bo.h
>> >>index e42360983229..87d07e3533eb 100644
>> >>--- a/drm/nouveau/nouveau_bo.h
>> >>+++ b/drm/nouveau/nouveau_bo.h
>> >>@@ -69,6 +69,8 @@ nouveau_bo_ref(struct nouveau_bo *ref, struct nouveau_bo 
>> >>**pnvbo)
>> >>  extern struct ttm_bo_driver nouveau_bo_driver;
>> >>
>> >>  void nouveau_bo_move_init(struct nouveau_drm *);
>> >>+void nouveau_bo_update_tiling(struct nouveau_drm *, struct nouveau_bo *,
>> >>+ struct nvkm_mem *);
>> >>  int  nouveau_bo_new(struct drm_device *, int size, int align, u32 flags,
>> >>u32 tile_mode, u32 tile_flags, struct sg_table *sg,
>> >>struct reservation_object *robj,
>> >>diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
>> >>index 28860268cf38..45a2c88ebf8e 100644
>> >>--- a/drm/nouveau/nouveau_drm.c
>> >>+++ b/drm/nouveau/nouveau_drm.c
>> >>@@ -75,6 +75,10 @@ MODULE_PARM_DESC(runpm, "disable (0), force enable (1), 
>> >>optimus only default (-1
>> >>  int nouveau_runtime_pm = -1;
>> >>  module_param_named(runpm, nouveau_runtime_pm, int, 0400);
>> >>
>> >>+MODULE_PARM_DESC(staging_tiling, "enable staging GEM_SET_TILING ioctl");
>> >>+int nouveau_staging_tiling = 0;
>> >>+module_param_named(staging_tiling, nouveau_staging_tiling, int, 0600);
>> >
>> >Please use _unsafe here to make sure that setting this option taints the
>> >kernel and gives at least a bit of a deterrent. But in the end the policy
>> >is still that you can't regress anything if people complain, which means
>> >you might end up with a staging ioctl locked down forever.
>>
>> That would kind of kill the whole purpose of this patchset. But at the same
>> time the point of having staging ioctls is to say "don't use them in
>> production", so hopefully the message is clear.
>>
>> >The other part I don't like with this plan is that it looks a bit like it
>> >could be easily abused to evade the open source userspace requirement
>> >upstream has for new interfaces. Doesn't help that your first staging
>> >ioctl doesn't come with links to mesa/hwc/whatever patches attached ;-)
>>
>> Well, you could abuse it - no more than 8 times though. ;)
>>
>> The point is not to evade anything though, but rather to have the necessary
>> kernel code land in such a way that we can experiment with Mesa and other
>> user-space.
>>
>> >Overall I don't think this will help - you need internal branch management
>> >anyway, and upstreaming new ABI is somewhat painful for a reason: Screwing
>> >things up is really expensive long-term, and the drm community has paid
>> >that price a few too many times.
>>
>> It seems to me that this staging feature can exactly help with that: allow
>> new ioctls to mature a bit (no longer than a kernel release 

[PATCH 1/6] gr: support for NVIDIA-provided firmwares

[Ben Skeggs]

On 19 June 2015 at 15:22, Alexandre Courbot  wrote:
> On Fri, Jun 19, 2015 at 1:40 PM, Ben Skeggs  wrote:
>> On 19 June 2015 at 00:47, Alexandre Courbot  wrote:
>>> NVIDIA will officially start providing signed firmwares through
>>> linux-firmware. Change the GR firmware lookup function to look them up
>>> in addition to the extracted firmwares.
>> I wonder if perhaps we should just replace the mechanism entirely, and
>> remove the support for nouveau/fuc* as we add "official" support for
>> NVIDIA's ucode.  The existing code is actually partially broken
>> anyway, and mostly works by luck and was intended as a development aid
>> / workaround anyway.  There are no chipsets (aside from GM2xx...)
>> which we don't currently support using our own ucode, so the impact of
>> removing it will be very minimal.
>>
>> Thoughts?
>
> I'm all for making things simpler, and if someone needs to use an
> external firmware for a Nouveau-supported GPU they can always put it
> under the nvidia/ firmware directory. So if you agree with it I will
> remove support for firmwares in nouveau/ in GR. I am not sure whether
> your statement also applies to other firmwares (falcon, xtensa)?
I'd say leave the non-gr engines for now, at least until we know what
NVIDIA plans on doing with dGPU firmwares.

[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[Krzysztof Kozlowski]

2015-06-19 14:28 GMT+09:00 Inki Dae :
> On 2015년 06월 19일 14:23, Krzysztof Kozlowski wrote:
>> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
>> 2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is
>> not referenced anywhere.
>>
>> One instance of 'exynos_drm_gem_obj' may be mapped to multiple
>> user-space VMAs so 'vma' field does not look useful anyway.
>
> Krzysztof,
>
> The vma member would be removed by below patch,
> http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html
>

I think it is a different object. The patch above removes it from
struct g2d_cmdlist_userptr.
However I removed it from struct exynos_drm_gem_obj, where it was
never referenced.

Best regards,
Krzysztof

> Thanks,
> Inki Dae
>
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> index 308173cb4f0a..6f42e2248288 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
>>   *   or at framebuffer creation.
>>   * @size: size requested from user, in bytes and this size is aligned
>>   *   in page unit.
>> - * @vma: a pointer to vm_area.
>>   * @flags: indicate memory type to allocated buffer and cache attruibute.
>>   *
>>   * P.S. this object would be transferred to user as kms_bo.handle so
>> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
>>   struct drm_gem_object   base;
>>   struct exynos_drm_gem_buf   *buffer;
>>   unsigned long   size;
>> - struct vm_area_struct   *vma;
>>   unsigned intflags;
>>  };
>>
>>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[Inki Dae]

On 2015년 06월 19일 14:46, Krzysztof Kozlowski wrote:
> 2015-06-19 14:28 GMT+09:00 Inki Dae :
>> On 2015년 06월 19일 14:23, Krzysztof Kozlowski wrote:
>>> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
>>> 2a3098ff6c21 ("drm/exynos: add userptr feature for g2d module") but is
>>> not referenced anywhere.
>>>
>>> One instance of 'exynos_drm_gem_obj' may be mapped to multiple
>>> user-space VMAs so 'vma' field does not look useful anyway.
>>
>> Krzysztof,
>>
>> The vma member would be removed by below patch,
>> http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html
>>
> 
> I think it is a different object. The patch above removes it from
> struct g2d_cmdlist_userptr.
> However I removed it from struct exynos_drm_gem_obj, where it was
> never referenced.

Ah, right. There was my mistake.

Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Krzysztof Kozlowski 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 308173cb4f0a..6f42e2248288 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
>>>   *   or at framebuffer creation.
>>>   * @size: size requested from user, in bytes and this size is aligned
>>>   *   in page unit.
>>> - * @vma: a pointer to vm_area.
>>>   * @flags: indicate memory type to allocated buffer and cache attruibute.
>>>   *
>>>   * P.S. this object would be transferred to user as kms_bo.handle so
>>> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
>>>   struct drm_gem_object   base;
>>>   struct exynos_drm_gem_buf   *buffer;
>>>   unsigned long   size;
>>> - struct vm_area_struct   *vma;
>>>   unsigned intflags;
>>>  };
>>>
>>>
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 1/2] drm/radeon: compute ring fix hibernation (CI GPU family).

[Christian König]

On 19.06.2015 00:31, j.glisse at gmail.com wrote:
> From: Jérôme Glisse 
>
> In order for hibernation to reliably work we need to cleanup more
> thoroughly the compute ring. Hibernation is different from suspend
> resume as when we resume from hibernation the hardware is first
> fully initialize by regular kernel then freeze callback happens
> (which correspond to a suspend inside the radeon kernel driver)
> and turn off each of the block. It turns out we were not cleanly
> shutting down the compute ring. This patch fix that.
>
> Hibernation and suspend to ram were tested (several times) on :
> Bonaire
> Hawaii
> Mullins
> Kaveri
> Kabini
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Jérôme Glisse 
> ---
>   drivers/gpu/drm/radeon/cik.c |   55 
> ++
>   1 files changed, 55 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index ba50f3c..d2576d4 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -4592,6 +4592,61 @@ static void cik_cp_compute_enable(struct radeon_device 
> *rdev, bool enable)
>   if (enable)
>   WREG32(CP_MEC_CNTL, 0);
>   else {
> + u32 tmp;
> + int idx, j;
> +
> + /*
> +  * To make hibernation reliable we need to clear compute ring
> +  * configuration before halting the compute ring.
> +  */
> + mutex_lock(&rdev->srbm_mutex);
> +
> + idx = CAYMAN_RING_TYPE_CP1_INDEX;
> + cik_srbm_select(rdev, rdev->ring[idx].me,
> + rdev->ring[idx].pipe,
> + rdev->ring[idx].queue, 0);
> + /* Disable wptr polling. */
> + tmp = RREG32(CP_PQ_WPTR_POLL_CNTL);
> + tmp &= ~WPTR_POLL_EN;
> + WREG32(CP_PQ_WPTR_POLL_CNTL, tmp);
> + /* Disable HQD. */
> + if (RREG32(CP_HQD_ACTIVE) & 1) {
> + WREG32(CP_HQD_DEQUEUE_REQUEST, 1);
> + for (j = 0; j < rdev->usec_timeout; j++) {
> + if (!(RREG32(CP_HQD_ACTIVE) & 1))
> + break;
> + udelay(1);
> + }
> + WREG32(CP_HQD_DEQUEUE_REQUEST, 0);
> + WREG32(CP_HQD_PQ_RPTR, 0);
> + WREG32(CP_HQD_PQ_WPTR, 0);
> + }
> + cik_srbm_select(rdev, 0, 0, 0, 0);

Could you factor out this part into a function which just takes a 
radeon_ring* argument?

Apart from that this patch and the other one looks good to me,
Christian.

> +
> + idx = CAYMAN_RING_TYPE_CP2_INDEX;
> + cik_srbm_select(rdev, rdev->ring[idx].me,
> + rdev->ring[idx].pipe,
> + rdev->ring[idx].queue, 0);
> + /* Disable wptr polling. */
> + tmp = RREG32(CP_PQ_WPTR_POLL_CNTL);
> + tmp &= ~WPTR_POLL_EN;
> + WREG32(CP_PQ_WPTR_POLL_CNTL, tmp);
> + /* Disable HQD. */
> + if (RREG32(CP_HQD_ACTIVE) & 1) {
> + WREG32(CP_HQD_DEQUEUE_REQUEST, 1);
> + for (j = 0; j < rdev->usec_timeout; j++) {
> + if (!(RREG32(CP_HQD_ACTIVE) & 1))
> + break;
> + udelay(1);
> + }
> + WREG32(CP_HQD_DEQUEUE_REQUEST, 0);
> + WREG32(CP_HQD_PQ_RPTR, 0);
> + WREG32(CP_HQD_PQ_WPTR, 0);
> + }
> + cik_srbm_select(rdev, 0, 0, 0, 0);
> +
> + mutex_unlock(&rdev->srbm_mutex);
> +
>   WREG32(CP_MEC_CNTL, (MEC_ME1_HALT | MEC_ME2_HALT));
>   rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX].ready = false;
>   rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX].ready = false;

[Bug 91009] [radeonsi, R9 270X] Random system lockup when start to play H.264 video in mplayer with VDPAU

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

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

--- Comment #5 from Yuriy Kolesnikov  ---
I had doubts about kernel, because I use -ck patchset. But I have switched to
vanilla linux from git, and git version of mesa and I have encountered same
issue when I started to play video.

-- 
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/20150619/f0ad05a5/attachment.html>

[PATCH 1/1] drm/radeon: use kzalloc for allocating one thing

[Christian König]

On 19.06.2015 06:05, Maninder Singh wrote:
> Use kzalloc for allocating one thing rather than
> kcalloc(1...
>
> The semantic patch that makes this change is as follows:
>
> // 
> @@
> @@
>
> - kcalloc(1,
> + kzalloc(
>...)
> // 
>
> Signed-off-by: Maninder Singh 
> Reviewed-by: Vaneet Narang 

Reviewed-by: Christian König 

Alex should pick that up in his 4.2 branch.

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index edafd3c..06ac59f 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -719,7 +719,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
>   return 0;
>   
>   if (gtt && gtt->userptr) {
> - ttm->sg = kcalloc(1, sizeof(struct sg_table), GFP_KERNEL);
> + ttm->sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
>   if (!ttm->sg)
>   return -ENOMEM;
>   

[Bug 88364] Xorg hangs after videocard switching

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

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

--- Comment #12 from Liss  ---
Bug still exists in 4.1-rc8.

-- 
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/20150619/b7940df7/attachment.html>

[PATCH 1/1] drm/radeon: use kzalloc for allocating one thing

[Maninder Singh]

Use kzalloc for allocating one thing rather than
kcalloc(1...

The semantic patch that makes this change is as follows:

// 
@@
@@

- kcalloc(1,
+ kzalloc(
  ...)
// 

Signed-off-by: Maninder Singh 
Reviewed-by: Vaneet Narang 
---
 drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index edafd3c..06ac59f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -719,7 +719,7 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm)
return 0;

if (gtt && gtt->userptr) {
-   ttm->sg = kcalloc(1, sizeof(struct sg_table), GFP_KERNEL);
+   ttm->sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!ttm->sg)
return -ENOMEM;

-- 
1.7.1

[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver

[Shobhit Kumar]

Hi Paul,

On Fri, Jun 19, 2015 at 12:11 AM, Paul Bolle  wrote:
> Hi Shobhit,
>
> On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote:
>> On Fri, May 1, 2015 at 2:42 AM, Paul Bolle  wrote:
>> > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
>> >> --- a/drivers/pwm/Kconfig
>> >> +++ b/drivers/pwm/Kconfig
>> >
>> >> +config PWM_CRC
>> >> + bool "Intel Crystalcove (CRC) PWM support"
>> >> + depends on X86 && INTEL_SOC_PMIC
>> >> + help
>> >> +   Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
>> >> +   control.
>> >
>> >> --- a/drivers/pwm/Makefile
>> >> +++ b/drivers/pwm/Makefile
>> >
>> >> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
>> >
>> > PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module.
>>
>> I actually started this as a module but later decided to make it as
>> bool because INTEL_SOC_PMIC on which this depends is itself a bool as
>> well.
>
> As does GPIO_CRYSTAL_COVE and that's a tristate. So?
>
>> Still it is good to keep the module based initialization.
>> Firstly because it causes no harm
>
> If I got a dime for every time people used an argument like that I ... I
> could treat myself to an ice cream. A really big ice cream. Hmm, that
> doesn't sound too impressive. But still, "causes no harm" is below the
> bar for kernel code. Kernel code needs to add value.
>
>> and even though some of the macros
>> are pre-processed out, gives info about the driver.
>
> None of which can't be gotten elsewhere (ie, the commit message, or the
> file these macro reside in).
>

Causes no harm comment had to be read together with more info about
the driver. It causes no harm while providing more info. And as you
only said those macros are pre-processed out to really the defaults
for built-in drivers. So what is the exact big problem with this ? I
can anyway shove out these macros to end the discussion.

BTW whether you  buy the argument or not, please do treat yourself
with ice cream for being able to make such a comment.

>> Secondly there
>> were discussion on why INTEL_SOC_PMIC is bool (note this driver also
>> has module based initialization even when bool).
>
> Yes, there's copy and paste going on even in kernel development.
>

There are other examples in the kernel. I just gave the one which is
related as well.

Regards
Shobhit

>> I am guessing because
>> of some tricky module load order dependencies. If ever that becomes a
>> module, this can mostly be unchanged to be loaded as a module.
>
> You put in a macro, or any other bit of code, when it's needed, not
> beforehand, "just in case". That's silly.
>
> Thanks,
>
>
> Paul Bolle
>

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

[Mikko Rapeli]

When trying to hibernate a Lenovo T60 the half moon led keeps blinking and
devices does not power off since commit da2bc1b9db3.

T60 chip details:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GM
L Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
Subsystem: Lenovo ThinkPad R60/T60/X60 series
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Address:   Data: 
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915

Signed-off-by: Mikko Rapeli 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec4d932..36e311e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device 
*drm_dev, bool hibernation)
 * the device even though it's already in D3 and hang the machine. So
 * leave the device in D0 on those platforms and hope the BIOS will
 * power down the device properly. Platforms where this was seen:
-* Lenovo Thinkpad X301, X61s
+* Lenovo Thinkpad X301, X61s, T60
 */
if (!(hibernation &&
  drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
- INTEL_INFO(dev_priv)->gen == 4))
+ ((INTEL_INFO(dev_priv)->gen == 3) ||
+  (INTEL_INFO(dev_priv)->gen == 4)))
pci_set_power_state(drm_dev->pdev, PCI_D3hot);

return 0;
-- 
2.1.4

[PATCH] drm/exynos: do not wait for vblank at atomic operation

[Inki Dae]

This patch resolves the issue that refresh rate got low
at extension mode test with fimd and vidi combination.

The problem was because atomic_commit callback waited
for the completion of vblank to gaurantee crtc relevant
registers are updated from shadow registers to real ones.

However, the waiting there is really unnecessary because
page flip operation does already it.

Signed-off-by: Inki Dae 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 789db6f..2b6320e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -295,8 +295,6 @@ static int exynos_atomic_commit(struct drm_device *dev,

drm_atomic_helper_commit_planes(dev, state);

-   drm_atomic_helper_wait_for_vblanks(dev, state);
-
drm_atomic_helper_cleanup_planes(dev, state);

drm_atomic_state_free(state);
-- 
1.7.9.5

[PATCH v10 00/17] drm/exynos: atomic modesetting support

[Inki Dae]

On 2015년 06월 17일 23:33, Gustavo Padovan wrote:
> Hi Inki,
> 
> 2015-06-17 Inki Dae :
> 
>> Hi Gustavo,
>>
>> On 2015년 06월 17일 05:35, Gustavo Padovan wrote:
>>> HI Inki,
>>>
>>> 2015-06-15 Inki Dae :
>>>
 Hi Gustavo,

 On 2015년 06월 02일 00:04, Gustavo Padovan wrote:
> From: Gustavo Padovan 
>
> Hi,
>
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
>
> v2: fixes comments by Joonyoung
> - remove unused var in patch 09
> - use ->disable instead of outdated ->dpms in hdmi code
> - remove WARN_ON from crtc enable/disable
>
> v3: fixes comment by Joonyoung
> - move the removal of drm_helper_disable_unused_functions() to
> separated patch
>
> v4: add patches that remove unnecessary calls to disable_plane()
>
> v5: fixes NULL CRTC crash on planes updates (reported by Inki and Tobias)
>
> v6: rebase on latest exynos_drm_next
>
> v7: fix comments by Joonyoung
> - fix two checkpatch errors
> - remove extra crtc->commit() call
> - check for null fb on exynos_check_plane()
>
> v8: fix comments by Joonyoung
> - fix merge error
> - move drm_crtc_vblank_get to the commit that introduces atomic 
> pageflip
> - remove .prepare() in the apropiated patch
> - add a new patch to move exynos_drm_crtc_disable()
>
> v9:  * fix comments by Joonyoung
> - also remove encoder .prepare()
> - do not shift exynos_update_plane() parameters
> - remove unused .mode_set() and .mode_set_base()
>  * add specific exynos .atomic_commit()
>  * add split of exynos_crtc->ops->dpms() into enable() and disable()
>  * add other atomic clean ups
>
> v10: * fix comments by Joonyoung
>   - add more comments on exynos_atomic_commit()
>   - make exynos_crtc's .enable and .disable void

 I found out one issue that refresh rate gets low with display extension
 mode test.

 I tested it with two crtc drivers - vidi and fimd on Trats2 board. Here
 is how to test it,

 #echo 1 > /sys/devices/platform/exynos-drm-vidi/connection
 # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480
 setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29
 setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21
 freq: 20.00Hz
 freq: 20.00Hz

 As you can see, refresh rate is 20.

 Below is the result without atomic patch series,
 # modetest -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480
 setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29
 setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21
 freq: 60.18Hz
 freq: 49.09Hz

 I can see 60Hz for FIMD and 49Hz for vidi.
>>>
>>> I gave this a try and figured out that this might be a vidi specific
>>> problem. If I try VIDI and FIMD I get the same results as you but with
>>> Mixer and FIMD(the setup I actually use to test) everything works fine.
>>
>> Hm... Did Mixer and FIMD combination really work correctly with
>> extension mode?
> 
> Yes.
> 
> collabora at singularity:~$ modetest -M exynos -s 31:1920x1080 -v -s
> 25:1366x768
> setting mode 1920x1080-60Hz at XR24 on connectors 31, crtc 29
> setting mode 1366x768-60Hz at XR24 on connectors 25, crtc 23
> freq: 55.82Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz
> freq: 55.30Hz
> freq: 55.38Hz

Your patch series had one bug that the vblank operation was duplicated.
As you may know, the page flip operation already contains vblank
functionality but your patch made atomic_commit callback wait for the
completion of vblank again.

See the below patch I posted,
[PATCH] drm/exynos: do not wait for vblank at atomic operation

That was why I asked for that mixer and fimd combination worked
correctly with extension mode. Don't you think above frequency is
strange? The frequency should be 60Hz, not 55Hz.

We would need to enhance the atomic feature for Exynos drm later.
Current atomic feature doesn't really do atomic operation, and is
required for more cleanups. Anyway, I have already merged it and will
have a pull-request soon.

Thanks for your contributions,
Inki Dae

> 
>>
>>> So somehow my patches caused a regression on vidi that I'm still
>>> ivestigating.
>>
>> I think this issue is because page flip operations are performed in
>> atomic: if I see correctly, when page flip is requested by modetest, the
>> call flow is as follows,
>>
>> drm_atomic_helper_page_flip
>>  drm_atomic_async_commit
>>  exynos_atomic_commit
>>  ...
>>  drm_atomic_helper_wait_for_vblanks
>>  ...
>>
>> However, the function, drm_a

[PATCH] drm/atomic: Don't set crtc_state->enable manually

[Laurent Pinchart]

The enable field needs to be kept in sync with the mode_blob field. Call
drm_atomic_set_mode_prop_for_crtc() instead of setting enable to false
in order to dereference the mode blob correctly.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Another option would be to open-code the mode blob unreference in
update_output_state(). I'm not sure what's best.

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 536ae4da4665..64c75af1c088 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1554,6 +1554,8 @@ static int update_output_state(struct drm_atomic_state 
*state,
}

for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   unsigned int num_connectors;
+
/* Don't update ->enable for the CRTC in the set_config request,
 * since a mismatch would indicate a bug in the upper layers.
 * The actual modeset code later on will catch any
@@ -1561,10 +1563,12 @@ static int update_output_state(struct drm_atomic_state 
*state,
if (crtc == set->crtc)
continue;

-   crtc_state->enable =
-   drm_atomic_connectors_for_crtc(state, crtc);
-   if (!crtc_state->enable)
+   num_connectors = drm_atomic_connectors_for_crtc(state, crtc);
+   if (!num_connectors) {
+   ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
+   NULL);
crtc_state->active = false;
+   }
}

return 0;
-- 
Regards,

Laurent Pinchart

[PATCH 1/2] drm/radeon: compute ring fix hibernation (CI GPU family) v2.

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

From: Jérôme Glisse 

In order for hibernation to reliably work we need to cleanup more
thoroughly the compute ring. Hibernation is different from suspend
resume as when we resume from hibernation the hardware is first
fully initialize by regular kernel then freeze callback happens
(which correspond to a suspend inside the radeon kernel driver)
and turn off each of the block. It turns out we were not cleanly
shutting down the compute ring. This patch fix that.

Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini

Changed since v1:
  - Factor the ring stop logic into a function taking ring as arg.

Cc: stable at vger.kernel.org
Signed-off-by: Jérôme Glisse 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/cik.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ba50f3c..8de5081 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4579,6 +4579,31 @@ void cik_compute_set_wptr(struct radeon_device *rdev,
WDOORBELL32(ring->doorbell_index, ring->wptr);
 }

+static void cik_compute_stop(struct radeon_device *rdev,
+struct radeon_ring *ring)
+{
+   u32 j, tmp;
+
+   cik_srbm_select(rdev, ring->me, ring->pipe, ring->queue, 0);
+   /* Disable wptr polling. */
+   tmp = RREG32(CP_PQ_WPTR_POLL_CNTL);
+   tmp &= ~WPTR_POLL_EN;
+   WREG32(CP_PQ_WPTR_POLL_CNTL, tmp);
+   /* Disable HQD. */
+   if (RREG32(CP_HQD_ACTIVE) & 1) {
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 1);
+   for (j = 0; j < rdev->usec_timeout; j++) {
+   if (!(RREG32(CP_HQD_ACTIVE) & 1))
+   break;
+   udelay(1);
+   }
+   WREG32(CP_HQD_DEQUEUE_REQUEST, 0);
+   WREG32(CP_HQD_PQ_RPTR, 0);
+   WREG32(CP_HQD_PQ_WPTR, 0);
+   }
+   cik_srbm_select(rdev, 0, 0, 0, 0);
+}
+
 /**
  * cik_cp_compute_enable - enable/disable the compute CP MEs
  *
@@ -4592,6 +4617,15 @@ static void cik_cp_compute_enable(struct radeon_device 
*rdev, bool enable)
if (enable)
WREG32(CP_MEC_CNTL, 0);
else {
+   /*
+* To make hibernation reliable we need to clear compute ring
+* configuration before halting the compute ring.
+*/
+   mutex_lock(&rdev->srbm_mutex);
+   cik_compute_stop(rdev,&rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX]);
+   cik_compute_stop(rdev,&rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX]);
+   mutex_unlock(&rdev->srbm_mutex);
+
WREG32(CP_MEC_CNTL, (MEC_ME1_HALT | MEC_ME2_HALT));
rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX].ready = false;
rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX].ready = false;
-- 
2.1.0

[PATCH 2/2] drm/radeon: SDMA fix hibernation (CI GPU family).

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

From: Jérôme Glisse 

In order for hibernation to reliably work we need to properly turn
off the SDMA block, sadly after numerous attemps i haven't not found
proper sequence for clean and full shutdown. So simply reset both
SDMA block, this makes hibernation works reliably on sea island GPU
family (CI)

Hibernation and suspend to ram were tested (several times) on :
Bonaire
Hawaii
Mullins
Kaveri
Kabini

Cc: stable at vger.kernel.org
Signed-off-by: Jérôme Glisse 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/radeon/cik_sdma.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index f86eb54..d16f2ee 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -268,6 +268,17 @@ static void cik_sdma_gfx_stop(struct radeon_device *rdev)
}
rdev->ring[R600_RING_TYPE_DMA_INDEX].ready = false;
rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready = false;
+
+   /* FIXME use something else than big hammer but after few days can not
+* seem to find good combination so reset SDMA blocks as it seems we
+* do not shut them down properly. This fix hibernation and does not
+* affect suspend to ram.
+*/
+   WREG32(SRBM_SOFT_RESET, SOFT_RESET_SDMA | SOFT_RESET_SDMA1);
+   (void)RREG32(SRBM_SOFT_RESET);
+   udelay(50);
+   WREG32(SRBM_SOFT_RESET, 0);
+   (void)RREG32(SRBM_SOFT_RESET);
 }

 /**
-- 
2.1.0

[PATCH] drm/imx: tve: fix media bus format for VGA output

[Philipp Zabel]

Commit a7c6e76feeb1 ("drm/imx: switch to use media bus formats")
accidentally replaced IPU_PIX_FMT_GBR24 with MEDIA_BUS_FMT_YUV8_1X24
instead of the correct MEDIA_BUS_FMT_GBR888_1X24.

Signed-off-by: Philipp Zabel 
---
 drivers/gpu/drm/imx/imx-tve.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 214ecee..e671ad3 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -301,7 +301,7 @@ static void imx_tve_encoder_prepare(struct drm_encoder 
*encoder)

switch (tve->mode) {
case TVE_MODE_VGA:
-   imx_drm_set_bus_format_pins(encoder, MEDIA_BUS_FMT_YUV8_1X24,
+   imx_drm_set_bus_format_pins(encoder, MEDIA_BUS_FMT_GBR888_1X24,
tve->hsync_pin, tve->vsync_pin);
break;
case TVE_MODE_TVOUT:
-- 
2.1.4

[PATCH] MAINTAINERS: Add IPUv3 core driver to the i.MX DRM driver section

[Philipp Zabel]

The ipu-v3 core driver is maintained in and merged through
the same trees as the imx-drm drivers that are using it.
This patch adds the drivers/gpu/ipu-v3/ directory to the
i.MX DRM driver section.

Signed-off-by: Philipp Zabel 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index af802b3..9d2f612 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3402,6 +3402,7 @@ M:Philipp Zabel 
 L: dri-devel at lists.freedesktop.org
 S: Maintained
 F: drivers/gpu/drm/imx/
+F: drivers/gpu/ipu-v3/
 F: Documentation/devicetree/bindings/drm/imx/

 DRM DRIVERS FOR NVIDIA TEGRA
-- 
2.1.4

[RESEND PATCH v2 v4.1-rc8 1/2] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Daniel Thompson]

Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.

It is trivial to relax the restriction and permit read/write access.
This is safe because the flags are seldom touched by drm; mostly they
are passed verbatim to dma_buf calls.

Signed-off-by: Daniel Thompson 
---
 drivers/gpu/drm/drm_prime.c | 9 +++--
 include/uapi/drm/drm.h  | 1 +
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7fec191b45f7..6d2cf4fb4038 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -331,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * drm_gem_prime_export - helper library implementation of the export callback
  * @dev: drm_device to export from
  * @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC and DRM_RDWR
  *
  * This is the implementation of the gem_prime_export functions for GEM drivers
  * using the PRIME helpers.
@@ -639,14 +639,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
return -ENOSYS;

/* check flags are valid */
-   if (args->flags & ~DRM_CLOEXEC)
+   if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
return -EINVAL;

-   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
-   flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
-   args->handle, flags, &args->fd);
+   args->handle, args->flags, &args->fd);
 }

 int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index ff6ef62d084b..092fe3fa8ec0 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -668,6 +668,7 @@ struct drm_set_client_cap {
__u64 value;
 };

+#define DRM_RDWR O_RDWR
 #define DRM_CLOEXEC O_CLOEXEC
 struct drm_prime_handle {
__u32 handle;
-- 
2.4.3

[RESEND PATCH v2 v4.1-rc8 2/2] drm: prime: Document gem_prime_mmap

[Daniel Thompson]

gem_prime_map is not currently described in the DRM manual, lets document
it.

Signed-off-by: Daniel Thompson 
---
 drivers/gpu/drm/drm_prime.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 6d2cf4fb4038..3b40a415f45d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -309,7 +309,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * Drivers can implement @gem_prime_export and @gem_prime_import in terms of
  * simpler APIs by using the helper functions @drm_gem_prime_export and
  * @drm_gem_prime_import.  These functions implement dma-buf support in terms 
of
- * five lower-level driver callbacks:
+ * six lower-level driver callbacks:
  *
  * Export callbacks:
  *
@@ -321,6 +321,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  *
  *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
  *
+ *  - @gem_prime_mmap (optional): mmap a buffer exported by your driver
+ *
  * Import callback:
  *
  *  - @gem_prime_import_sg_table (import): produce a GEM object from another
-- 
2.4.3

[RESEND PATCH v2 v4.1-rc8 0/2] drm: prime: Allow exported dma-bufs to be mapped

[Daniel Thompson]

This patch set started out as a single patch with a trivial bit of
boilerplate to add dmabuf mmap support to the msm driver. However Rob
Clark pointed out that, rather than keep one of the tricks I had used, it
would be better to change the helpers resulting in this series.

I've tested this both with a rather hacked about Android userspace
and with a fairly small test case run from debian. Both bits of code
currently use dumb buffers.

Thanks to Benjamin Gaignard for his help in finding this bit of code and
to Damien Hobson-Garcia for pointing out that I'd forgotten (since 3.18)
to RESEND these patches.

Dave: I guess its probably too late in the dev. cycle to take this code
  but don't worry, I will try really hard to remember to RESEND it
  for 4.2. ;-)

v2:

* Modified DRM_PRIME_HANDLE_TO_FD to honour the O_RDRW from the user
  and removed code to workaround this from the sti driver (Rob Clark).

* Added a patch to (rather spartanly) document gem_prime_mmap. Only
  tacked into this series 'cos I spotted it was missing when I was
  checking whether I needed to describe DRM_RDRW anywhere.


Daniel Thompson (2):
  drm: prime: Honour O_RDWR during prime-handle-to-fd
  drm: prime: Document gem_prime_mmap

 drivers/gpu/drm/drm_prime.c | 13 ++---
 include/uapi/drm/drm.h  |  1 +
 2 files changed, 7 insertions(+), 7 deletions(-)

--
2.4.3

[PULL] drm-intel-next-fixes

[Daniel Vetter]

On Fri, Jun 19, 2015 at 01:48:13PM +1000, Dave Airlie wrote:
> On 18 June 2015 at 16:04, Jani Nikula  wrote:
> >
> > Hi Dave, i915 fixes for drm-next/v4.2.
> >
> > BR,
> > Jani.
> 
> And my gcc says:
> 
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:
> In function ‘__intel_set_mode’:
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11850:14:
> warning: ‘crtc_state’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>   return state->mode_changed || state->active_changed;
>   ^
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11860:25:
> note: ‘crtc_state’ was declared here
>   struct drm_crtc_state *crtc_state;
>  ^
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11874:6:
> warning: ‘crtc’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>if (crtc != intel_encoder->base.crtc)
>   ^
> /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:11859:19:
> note: ‘crtc’ was declared here
>   struct drm_crtc *crtc;
>^
> 
> No idea if this is true, but I don't think I've seen it before now.
> 
> gcc 5.1.1 on fedora 22

Yeah this is new with Ander's patches. gcc Doesn't know that we have at
least 1 crtc and hence crtc&crtc are guaranteed to be initiliazed. I
think you should be able to shut it up with

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e047105837c9..5ade250dc6d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11856,8 +11856,8 @@ intel_modeset_update_state(struct drm_atomic_state 
*state)
struct drm_device *dev = state->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *intel_encoder;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc = NULL;
+   struct drm_crtc_state *crtc_state = NULL;
struct drm_connector *connector;
int i;

But the entire Finland team is out of office (celebrating solstice), so
might be better to wait for Monday for them to confirm. Otherwise just
apply this fixup with my ack if you want to send out the merge window pull
asap.

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

[PATCH] drm/atomic: Extract needs_modeset function

[Daniel Vetter]

On Fri, Jun 19, 2015 at 06:08:08AM +0200, Maarten Lankhorst wrote:
> Op 18-06-15 om 11:25 schreef Daniel Vetter:
> > We use the same check already in the atomic core, so might as well
> > make this official. And it's also reused in e.g. i915.
> >
> > Motivated by Maarten's idea to extract a connector_changed state out
> > of mode_changed.
> >
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Daniel Vetter 
> >
> Reviewed-By: Maarten Lankhorst 

Thanks for the review, applied. For i915 I guess we could switch if we
want to, but perhaps only once we look into the connector_changed idea to
implement fastboot. Just to avoid needless churn.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/3]drm/msm/mdp5: Add plane blending operation support for MDP5

[Jilai Wang]

Jilai Wang (3):
  drm/doc: Add description of drm properties in msm
  drm/msm/mdp5: Update generated header files
  drm/msm/mdp5: Add plane blending operation support for MDP5

 Documentation/DocBook/drm.tmpl|  23 +++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h   |  58 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c  | 110 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c   |  66 --
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h   |  32 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  16 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 107 ++---
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h  |   4 ++
 drivers/gpu/drm/msm/msm_drv.h |  10 +++
 9 files changed, 331 insertions(+), 95 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/3] drm/doc: Add description of drm properties in msm

[Jilai Wang]

Add plane properties "premultiplied/zpos/alpha" used in msm MDP
driver to perform proper blending operation.

Signed-off-by: Jilai Wang 
---
 Documentation/DocBook/drm.tmpl | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 109fde8..9dc0940 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3500,6 +3500,29 @@ void intel_crt_init(struct drm_device *dev)
Plane
TBD

+   
+   msm
+   Generic
+   "premultiplied"
+   RANGE
+   Min=0, Max=1
+   Plane
+   property to indicate the framebuffer used by this 
plane is alpha pre-multiplied
+   
+   
+   "alpha"
+   RANGE
+   Min=0, Max=255
+   Plane
+   property to set plane's global alpha value
+   
+   
+   "zpos"
+   RANGE
+   Min=1, Max=255
+   Plane
+   property to set plane's z position during 
blending
+   


 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/3] drm/msm/mdp5: Update generated header files

[Jilai Wang]

To support mdp5 blending for mdp5 v1.5 and later

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h  | 58 ++--
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h |  4 +++
 2 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index 50e1752..d037921 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -381,49 +381,49 @@ static inline uint32_t REG_MDP5_CTL_LAYER(uint32_t i0, 
uint32_t i1) { return 0x0
 static inline uint32_t REG_MDP5_CTL_LAYER_REG(uint32_t i0, uint32_t i1) { 
return 0x + __offset_CTL(i0) + __offset_LAYER(i1); }
 #define MDP5_CTL_LAYER_REG_VIG0__MASK  0x0007
 #define MDP5_CTL_LAYER_REG_VIG0__SHIFT 0
-static inline uint32_t MDP5_CTL_LAYER_REG_VIG0(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_VIG0(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_VIG0__SHIFT) & 
MDP5_CTL_LAYER_REG_VIG0__MASK;
 }
 #define MDP5_CTL_LAYER_REG_VIG1__MASK  0x0038
 #define MDP5_CTL_LAYER_REG_VIG1__SHIFT 3
-static inline uint32_t MDP5_CTL_LAYER_REG_VIG1(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_VIG1(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_VIG1__SHIFT) & 
MDP5_CTL_LAYER_REG_VIG1__MASK;
 }
 #define MDP5_CTL_LAYER_REG_VIG2__MASK  0x01c0
 #define MDP5_CTL_LAYER_REG_VIG2__SHIFT 6
-static inline uint32_t MDP5_CTL_LAYER_REG_VIG2(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_VIG2(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_VIG2__SHIFT) & 
MDP5_CTL_LAYER_REG_VIG2__MASK;
 }
 #define MDP5_CTL_LAYER_REG_RGB0__MASK  0x0e00
 #define MDP5_CTL_LAYER_REG_RGB0__SHIFT 9
-static inline uint32_t MDP5_CTL_LAYER_REG_RGB0(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_RGB0(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_RGB0__SHIFT) & 
MDP5_CTL_LAYER_REG_RGB0__MASK;
 }
 #define MDP5_CTL_LAYER_REG_RGB1__MASK  0x7000
 #define MDP5_CTL_LAYER_REG_RGB1__SHIFT 12
-static inline uint32_t MDP5_CTL_LAYER_REG_RGB1(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_RGB1(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_RGB1__SHIFT) & 
MDP5_CTL_LAYER_REG_RGB1__MASK;
 }
 #define MDP5_CTL_LAYER_REG_RGB2__MASK  0x00038000
 #define MDP5_CTL_LAYER_REG_RGB2__SHIFT 15
-static inline uint32_t MDP5_CTL_LAYER_REG_RGB2(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_RGB2(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_RGB2__SHIFT) & 
MDP5_CTL_LAYER_REG_RGB2__MASK;
 }
 #define MDP5_CTL_LAYER_REG_DMA0__MASK  0x001c
 #define MDP5_CTL_LAYER_REG_DMA0__SHIFT 18
-static inline uint32_t MDP5_CTL_LAYER_REG_DMA0(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_DMA0(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_DMA0__SHIFT) & 
MDP5_CTL_LAYER_REG_DMA0__MASK;
 }
 #define MDP5_CTL_LAYER_REG_DMA1__MASK  0x00e0
 #define MDP5_CTL_LAYER_REG_DMA1__SHIFT 21
-static inline uint32_t MDP5_CTL_LAYER_REG_DMA1(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_DMA1(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_DMA1__SHIFT) & 
MDP5_CTL_LAYER_REG_DMA1__MASK;
 }
@@ -431,13 +431,13 @@ static inline uint32_t MDP5_CTL_LAYER_REG_DMA1(enum 
mdp_mixer_stage_id val)
 #define MDP5_CTL_LAYER_REG_CURSOR_OUT  0x0200
 #define MDP5_CTL_LAYER_REG_VIG3__MASK  0x1c00
 #define MDP5_CTL_LAYER_REG_VIG3__SHIFT 26
-static inline uint32_t MDP5_CTL_LAYER_REG_VIG3(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_VIG3(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_VIG3__SHIFT) & 
MDP5_CTL_LAYER_REG_VIG3__MASK;
 }
 #define MDP5_CTL_LAYER_REG_RGB3__MASK  0xe000
 #define MDP5_CTL_LAYER_REG_RGB3__SHIFT 29
-static inline uint32_t MDP5_CTL_LAYER_REG_RGB3(enum mdp_mixer_stage_id val)
+static inline uint32_t MDP5_CTL_LAYER_REG_RGB3(uint32_t val)
 {
return ((val) << MDP5_CTL_LAYER_REG_RGB3__SHIFT) & 
MDP5_CTL_LAYER_REG_RGB3__MASK;
 }
@@ -499,6 +499,44 @@ static inline uint32_t REG_MDP5_CTL_START(uint32_t i0) { 
return 0x001c + __o

 static inline uint32_t REG_MDP5_CTL_PACK_3D(uint32_t i0) { return 0x0020 + 
__offset_CTL(i0); }

+static inline uint32_t __offset_LAYER_EXT(uint32_t idx)
+{
+   switch (idx) {
+   case 0: return 0x000

[PATCH 3/3] drm/msm/mdp5: Add plane blending operation support for MDP5

[Jilai Wang]

This change is to add properties alpha/zpos/premultiplied to mdp5 plane
for alpha blending operation to generate the blended output.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c  | 110 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c   |  66 --
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h   |  32 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  16 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 107 ++---
 drivers/gpu/drm/msm/msm_drv.h |  10 +++
 6 files changed, 256 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index dea3d2e..e6e53b8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -160,7 +160,7 @@ static void complete_flip(struct drm_crtc *crtc, struct 
drm_file *file)

if (mdp5_crtc->ctl && !crtc->state->enable) {
/* set STAGE_UNUSED for all layers */
-   mdp5_ctl_blend(mdp5_crtc->ctl, mdp5_crtc->lm, 0x);
+   mdp5_ctl_blend(mdp5_crtc->ctl, mdp5_crtc->lm, NULL, 0, 0);
mdp5_ctl_release(mdp5_crtc->ctl);
mdp5_crtc->ctl = NULL;
}
@@ -196,13 +196,9 @@ static bool mdp5_crtc_mode_fixup(struct drm_crtc *crtc,
 /*
  * blend_setup() - blend all the planes of a CRTC
  *
- * When border is enabled, the border color will ALWAYS be the base layer.
- * Therefore, the first plane (private RGB pipe) will start at STAGE0.
- * If disabled, the first plane starts at STAGE_BASE.
- *
- * Note:
- * Border is not enabled here because the private plane is exactly
- * the CRTC resolution.
+ * If no base layer is available, border will be enabled as the base layer.
+ * Otherwise all layers will be blended based on their stage calculated
+ * in mdp5_crtc_atomic_check.
  */
 static void blend_setup(struct drm_crtc *crtc)
 {
@@ -210,9 +206,14 @@ static void blend_setup(struct drm_crtc *crtc)
struct mdp5_kms *mdp5_kms = get_kms(crtc);
struct drm_plane *plane;
const struct mdp5_cfg_hw *hw_cfg;
-   uint32_t lm = mdp5_crtc->lm, blend_cfg = 0;
+   struct mdp5_plane_state *pstate, *pstates[STAGE_MAX + 1] = {NULL};
+   const struct mdp_format *format;
+   uint32_t lm = mdp5_crtc->lm;
+   uint32_t blend_op, fg_alpha, bg_alpha, ctl_blend_flags = 0;
unsigned long flags;
-#define blender(stage) ((stage) - STAGE_BASE)
+   uint8_t stage[STAGE_MAX + 1];
+   int i, plane_cnt = 0;
+#define blender(stage) ((stage) - STAGE0)

hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);

@@ -222,33 +223,73 @@ static void blend_setup(struct drm_crtc *crtc)
if (!mdp5_crtc->ctl)
goto out;

+   /* Collect all plane information */
drm_atomic_crtc_for_each_plane(plane, crtc) {
-   enum mdp_mixer_stage_id stage =
-   to_mdp5_plane_state(plane->state)->stage;
+   pstate = to_mdp5_plane_state(plane->state);
+   pstates[pstate->stage] = pstate;
+   stage[pstate->stage] = mdp5_plane_pipe(plane);
+   plane_cnt++;
+   }

-   /*
-* Note: This cannot happen with current implementation but
-* we need to check this condition once z property is added
-*/
-   BUG_ON(stage > hw_cfg->lm.nb_stages);
+   /*
+   * If there is no base layer, enable border color.
+   * Although it's not possbile in current blend logic,
+   * put it here as a reminder.
+   */
+   if (!pstates[STAGE_BASE] && plane_cnt) {
+   ctl_blend_flags |= MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT;
+   DBG("Border Color is enabled");
+   }

-   /* LM */
-   mdp5_write(mdp5_kms,
-   REG_MDP5_LM_BLEND_OP_MODE(lm, blender(stage)),
-   MDP5_LM_BLEND_OP_MODE_FG_ALPHA(FG_CONST) |
-   MDP5_LM_BLEND_OP_MODE_BG_ALPHA(BG_CONST));
+   /* The reset for blending */
+   for (i = STAGE0; i <= STAGE_MAX; i++) {
+   if (!pstates[i])
+   continue;
+
+   format = to_mdp_format(
+   msm_framebuffer_format(pstates[i]->base.fb));
+   plane = pstates[i]->base.plane;
+   blend_op = MDP5_LM_BLEND_OP_MODE_FG_ALPHA(FG_CONST) |
+   MDP5_LM_BLEND_OP_MODE_BG_ALPHA(BG_CONST);
+   fg_alpha = pstates[i]->alpha;
+   bg_alpha = 0xFF - pstates[i]->alpha;
+   DBG("Stage %d fg_alpha %x bg_alpha %x", i, fg_alpha, bg_alpha);
+
+   if (format->alpha_enable && pstates[i]->premultiplied) {
+   blend_op = MDP5_LM_BLEND_OP_MODE_FG_ALPHA(FG_CONST) |
+   MDP5_LM_BLEND_OP_MODE_BG_ALPHA(FG_PIXEL);
+  

[PATCH] rnndb: Increase stage number for MDP1.5

[Jilai Wang]

MDP1.5 can support 7 stages. Update xml file accordingly.

Signed-off-by: Jilai Wang 
---
 rnndb/mdp/mdp5.xml   | 36 ++--
 rnndb/mdp/mdp_common.xml |  4 
 2 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml
index 6e92e54..c9aa10c 100644
--- a/rnndb/mdp/mdp5.xml
+++ b/rnndb/mdp/mdp5.xml
@@ -212,18 +212,18 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
-   
-   
-   
-   
-   
-   
-   
+   
+   
+   
+   
+   
+   
+   
+   


-   
-   
+   
+   



@@ -266,6 +266,22 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   



diff --git a/rnndb/mdp/mdp_common.xml b/rnndb/mdp/mdp_common.xml
index b4d1949..f666d1a 100644
--- a/rnndb/mdp/mdp_common.xml
+++ b/rnndb/mdp/mdp_common.xml
@@ -26,6 +26,10 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">
   
   
   
+  
+  
+  
+
 

 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm/dp: look up the mstb passed into work function

[Daniel Vetter]

On Fri, Jun 19, 2015 at 10:53:10AM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> We should validate the passed in mstb under the lock
> this should stop us getting an invalid mstb here.
> 
> (first attempt with cancelling work has lockdep issues).

Yeah cancel_work_sync is nasty that way ;-)

Btw random bikeshed, but mgr->work would look nice as mgr->probe_work.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89366
Bugzilla: https://bugs.archlinux.org/task/45369

seems the more accurate one, the fdo one is a mess.
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index fb65f5d..ad0d1bf 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1198,9 +1198,14 @@ static struct drm_dp_mst_branch 
> *drm_dp_get_mst_branch_device(struct drm_dp_mst_
>  }
>  
>  static void drm_dp_check_and_send_link_address(struct 
> drm_dp_mst_topology_mgr *mgr,
> -struct drm_dp_mst_branch *mstb)
> +struct drm_dp_mst_branch 
> *mstb_in)
>  {
>   struct drm_dp_mst_port *port;
> + struct drm_dp_mst_branch *mstb;
> +
> + mstb = drm_dp_get_validated_mstb_ref(mgr, mstb_in);
> + if (!mstb)
> + return;
>  
>   if (!mstb->link_address_sent) {
>   drm_dp_send_link_address(mgr, mstb);
> @@ -1219,6 +1224,7 @@ static void drm_dp_check_and_send_link_address(struct 
> drm_dp_mst_topology_mgr *m
>   if (port->mstb)
>   drm_dp_check_and_send_link_address(mgr, port->mstb);
>   }
> + drm_dp_put_mst_branch_device(mstb);
>  }

I am a bit concerned about the lifetime rules of the mgr->mst_primary
pointer. port->mstb is controlled by the lifetime of the port and that by
the parent mst branch, so I think we're covered dereferencing that one.

But mgr->mst_primary seems to be protected only by mgr->lock, and you're
not holding that in the probe work. I did review
drm_dp_mst_topology_mgr_set_mst and that does seem to clean up
->mst_primary correctly but might be helped with a comment. But we do need
the locking I think.

Assuming the added locking doesn't piss off lockdep this is
Reviewed-by: Daniel Vetter 
-Daniel
---
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 132581ca4ad8..08c3c65e7d08 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1213,7 +1213,9 @@ static void drm_dp_mst_link_probe_work(struct work_struct 
*work)
 {
struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct 
drm_dp_mst_topology_mgr, work);

+   mutex_lock(&mgr->lock);
drm_dp_check_and_send_link_address(mgr, mgr->mst_primary);
+   mutex_unlock(&mgr->lock);

 }

@@ -1921,6 +1923,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
} else {
/* disable MST on the device */
mstb = mgr->mst_primary;
+   /* inherit reference from ->mst_primary, will be cleaned up
+* at the end. */
mgr->mst_primary = NULL;
/* this can fail if the device is gone */
drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0);
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

[Daniel Vetter]

On Fri, Jun 19, 2015 at 08:17:55AM +0200, Mikko Rapeli wrote:
> When trying to hibernate a Lenovo T60 the half moon led keeps blinking and
> devices does not power off since commit da2bc1b9db3.
> 
> T60 chip details:
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
> 943/940GM
> L Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA 
> controller])
> Subsystem: Lenovo ThinkPad R60/T60/X60 series
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Step
> ping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
>  SERR-  Latency: 0
> Interrupt: pin A routed to IRQ 16
> Region 0: Memory at ee10 (32-bit, non-prefetchable) [size=512K]
> Region 1: I/O ports at 1800 [size=8]
> Region 2: Memory at d000 (32-bit, prefetchable) [size=256M]
> Region 3: Memory at ee20 (32-bit, non-prefetchable) [size=256K]
> Expansion ROM at  [disabled]
> Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
> Address:   Data: 
> Capabilities: [d0] Power Management version 2
> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: i915
> 
> Signed-off-by: Mikko Rapeli 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ec4d932..36e311e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device 
> *drm_dev, bool hibernation)
>* the device even though it's already in D3 and hang the machine. So
>* leave the device in D0 on those platforms and hope the BIOS will
>* power down the device properly. Platforms where this was seen:
> -  * Lenovo Thinkpad X301, X61s
> +  * Lenovo Thinkpad X301, X61s, T60
>*/
>   if (!(hibernation &&
> drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> -   INTEL_INFO(dev_priv)->gen == 4))
> +   ((INTEL_INFO(dev_priv)->gen == 3) ||
> +(INTEL_INFO(dev_priv)->gen == 4)))

I wonder whether we shouldn't do this unconditionally for gen4 and earlier
for Lenovo ... Anyway this needs Cc: stable at vger.kernel.org and is for
Jani to pick up.

Thanks for figuring out what's been broken here.
-Daniel

>   pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>  
>   return 0;
> -- 
> 2.1.4
> 
> ___
> 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

[RESEND PATCH v2 v4.1-rc8 0/2] drm: prime: Allow exported dma-bufs to be mapped

[Daniel Vetter]

On Fri, Jun 19, 2015 at 02:52:27PM +0100, Daniel Thompson wrote:
> This patch set started out as a single patch with a trivial bit of
> boilerplate to add dmabuf mmap support to the msm driver. However Rob
> Clark pointed out that, rather than keep one of the tricks I had used, it
> would be better to change the helpers resulting in this series.
> 
> I've tested this both with a rather hacked about Android userspace
> and with a fairly small test case run from debian. Both bits of code
> currently use dumb buffers.
> 
> Thanks to Benjamin Gaignard for his help in finding this bit of code and
> to Damien Hobson-Garcia for pointing out that I'd forgotten (since 3.18)
> to RESEND these patches.
> 
> Dave: I guess its probably too late in the dev. cycle to take this code
>   but don't worry, I will try really hard to remember to RESEND it
>   for 4.2. ;-)
> 
> v2:
> 
> * Modified DRM_PRIME_HANDLE_TO_FD to honour the O_RDRW from the user
>   and removed code to workaround this from the sti driver (Rob Clark).
> 
> * Added a patch to (rather spartanly) document gem_prime_mmap. Only
>   tacked into this series 'cos I spotted it was missing when I was
>   checking whether I needed to describe DRM_RDRW anywhere.

Oh hornets nest since I just screamed around again against drm prime mmap
support ;-) Imo before we expose this for real we really need to somehow
figure out what to do about cache coherency. Some intel folks are looking
into adding suitable ioctls to the dma-buf fd to make this possible. I
think we should wait with enabling drm prime mmaping before that's
resolved somehow. I'll point them at your patches though to make sure they
don't reinvent this wheel here.
-Daniel

> 
> 
> Daniel Thompson (2):
>   drm: prime: Honour O_RDWR during prime-handle-to-fd
>   drm: prime: Document gem_prime_mmap
> 
>  drivers/gpu/drm/drm_prime.c | 13 ++---
>  include/uapi/drm/drm.h  |  1 +
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> --
> 2.4.3
> 
> ___
> 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

[RESEND PATCH v2 v4.1-rc8 1/2] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Daniel Vetter]

On Fri, Jun 19, 2015 at 02:52:28PM +0100, Daniel Thompson wrote:
> Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
> (DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
> to mmap() the resulting dma-buf even when this is supported by the
> DRM driver.
> 
> It is trivial to relax the restriction and permit read/write access.
> This is safe because the flags are seldom touched by drm; mostly they
> are passed verbatim to dma_buf calls.
> 
> Signed-off-by: Daniel Thompson 
> ---
>  drivers/gpu/drm/drm_prime.c | 9 +++--
>  include/uapi/drm/drm.h  | 1 +
>  2 files changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7fec191b45f7..6d2cf4fb4038 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -331,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   * drm_gem_prime_export - helper library implementation of the export 
> callback
>   * @dev: drm_device to export from
>   * @obj: GEM object to export
> - * @flags: flags like DRM_CLOEXEC
> + * @flags: flags like DRM_CLOEXEC and DRM_RDWR
>   *
>   * This is the implementation of the gem_prime_export functions for GEM 
> drivers
>   * using the PRIME helpers.
> @@ -639,14 +639,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device 
> *dev, void *data,
>   return -ENOSYS;
>  
>   /* check flags are valid */
> - if (args->flags & ~DRM_CLOEXEC)
> + if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
>   return -EINVAL;

I think we should reject DRM_RDWR if there's no mmap implementation in the
underlying dma-buf vfunc table. Or in the gem version of those. Otherwise
looks ok to me, if we first resolve the dma-buf userspace mmap coherency
issue.
-Daniel

>  
> - /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
> - flags = args->flags & DRM_CLOEXEC;
> -
>   return dev->driver->prime_handle_to_fd(dev, file_priv,
> - args->handle, flags, &args->fd);
> + args->handle, args->flags, &args->fd);
>  }
>  
>  int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index ff6ef62d084b..092fe3fa8ec0 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -668,6 +668,7 @@ struct drm_set_client_cap {
>   __u64 value;
>  };
>  
> +#define DRM_RDWR O_RDWR
>  #define DRM_CLOEXEC O_CLOEXEC
>  struct drm_prime_handle {
>   __u32 handle;
> -- 
> 2.4.3
> 
> ___
> 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

[RESEND PATCH v2 v4.1-rc8 2/2] drm: prime: Document gem_prime_mmap

[Daniel Vetter]

On Fri, Jun 19, 2015 at 02:52:29PM +0100, Daniel Thompson wrote:
> gem_prime_map is not currently described in the DRM manual, lets document
> it.
> 
> Signed-off-by: Daniel Thompson 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_prime.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 6d2cf4fb4038..3b40a415f45d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -309,7 +309,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   * Drivers can implement @gem_prime_export and @gem_prime_import in terms of
>   * simpler APIs by using the helper functions @drm_gem_prime_export and
>   * @drm_gem_prime_import.  These functions implement dma-buf support in 
> terms of
> - * five lower-level driver callbacks:
> + * six lower-level driver callbacks:
>   *
>   * Export callbacks:
>   *
> @@ -321,6 +321,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   *
>   *  - @gem_prime_vunmap: vunmap a buffer exported by your driver
>   *
> + *  - @gem_prime_mmap (optional): mmap a buffer exported by your driver
> + *
>   * Import callback:
>   *
>   *  - @gem_prime_import_sg_table (import): produce a GEM object from another
> -- 
> 2.4.3
> 
> ___
> 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] drm/atomic: Don't set crtc_state->enable manually

[Daniel Vetter]

On Fri, Jun 19, 2015 at 04:41:55PM +0300, Laurent Pinchart wrote:
> The enable field needs to be kept in sync with the mode_blob field. Call
> drm_atomic_set_mode_prop_for_crtc() instead of setting enable to false
> in order to dereference the mode blob correctly.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> Another option would be to open-code the mode blob unreference in
> update_output_state(). I'm not sure what's best.
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 536ae4da4665..64c75af1c088 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1554,6 +1554,8 @@ static int update_output_state(struct drm_atomic_state 
> *state,
>   }
>  
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + unsigned int num_connectors;
> +
>   /* Don't update ->enable for the CRTC in the set_config request,
>* since a mismatch would indicate a bug in the upper layers.
>* The actual modeset code later on will catch any
> @@ -1561,10 +1563,12 @@ static int update_output_state(struct 
> drm_atomic_state *state,
>   if (crtc == set->crtc)
>   continue;
>  
> - crtc_state->enable =
> - drm_atomic_connectors_for_crtc(state, crtc);
> - if (!crtc_state->enable)
> + num_connectors = drm_atomic_connectors_for_crtc(state, crtc);
> + if (!num_connectors) {
> + ret = drm_atomic_set_mode_prop_for_crtc(crtc_state,
> + NULL);

ret seems lost here because of the return 0; below.
-Daniel

>   crtc_state->active = false;
> + }
>   }
>  
>   return 0;
> -- 
> Regards,
> 
> Laurent Pinchart
> 

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

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

[Paul Bolle]

On Fri, 2015-06-19 at 17:44 +0200, Daniel Vetter wrote:
> I wonder whether we shouldn't do this unconditionally for gen4 and earlier
> for Lenovo ... Anyway this needs Cc: stable at vger.kernel.org and is for
> Jani to pick up.
> 
> Thanks for figuring out what's been broken here.
> -Daniel
> 
> > pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> >  
> > return 0;

Just two days ago we discussed this bug too, see
https://lkml.org/lkml/2015/6/17/327 . That message contains a link to a
patch I cobbled together for yet another ThinkPad hitting this, but with
PCI_SUBVENDOR_ID_IBM involved.


Paul Bolle

[PATCH v5 1/6] drm: bridge/dw_hdmi: add audio support for more display resolutions

[Russell King - ARM Linux]

On Sat, Jun 20, 2015 at 12:19:12AM +0800, Yakir Yang wrote:
> Just like HDMISpecification 1.4 document descripted, the soure shall
> determine the fractional relationship between the TMDS clock an an
> audio reference clock, the sink may then recreate the audio clock from
> the TMDS clock by using an clock divider. So if we can make sink generate
> the correct samplerate, then we can say those display resolutions with
> this pixelclock could support audio play.
> 
> The exact relationship between the two clocks will be:
>   128 * SampleRate = TmdsClock * N / CTS.
> So this patch would generate the correct N/CTS values, add audio support
> for the below  tmds clocks:
> 25.175MHz, 40MHz, 54MHz, 65MHz, 74.25MHz, 83.5MHz, 106.5MHz, 108Mhz

I think I've said this before.  The documentation for iMX6 (which is
freely available, unlike Rock-chips documentation, so you can look at
it yourself) specifies that only certain audio and video rates are
supported.  See the iMX6 manuals, the section on the HDMI Tx, sub-
section "CTS calculation".

It clearly states that values which do not appear in the table there
are "not supported".

Adding more rates to this code puts iMX6 outside of its specification.

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

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

[mikko.rap...@iki.fi]

On Fri Jun 19 17:44:31 2015 GMT+0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2015 at 08:17:55AM +0200, Mikko Rapeli wrote:
> > When trying to hibernate a Lenovo T60 the half moon led keeps blinking and
> > devices does not power off since commit da2bc1b9db3.
> > 
> > T60 chip details:
> > 
> > 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
> > 943/940GM
> > L Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA 
> > controller])
> > Subsystem: Lenovo ThinkPad R60/T60/X60 series
> > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> > Step
> > ping- SERR- FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- 
> >  > SERR-  > Latency: 0
> > Interrupt: pin A routed to IRQ 16
> > Region 0: Memory at ee10 (32-bit, non-prefetchable) [size=512K]
> > Region 1: I/O ports at 1800 [size=8]
> > Region 2: Memory at d000 (32-bit, prefetchable) [size=256M]
> > Region 3: Memory at ee20 (32-bit, non-prefetchable) [size=256K]
> > Expansion ROM at  [disabled]
> > Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
> > Address:   Data: 
> > Capabilities: [d0] Power Management version 2
> > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
> > PME(D0-,D1-,D2-,D3hot-,D3cold-)
> > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> > Kernel driver in use: i915
> > 
> > Signed-off-by: Mikko Rapeli 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index ec4d932..36e311e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device 
> > *drm_dev, bool hibernation)
> >  * the device even though it's already in D3 and hang the machine. So
> >  * leave the device in D0 on those platforms and hope the BIOS will
> >  * power down the device properly. Platforms where this was seen:
> > -* Lenovo Thinkpad X301, X61s
> > +* Lenovo Thinkpad X301, X61s, T60
> >  */
> > if (!(hibernation &&
> >   drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> > - INTEL_INFO(dev_priv)->gen == 4))
> > + ((INTEL_INFO(dev_priv)->gen == 3) ||
> > +  (INTEL_INFO(dev_priv)->gen == 4)))
> 
> I wonder whether we shouldn't do this unconditionally for gen4 and earlier
> for Lenovo ... Anyway this needs Cc: stable at vger.kernel.org and is for
> Jani to pick up.


Yes, I also tought about enabling this for all older Lenovo devices but I don't 
know the hardware or chips and can't test so I let it be. Also reverting the 
original bug causing patch could be an option since this is affecting so many 
devices and users.

> Thanks for figuring out what's been broken here.

You're welcome.

-Mikko

> -Daniel
> 
> > pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> >  
> > return 0;
> > -- 
> > 2.1.4
> > 
> > ___
> > 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
>

-- 
Sent from my Jolla

[PATCH] drm/msm/mdp5: release SMB(shared memory blocks) in various cases

[Wentao Xu]

Release all blocks after the pipe is disabled, even when vsync
didn't happen in some error cases. Allow requesting SMB multiple
times before configuring to hardware, by releasing blocks not
programmed to hardware yet for shrinking case.

Signed-off-by: Wentao Xu 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 13 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 33 +---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c   | 87 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.h   |  1 +
 5 files changed, 104 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 97226a1..db49ee8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -78,7 +78,20 @@ static void mdp5_prepare_commit(struct msm_kms *kms, struct 
drm_atomic_state *st

 static void mdp5_complete_commit(struct msm_kms *kms, struct drm_atomic_state 
*state)
 {
+   int i;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+   int nplanes = mdp5_kms->dev->mode_config.num_total_plane;
+
+   for (i = 0; i < nplanes; i++) {
+   struct drm_plane *plane = state->planes[i];
+   struct drm_plane_state *plane_state = state->plane_states[i];
+
+   if (!plane)
+   continue;
+
+   mdp5_plane_complete_commit(plane, plane_state);
+   }
+
mdp5_disable(mdp5_kms);
 }

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 2c0de17..42f270b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -227,6 +227,8 @@ void mdp5_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);
 uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
 void mdp5_plane_complete_flip(struct drm_plane *plane);
+void mdp5_plane_complete_commit(struct drm_plane *plane,
+   struct drm_plane_state *state);
 enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
 struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 18a3d20..05b2634 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -31,8 +31,6 @@ struct mdp5_plane {

uint32_t nformats;
uint32_t formats[32];
-
-   bool enabled;
 };
 #define to_mdp5_plane(x) container_of(x, struct mdp5_plane, base)

@@ -56,22 +54,6 @@ static bool plane_enabled(struct drm_plane_state *state)
return state->fb && state->crtc;
 }

-static int mdp5_plane_disable(struct drm_plane *plane)
-{
-   struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
-   struct mdp5_kms *mdp5_kms = get_kms(plane);
-   enum mdp5_pipe pipe = mdp5_plane->pipe;
-
-   DBG("%s: disable", mdp5_plane->name);
-
-   if (mdp5_kms) {
-   /* Release the memory we requested earlier from the SMP: */
-   mdp5_smp_release(mdp5_kms->smp, pipe);
-   }
-
-   return 0;
-}
-
 static void mdp5_plane_destroy(struct drm_plane *plane)
 {
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
@@ -224,7 +206,6 @@ static void mdp5_plane_atomic_update(struct drm_plane 
*plane,

if (!plane_enabled(state)) {
to_mdp5_plane_state(state)->pending = true;
-   mdp5_plane_disable(plane);
} else if (to_mdp5_plane_state(state)->mode_changed) {
int ret;
to_mdp5_plane_state(state)->pending = true;
@@ -602,6 +583,20 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
return mdp5_plane->flush_mask;
 }

+/* called after vsync in thread context */
+void mdp5_plane_complete_commit(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   struct mdp5_kms *mdp5_kms = get_kms(plane);
+   struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
+   enum mdp5_pipe pipe = mdp5_plane->pipe;
+
+   if (!plane_enabled(plane->state)) {
+   DBG("%s: free SMP", mdp5_plane->name);
+   mdp5_smp_release(mdp5_kms->smp, pipe);
+   }
+}
+
 /* initialize plane */
 struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane, uint32_t reg_offset)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
index 16702ae..64a27d8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
@@ -34,22 +34,44 @@
  * and CANNOT be re-allocated (eg: MMB0 and MMB1 both tied to RGB0).
  *
  * For each block that can be dynamically allocated, it can be either
- * free, or pending/in-use by a client. The updates happen in three steps:
+ * 

[PATCH 0/2] drm/msm: HDMI PHY rework for MSM8x94 support

[Stephane Viau]

This it to follow up with my RFC sent a few days ago[1].

Since the RFC got discussed and approved through IRC, here are the actual
patches.

Rgds,
Stephane.

[1] http://lists.freedesktop.org/archives/dri-devel/2015-June/084788.html

Stephane Viau (2):
  drm/msm/hdmi: remove ->reset() from HDMI PHY
  drm/msm: Add support for msm8x94

 drivers/gpu/drm/msm/hdmi/hdmi.c   | 30 ++
 drivers/gpu/drm/msm/hdmi/hdmi.h   |  1 -
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|  8 ++-
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 94 +--
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c  | 52 -
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c  | 32 ---
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c  | 57 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c   | 73 +++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  8 ++-
 9 files changed, 179 insertions(+), 176 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

[PATCH 1/2] drm/msm/hdmi: remove ->reset() from HDMI PHY

[Stephane Viau]

->reset() currently only accesses HDMI core registers, and yet it
is located in hdmi_phy*. Since no PHY registers are being
accessed during ->reset(), it would be better to bring that
function in hdmi core module where HDMI core registers are
usually being accessed.

This will also help for msm8x94 for which no PHY registers
accesses are done (->phy_init == NULL) but the HDMI PHY reset
from HDMI core still needs to be done.

Note:
SW_RESET_PLL bit is not written in hdmi_phy_8x60_reset(); this
write should not affect anything if the corresponding field is
not writable.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/hdmi/hdmi.h   |  1 -
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 51 ++-
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c  | 52 
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c  | 32 -
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x74.c  | 57 ---
 5 files changed, 50 insertions(+), 143 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 68fdfb3..a155c4a 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -117,7 +117,6 @@ static inline u32 hdmi_read(struct hdmi *hdmi, u32 reg)

 struct hdmi_phy_funcs {
void (*destroy)(struct hdmi_phy *phy);
-   void (*reset)(struct hdmi_phy *phy);
void (*powerup)(struct hdmi_phy *phy, unsigned long int pixclock);
void (*powerdown)(struct hdmi_phy *phy);
 };
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index a1650f4..ece572d 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -28,6 +28,55 @@ struct hdmi_connector {
 };
 #define to_hdmi_connector(x) container_of(x, struct hdmi_connector, base)

+static void hdmi_phy_reset(struct hdmi *hdmi)
+{
+   unsigned int val;
+
+   val = hdmi_read(hdmi, REG_HDMI_PHY_CTRL);
+
+   if (val & HDMI_PHY_CTRL_SW_RESET_LOW) {
+   /* pull low */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val & ~HDMI_PHY_CTRL_SW_RESET);
+   } else {
+   /* pull high */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val | HDMI_PHY_CTRL_SW_RESET);
+   }
+
+   if (val & HDMI_PHY_CTRL_SW_RESET_PLL_LOW) {
+   /* pull low */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val & ~HDMI_PHY_CTRL_SW_RESET_PLL);
+   } else {
+   /* pull high */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val | HDMI_PHY_CTRL_SW_RESET_PLL);
+   }
+
+   msleep(100);
+
+   if (val & HDMI_PHY_CTRL_SW_RESET_LOW) {
+   /* pull high */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val | HDMI_PHY_CTRL_SW_RESET);
+   } else {
+   /* pull low */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val & ~HDMI_PHY_CTRL_SW_RESET);
+   }
+
+   if (val & HDMI_PHY_CTRL_SW_RESET_PLL_LOW) {
+   /* pull high */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val | HDMI_PHY_CTRL_SW_RESET_PLL);
+   } else {
+   /* pull low */
+   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
+   val & ~HDMI_PHY_CTRL_SW_RESET_PLL);
+   }
+}
+
 static int gpio_config(struct hdmi *hdmi, bool on)
 {
struct device *dev = &hdmi->pdev->dev;
@@ -181,7 +230,7 @@ static int hpd_enable(struct hdmi_connector *hdmi_connector)
}

hdmi_set_mode(hdmi, false);
-   phy->funcs->reset(phy);
+   hdmi_phy_reset(hdmi);
hdmi_set_mode(hdmi, true);

hdmi_write(hdmi, REG_HDMI_USEC_REFTIMER, 0x0001001b);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
index 6997ec6..3a01cb5 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
@@ -426,57 +426,6 @@ static void hdmi_phy_8960_destroy(struct hdmi_phy *phy)
kfree(phy_8960);
 }

-static void hdmi_phy_8960_reset(struct hdmi_phy *phy)
-{
-   struct hdmi_phy_8960 *phy_8960 = to_hdmi_phy_8960(phy);
-   struct hdmi *hdmi = phy_8960->hdmi;
-   unsigned int val;
-
-   val = hdmi_read(hdmi, REG_HDMI_PHY_CTRL);
-
-   if (val & HDMI_PHY_CTRL_SW_RESET_LOW) {
-   /* pull low */
-   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
-   val & ~HDMI_PHY_CTRL_SW_RESET);
-   } else {
-   /* pull high */
-   hdmi_write(hdmi, REG_HDMI_PHY_CTRL,
-   val | HDMI_PHY_CTRL_SW_RESET);
-   }
-
-   if (val & HDMI_PHY_CTRL_SW_RESET_PLL_LOW) {
-   /* pull low */
-   hdmi_write(hdmi, REG_HDMI_PHY_CT

[PATCH 2/2] drm/msm: Add support for msm8x94

[Stephane Viau]

This change adds the MDP and HDMI support for msm8x94.
Note that HDMI PHY registers are not being accessed anymore from
the driver.

Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c   | 30 -
 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c|  8 +++-
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 43 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c   | 73 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  8 ++--
 5 files changed, 129 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 8145362..4d73a69 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -89,16 +89,15 @@ static struct hdmi *hdmi_init(struct platform_device *pdev)
hdmi->config = config;

/* not sure about which phy maps to which msm.. probably I miss some */
-   if (config->phy_init)
+   if (config->phy_init) {
hdmi->phy = config->phy_init(hdmi);
-   else
-   hdmi->phy = ERR_PTR(-ENXIO);

-   if (IS_ERR(hdmi->phy)) {
-   ret = PTR_ERR(hdmi->phy);
-   dev_err(&pdev->dev, "failed to load phy: %d\n", ret);
-   hdmi->phy = NULL;
-   goto fail;
+   if (IS_ERR(hdmi->phy)) {
+   ret = PTR_ERR(hdmi->phy);
+   dev_err(&pdev->dev, "failed to load phy: %d\n", ret);
+   hdmi->phy = NULL;
+   goto fail;
+   }
}

hdmi->mmio = msm_ioremap(pdev, config->mmio_name, "HDMI");
@@ -330,7 +329,19 @@ static struct hdmi_platform_config hdmi_tx_8084_config = {
.hpd_freq  = hpd_clk_freq_8x74,
 };

+static const char *hpd_reg_names_8x94[] = {};
+
+static struct hdmi_platform_config hdmi_tx_8x94_config = {
+   .phy_init = NULL, /* nothing to do for this HDMI PHY 20nm */
+   HDMI_CFG(pwr_reg, 8x74),
+   HDMI_CFG(hpd_reg, 8x94),
+   HDMI_CFG(pwr_clk, 8x74),
+   HDMI_CFG(hpd_clk, 8x74),
+   .hpd_freq  = hpd_clk_freq_8x74,
+};
+
 static const struct of_device_id dt_match[] = {
+   { .compatible = "qcom,hdmi-tx-8x94", .data = &hdmi_tx_8x94_config },
{ .compatible = "qcom,hdmi-tx-8084", .data = &hdmi_tx_8084_config },
{ .compatible = "qcom,hdmi-tx-8074", .data = &hdmi_tx_8074_config },
{ .compatible = "qcom,hdmi-tx-8960", .data = &hdmi_tx_8960_config },
@@ -347,8 +358,7 @@ static int get_gpio(struct device *dev, struct device_node 
*of_node, const char
snprintf(name2, sizeof(name2), "%s-gpio", name);
gpio = of_get_named_gpio(of_node, name2, 0);
if (gpio < 0) {
-   dev_err(dev, "failed to get gpio: %s (%d)\n",
-   name, gpio);
+   DBG("failed to get gpio: %s (%d)", name, gpio);
gpio = -1;
}
}
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
index a7a1d82..00cec41 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_bridge.c
@@ -100,7 +100,9 @@ static void hdmi_bridge_pre_enable(struct drm_bridge 
*bridge)
hdmi_audio_update(hdmi);
}

-   phy->funcs->powerup(phy, hdmi->pixclock);
+   if (phy)
+   phy->funcs->powerup(phy, hdmi->pixclock);
+
hdmi_set_mode(hdmi, true);
 }

@@ -120,7 +122,9 @@ static void hdmi_bridge_post_disable(struct drm_bridge 
*bridge)

DBG("power down");
hdmi_set_mode(hdmi, false);
-   phy->funcs->powerdown(phy);
+
+   if (phy)
+   phy->funcs->powerdown(phy);

if (hdmi->power_on) {
power_off(bridge);
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
index ece572d..cdc818c 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c
@@ -84,21 +84,25 @@ static int gpio_config(struct hdmi *hdmi, bool on)
int ret;

if (on) {
-   ret = gpio_request(config->ddc_clk_gpio, "HDMI_DDC_CLK");
-   if (ret) {
-   dev_err(dev, "'%s'(%d) gpio_request failed: %d\n",
-   "HDMI_DDC_CLK", config->ddc_clk_gpio, ret);
-   goto error1;
+   if (config->ddc_clk_gpio != -1) {
+   ret = gpio_request(config->ddc_clk_gpio, 
"HDMI_DDC_CLK");
+   if (ret) {
+   dev_err(dev, "'%s'(%d) gpio_request failed: 
%d\n",
+   "HDMI_DDC_CLK", config->ddc_clk_gpio, 
ret);
+   goto error1;
+   }
+   gpio_set_value_cansleep(config->ddc_clk_gpio, 1);
 

[RESEND PATCH v2 v4.1-rc8 0/2] drm: prime: Allow exported dma-bufs to be mapped

[Benjamin Gaignard]

I'm far of being an expert in cache coherency but, from past experiences,
I have notice that ION cache management give good performances and is
simple to understand.

ION mark as "dirty" the mapped pages in wm_fault function and check this
flag while mapping the buffer in kernel space.
If the flag is set it call dma_sync_sg_for_device() with the good direction.

ION allow with an iotcl to do explicit or implicit cache management but, for
me, it add complexity to the code when implicit mode should be the
preferred one.

Benjamin


2015-06-19 17:48 GMT+02:00 Daniel Vetter :
> On Fri, Jun 19, 2015 at 02:52:27PM +0100, Daniel Thompson wrote:
>> This patch set started out as a single patch with a trivial bit of
>> boilerplate to add dmabuf mmap support to the msm driver. However Rob
>> Clark pointed out that, rather than keep one of the tricks I had used, it
>> would be better to change the helpers resulting in this series.
>>
>> I've tested this both with a rather hacked about Android userspace
>> and with a fairly small test case run from debian. Both bits of code
>> currently use dumb buffers.
>>
>> Thanks to Benjamin Gaignard for his help in finding this bit of code and
>> to Damien Hobson-Garcia for pointing out that I'd forgotten (since 3.18)
>> to RESEND these patches.
>>
>> Dave: I guess its probably too late in the dev. cycle to take this code
>>   but don't worry, I will try really hard to remember to RESEND it
>>   for 4.2. ;-)
>>
>> v2:
>>
>> * Modified DRM_PRIME_HANDLE_TO_FD to honour the O_RDRW from the user
>>   and removed code to workaround this from the sti driver (Rob Clark).
>>
>> * Added a patch to (rather spartanly) document gem_prime_mmap. Only
>>   tacked into this series 'cos I spotted it was missing when I was
>>   checking whether I needed to describe DRM_RDRW anywhere.
>
> Oh hornets nest since I just screamed around again against drm prime mmap
> support ;-) Imo before we expose this for real we really need to somehow
> figure out what to do about cache coherency. Some intel folks are looking
> into adding suitable ioctls to the dma-buf fd to make this possible. I
> think we should wait with enabling drm prime mmaping before that's
> resolved somehow. I'll point them at your patches though to make sure they
> don't reinvent this wheel here.
> -Daniel
>
>>
>>
>> Daniel Thompson (2):
>>   drm: prime: Honour O_RDWR during prime-handle-to-fd
>>   drm: prime: Document gem_prime_mmap
>>
>>  drivers/gpu/drm/drm_prime.c | 13 ++---
>>  include/uapi/drm/drm.h  |  1 +
>>  2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> --
>> 2.4.3
>>
>> ___
>> 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



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[Intel-gfx] [PATCH v2 06/10] drm: Avoid atomic commit path for CRTC property (Gamma)

[Matt Roper]

On Mon, Jun 08, 2015 at 05:58:23PM -0700, Matt Roper wrote:
> On Sat, Jun 06, 2015 at 05:34:45PM +0530, Sharma, Shashank wrote:
> > Regards
> > Shashank
> > 
> > On 6/6/2015 6:31 AM, Matt Roper wrote:
> > >On Thu, Jun 04, 2015 at 07:12:37PM +0530, Kausal Malladi wrote:
> > >>From: Kausal Malladi 
> > >>
> > >>The atomic CRTC set infrastructure is not available yet. So, the atomic
> > >>check path throws error for any non-plane property.
> > >>
> > >>This patch adds a diversion to avoid commit path for DRM atomic set Gamma
> > >>property, until atomic CRTC infrastructure is ready.
> > >
> > >This doesn't look right, but I don't quite understand what you're trying
> > >to do from the commit message.
> > >
> > >This function is what will implement legacy set_property ioctl's of a
> > >CRTC on an atomic-based driver.  The idea is that when the ioctl is
> > >issued, we should get (i.e., make a duplicate of) the current CRTC
> > >state, change some of the values in that state (which is what the
> > >.atomic_set_property function takes care of), and then submit that
> > >modified state to the driver for checking and hw-programming.
> > >
> > >Okay, I just took a quick peek ahead in your patch set and I think I
> > >understand the confusion now...it looks like you're trying to actually
> > >perform the full hardware update in the .atomic_set_property call chain,
> > >which isn't what we want to be doing in an atomic driver.
> > >.atomic_set_property() is just a matter of updating the state structures
> > >to reflect the changes you *want* to make (but not actually performing
> > >those changes right away).  It isn't until drm_atomic_commit() gets
> > >called that we validate the new state structure and then write it to the
> > >hardware if it looks okay.
> > >
> > >Keep in mind that the overall goal behind atomic is that we want to be
> > >able to supply several items to be updated (e.g., mode, CSC, gamma,
> > >etc.) via the atomic ioctl and then have them all accepted (and
> > >programmed) by the driver, or all rejected (so none get programmed) if
> > >any of them are invalid.  Also, if the collection of properties that
> > >you're updating fall within the "nuclear pageflip" subset of
> > >functionality, you'll also get a guarantee that those items all get
> > >updated within the same vblank; updates that straddle a vblank could
> > >cause unwanted flickering or other artifacts.  The helper function
> > >you're updating here only happens to update a single state value at a
> > >time, but the same .atomic_set_property() is also used by the atomic
> > >ioctl, so we need to make sure it's following the expected design.
> > >
> > >Finally, keep in mind that the function you're updating here is a DRM
> > >core function.  Even though i915 isn't quite ready for full atomic yet
> > >and might have a bit of brain damage in areas, other vendors' drivers do
> > >have complete atomic modesetting support (I think?), so adding
> > >i915-specific workarounds like this to the core function could actually
> > >hamper them.
> > >
> > >
> > >Matt
> > >
> > I understood this point. But in this case, we will be blocked until
> > set CRTC implementation comes in. Can you suggest a better way to
> > handle this without getting blocked for set_crtc() ?
> 
> Is the functionality you need still lacking with Maarten Lankhorst's
> "convert to atomic, part 2" series that recently landed upstream?  If
> that series isn't sufficient, them I'm pretty sure that his "part 3"
> series on the mailing list will fix it; that will hopefully be ready to
> merge as soon as I get a chance to do a review of it.
> 
> I'll add Maarten to the Cc here in case he wants to comment...
> 
> 
> Matt

Kausal/Shashank, have you guys had a chance to check out Maarten's
latest i915 atomic work?  His "part 2" series is already merged and
"part 3" should be merged soon and those really help clean up a lot of
the Intel-specific pain points caused by the atomic transition.  I think
we need to make sure you can handle properties properly in an atomic
manner, so if you find you're still blocked on the current code, we
should look into how to address that so that we don't have to bring any
temporary Intel hackiness into the shared DRM core code.


Matt

> 
> > >>
> > >>Signed-off-by: Shashank Sharma 
> > >>Signed-off-by: Kausal Malladi 
> > >>---
> > >>  drivers/gpu/drm/drm_atomic_helper.c | 17 ++---
> > >>  1 file changed, 14 insertions(+), 3 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > >>b/drivers/gpu/drm/drm_atomic_helper.c
> > >>index a900858..37dba55 100644
> > >>--- a/drivers/gpu/drm/drm_atomic_helper.c
> > >>+++ b/drivers/gpu/drm/drm_atomic_helper.c
> > >>@@ -1696,6 +1696,8 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc 
> > >>*crtc,
> > >>  {
> > >>  struct drm_atomic_state *state;
> > >>  struct drm_crtc_state *crtc_state;
> > >>+ struct drm_device *dev = crtc->dev;
> > >>+ struct drm_mode_config