[REPOST PATCH 4/8] android: convert sync to fence api, v5

[Thierry Reding]

On Thu, Jun 19, 2014 at 02:28:14PM +0200, Daniel Vetter wrote:
> On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding
>  wrote:
> >> > With these changes, can we pull the android sync logic out of
> >> > drivers/staging/ now?
> >>
> >> Afaik the google guys never really looked at this and acked it. So I'm not
> >> sure whether they'll follow along. The other issue I have as the
> >> maintainer of gfx driver is that I don't want to implement support for two
> >> different sync object primitives (once for dma-buf and once for android
> >> syncpts), and my impression thus far has been that even with this we're
> >> not there.
> >>
> >> I'm trying to get our own android guys to upstream their i915 syncpts
> >> support, but thus far I haven't managed to convince them to throw people's
> >> time at this.
> >
> > This has been discussed a fair bit internally recently and some of our
> > GPU experts have raised concerns that this may result in seriously
> > degraded performance in our proprietary graphics stack. Now I don't care
> > very much for the proprietary graphics stack, but by extension I would
> > assume that the same restrictions are relevant for any open-source
> > driver as well.
> >
> > I'm still trying to fully understand all the implications and at the
> > same time get some of the people who raised concerns to join in this
> > discussion. As I understand it the concern is mostly about explicit vs.
> > implicit synchronization and having this mechanism in the kernel will
> > implicitly synchronize all accesses to these buffers even in cases where
> > it's not needed (read vs. write locks, etc.). In one particular instance
> > it was even mentioned that this kind of implicit synchronization can
> > lead to deadlocks in some use-cases (this was mentioned for Android
> > compositing, but I suspect that the same may happen for Wayland or X
> > compositors).
> 
> Well the implicit fences here actually can't deadlock. That's the
> entire point behind using ww mutexes. I've also heard tons of
> complaints about implicit enforced syncing (especially from opencl
> people), but in the end drivers and always expose unsynchronized
> access for specific cases. We do that in i915 for upload buffers and
> other fun stuff. This is about shared stuff across different drivers
> and different processes.

Tegra K1 needs to share buffers across different drivers even for very
basic use-cases since the GPU and display drivers are separate. So while
I agree that the GPU driver can still use explicit synchronization for
internal work, things aren't that simple in general.

Let me try to reconstruct the use-case that caused the lock on Android:
the compositor uses a hardware overlay to display an image. The system
detects that there's little activity and instructs the compositor to put
everything into one image and scan out only that (for power efficiency).
Now with implicit locking the display driver has a lock on the image, so
the GPU (used for compositing) needs to wait for it before it can
composite everything into one image. But the display driver cannot
release the lock on the image until the final image has been composited
and can be displayed instead.

This may not be technically a deadlock, but it's still a stalemate.
Unless I'm missing something fundamental about DMA fences and ww mutexes
I don't see how you can get out of this situation.

Explicit vs. implicit synchronization may also become more of an issue
as buffers are imported from other sources (such as cameras).

> Finally I've never seen anyone from google or any android product guy
> push a real driver enabling for syncpts to upstream, and google itself
> has a bit a history of constantly exchanging their gfx framework for
> the next best thing. So I really doubt this is worthwhile to pursue in
> upstream with our essentially eternal api guarantees. At least until
> we see serious uptake from vendors and gfx driver guys. Unfortunately
> the Intel android folks are no exception here and haven't pushed
> anything like this in my direction yet at all. Despite multiple pokes
> from my side.
> 
> So from my side I think we should move ahead with Maarten's work and
> figure the android side out once there's real interest.

The downside of that is that we may end up with two different ways to
synchronize buffers if it turns out that we can't make Android (or other
use-cases) work with DMA fence. However I don't think that justifies
postponing this patch set indefinitely.

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

drm/i2c: tda998x: free the CEC device on encoder_destroy

[Dan Carpenter]

Hello Jean-Francois Moine,

This is a semi-automatic email about new static checker warnings.

The patch fc275a74eb81: "drm/i2c: tda998x: free the CEC device on 
encoder_destroy" from Jan 25, 2014, leads to the following Smatch 
complaint:

drivers/gpu/drm/i2c/tda998x_drv.c:1194 tda998x_encoder_destroy()
 warn: variable dereferenced before check 'priv->cec' (see line 1189)

drivers/gpu/drm/i2c/tda998x_drv.c
  1188  /* disable all IRQs and free the IRQ handler */
  1189  cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
  
We need priv->cec for this.

  1190  reg_clear(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
  1191  if (priv->hdmi->irq)
  1192  free_irq(priv->hdmi->irq, priv);
  1193  
  1194  if (priv->cec)
^
So hopefully this new check can be removed?

  1195  i2c_unregister_device(priv->cec);
  1196  kfree(priv);

regards,
dan carpenter

[PATCH] drm/panel: add support for Innolux N156BGE-L21 panel

[Thierry Reding]

On Thu, Jun 12, 2014 at 05:09:05PM +0200, Alban Bedel wrote:
> This panel is used by the Medcom Wide and supported by the
> simple-panel driver.
> 
> Signed-off-by: Alban Bedel 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 309f29e..6a361bb 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -372,6 +372,28 @@ static const struct panel_desc samsung_ltn101nt05 = {
>   },
>  };
>  
> +static const struct drm_display_mode innolux_n156bge_l21_mode = {
> + .clock = 69300,
> + .hdisplay = 1366,
> + .hsync_start = 1366,
> + .hsync_end = 1366,
> + .htotal = 1366 + 100,
> + .vdisplay = 768,
> + .vsync_start = 768,
> + .vsync_end = 768,
> + .vtotal = 768 + 20,

The timings here look slightly strange. Typically

.{h,v}display < .{h,v}sync_start < .{h,v}hsync_end < .{h,v}total

Given your timings above essentially means that the vsync pulse starts
immediately after the last active pixel or line and is of length zero.

> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc innolux_n156bge_l21 = {
> + .modes = _n156bge_l21_mode,
> + .num_modes = 1,
> + .size = {
> + .width = 1366,
> + .height = 768,

This size is the physical size (in mm) of the active area of the panel.

> + },
> +};
> +
>  static const struct of_device_id platform_of_match[] = {
>   {
>   .compatible = "auo,b101aw03",
> @@ -389,6 +411,9 @@ static const struct of_device_id platform_of_match[] = {
>   .compatible = "samsung,ltn101nt05",
>   .data = _ltn101nt05,
>   }, {
> + .compatible = "innolux,n156bge-l21",
> + .data = _n156bge_l21,
> + }, {

This patch should also be adding a device tree binding document for this
panel.

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

[Bug 80311] New: 3D acceleration is broken with recent llvm and git

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

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

  Priority: medium
Bug ID: 80311
  Assignee: dri-devel at lists.freedesktop.org
   Summary: 3D acceleration is broken with recent llvm and git
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: half-shot at molrams.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 101461
  --> https://bugs.freedesktop.org/attachment.cgi?id=101461=edit
glxinfo

On my RadeonHD 7950, some games will get as far as the menu but by using
glxgears it segfaults on start with the message 'LLVM triggered Diagnostic
Handler: unsupported call to function llvm.AMDGPU.rsq in main'. Some games will
crash xorg, some will just segfault. SuperTuxKart has also been tested and the
game does not crash until actual 3D elements are drawn, as with Team Fortress
2.

Distro is Arch Linux
Environment is XFCE4
Kernel Version: 3.15.0-1-mainline
glxinfo is dumped to file
LLVM Version: 3.5.0svn (211341-1)

Thanks for checking.

-- 
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/20140620/4bbaeb5c/attachment.html>

AGP GART clarifications, please!

[Dave Airlie]

On 20 June 2014 18:27, ?meric MASCHINO  wrote:
> 2014-06-20 2:06 GMT+02:00 Dave Airlie :
>> So to run in AGP mode you need a chipset specific driver to manage the
>> chipsets AGP GART and other features, that the GPU drivers can talk
>> to.
>
> Do the GPU drivers then talk differently to the graphics card when
> there's a GART? I mean, are there different code paths in the GPU
> drivers depending on the presence of GART or not? Or is the command
> stream built by the DRI module exactly the same with or without GART?

The userspace command streams are the same, the kernel driver is all
that contains differences,

in the radeon driver look for RADEON_IS_AGP, to see the differences.

> Next, in the kernel DRM, are there different code paths taken
> depending on the presence of GART or not? Or is it something
> "transparently" (from the DRI module/kernel DRM point of view) managed
> at the hardware level: I mean, the exact same data are sent to the
> graphics card through the DRI module and kernel DRM, but depending on
> the presence of GART or not, the data aren't handled the same at the
> hardware level and are "intercepted" and managed differently (e.g.
> reorganized) by the GART before being effectively delivered to the
> graphics adapter?

The GPUs have an internal memory layout, all the GART does is allow it to see
scatter/gather objects in main RAM as linear objects in its address space, so
its only about how the GPU accesses objects, and how the CPU sets things up,

Nothing else is affected like shaders or command streams.

booting with radeon.benchmark=1 might show some.

Dave.

[PATCH 5/5] drm/exynos: enable vsync interrupt while waiting for vblank

[Rahul Sharma]

Hi All,

On 18 June 2014 17:04, Rahul Sharma  wrote:
> mixer_wait_for_vblank function expects that the upcoming
> vsync interrupt handler routine will clear the
> wait_vsync_event atomic variable.
>
> For this to happen, interrupts should be enabled and
> disabled properly.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 6f18581..7927f2e 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1019,6 +1019,8 @@ static void mixer_wait_for_vblank(struct 
> exynos_drm_manager *mgr)
> }
> mutex_unlock(_ctx->mixer_mutex);
>
> +   mixer_enable_vblank(mgr);
> +
> atomic_set(_ctx->wait_vsync_event, 1);
>
> /*
> @@ -1029,6 +1031,8 @@ static void mixer_wait_for_vblank(struct 
> exynos_drm_manager *mgr)
> !atomic_read(_ctx->wait_vsync_event),
> HZ/20))
> DRM_DEBUG_KMS("vblank wait timed out.\n");
> +
> +   mixer_disable_vblank(mgr);
>  }

I found issue with this patch. It is causing deadlock by bypassing
vblank refcounting
and manually disabling the Interrupt.

I switched to following and it is back on track.

drm_vblank_get(mgr->crtc->dev, mixer_ctx->pipe);
drm_vblank_put(mgr->crtc->dev, mixer_ctx->pipe);

I will include this change in next version.

Regards,
Rahul Sharma.

>
>  static void mixer_window_suspend(struct exynos_drm_manager *mgr)
> --
> 1.7.9.5
>

[PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start, len}

[Daniel Kurtz]

On Fri, Jun 20, 2014 at 7:59 AM, Siarhei Siamashka
 wrote:
>
> On Fri,  4 Apr 2014 17:22:01 +0800
> Daniel Kurtz  wrote:
>
> > Kernel access to the eyxnos fbdev framebuffer is via its gem object's
> > kernel mapping (kvaddr, stored in info->screen_base).
> >
> > User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
> > These functions also only use screen_base/screen_size().
> >
> > Therefore, it is not necessary to set fix->smem_{start,len} or
> > fix->mmio_{start,len} fields.
> >
> > This avoids leaking kernel, physical and dma mapped addresses to user
> > space via the ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO.
> >
> > Signed-off-by: Daniel Kurtz 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ---
> >  1 file changed, 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > index 5fa342e..2dcc589 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -123,14 +123,7 @@ static int exynos_drm_fbdev_update(struct 
> > drm_fb_helper *helper,
> >
> >   dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
> >   fbi->screen_base = buffer->kvaddr + offset;
> > - if (is_drm_iommu_supported(dev))
> > - fbi->fix.smem_start = (unsigned long)
> > - (page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
> > - else
> > - fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
> > -
> >   fbi->screen_size = size;
> > - fbi->fix.smem_len = size;
>
> Can we keep proper initialization of 'smem_len'? Some userland
> applications use it for calculating the size for mmap:
>
> 
> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571
>
> >
> >   return 0;
> >  }
>
> Basically, this patch breaks the xf86-video-fbdev ddx and some users
> are already unhappy.


I'm so sorry this patch broke things for some users.
Can you upload a patch to correct it?
I'll happily review it.

-djk

>
>
> --
> Best regards,
> Siarhei Siamashka

[Bug 68151] Backlight brightness change causes freeze (radeon with KMS)

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

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

Fabian  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |UNREPRODUCIBLE

--- Comment #3 from Fabian  ---
I tried to bisect it but somehow it got very hard to reproduce at some point.
I had to change the backlight for almost a minute before it freezes and with
the new 3.15.0-rc4 I'm running on I can't reproduce it with normal usage.
I can't tell for sure whether it's fixed, but it works definitely reliable
enough for me, so closing as "unreproducible" for now.

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

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

Just ping, any comments?

Thanks
Tiejun

On 2014/6/19 17:53, Tiejun Chen wrote:
> Originally the reason to probe ISA bridge instead of Dev31:Fun0
> is to make graphics device passthrough work easy for VMM, that
> only need to expose ISA bridge to let driver know the real
> hardware underneath. This is a requirement from virtualization
> team. Especially in that virtualized environments, XEN, there
> is irrelevant ISA bridge in the system with that legacy qemu
> version specific to xen, qemu-xen-traditional. So to work
> reliably, we should scan through all the ISA bridge devices
> and check for the first match, instead of only checking the
> first one.
>
> But actually, qemu-xen-traditional, is always enumerated with
> Dev31:Fun0, 00:1f.0 as follows:
>
> hw/pt-graphics.c:
>
> intel_pch_init()
>  |
>  + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
>
> so this mean that isa bridge is still represented with Dev31:Func0
> like the native OS. Furthermore, currently we're pushing VGA
> passthrough support into qemu upstream, and with some discussion,
> we wouldn't set the bridge class type and just expose this devfn.
>
> So we just go back to check devfn to make life normal.
>
> Signed-off-by: Tiejun Chen 
> ---
>   drivers/gpu/drm/i915/i915_drv.c | 19 +++
>   1 file changed, 3 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 651e65e..cb2526e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -417,18 +417,8 @@ void intel_detect_pch(struct drm_device *dev)
>   return;
>   }
>
> - /*
> -  * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> -  * make graphics device passthrough work easy for VMM, that only
> -  * need to expose ISA bridge to let driver know the real hardware
> -  * underneath. This is a requirement from virtualization team.
> -  *
> -  * In some virtualized environments (e.g. XEN), there is irrelevant
> -  * ISA bridge in the system. To work reliably, we should scan trhough
> -  * all the ISA bridge devices and check for the first match, instead
> -  * of only checking the first one.
> -  */
> - while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
> + pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
> + if (pch) {
>   if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>   unsigned short id = pch->device & 
> INTEL_PCH_DEVICE_ID_MASK;
>   dev_priv->pch_id = id;
> @@ -462,10 +452,7 @@ void intel_detect_pch(struct drm_device *dev)
>   DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
>   WARN_ON(!IS_HASWELL(dev));
>   WARN_ON(!IS_ULT(dev));
> - } else
> - continue;
> -
> - break;
> + }
>   }
>   }
>   if (!pch)
>

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

[Laszlo Kertesz]

On 6/20/2014 4:30 PM, bugzilla-daemon at freedesktop.org wrote:
>
> *Comment # 25 <https://bugs.freedesktop.org/show_bug.cgi?id=72921#c25> 
> on bug 72921 <https://bugs.freedesktop.org/show_bug.cgi?id=72921> from 
> Alex Deucher <mailto:agd5f at yahoo.com> *
> (In reply tocomment #24  <show_bug.cgi?id=72921#c24>)
> > Createdattachment 101420  <attachment.cgi?id=101420>  [details]  
> > <attachment.cgi?id=101420=edit>
> > dmesg with working bapm patch
> >
> > I can confirm that the latter patch (attachment 101191  
> > <attachment.cgi?id=101191>  [details]  
> > <attachment.cgi?id=101191=edit>  [review]  
> > <page.cgi?id=splinter.html=72921=101191>  [review])
> > solves the issue for me, I haven't tried the earlier patch because it didn't
> > work for Collin. I can re-test that if that's still useful.
> >
>
> Probably not necessary.
>
> > Attaching dmesg; I compared the probed power states and they appear similar.
> > What's bapm?
>
> It allows the CPU and GPU to share TDP headroom.  E.g., if the CPU isn't busy,
> the the GPU can user higher performance states longer and vice versa.
And what happens if its disabled?
Because as it stands now, the CPU and GPU are still throttled if heated 
up. The CPU's turbo core is disabled, is it the same for the GPU?


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

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/b1f595f9/attachment-0001.html>

[PATCH] drm: fix NULL pointer access by wrong ioctl

[David Herrmann]

Hi

On Wed, Jun 18, 2014 at 8:33 AM, Zhaowei Yuan  
wrote:
> If user uses wrong ioctl command with _IOC_NONE and argument size
> greater than 0, it can cause NULL pointer access from memset of line
> 463. If _IOC_NONE, don't memset to 0 for kdata.
>
> Signed-off-by: Zhaowei Yuan 

Reviewed-by: David Herrmann 
Cc: 

@Dave: Imo, this should go through stable. We initialize "kdata" to
NULL, but "usize" can be up to 2^14, so it might write to real memory
there. Most systems probably reserve the lower 64KB and the first
write on the NULL-page should kill the process and have no other
side-effects, however, who knows how memset() is implemented on
different architectures. It might start writing at the end.. or might
issue large writes.. what do I know..

Thanks
David

> ---
>  drivers/gpu/drm/drm_drv.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>  mode change 100644 => 100755 drivers/gpu/drm/drm_drv.c
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> old mode 100644
> new mode 100755
> index 2ab782c..1a92bcb
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -459,8 +459,9 @@ long drm_ioctl(struct file *filp,
> retcode = -EFAULT;
> goto err_i1;
> }
> -   } else
> +   } else if (cmd & IOC_OUT) {
> memset(kdata, 0, usize);
> +   }
>
> if (ioctl->flags & DRM_UNLOCKED)
> retcode = func(dev, kdata, file_priv);
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 65121] Possible memory leak in qxl drm driver

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

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

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #12 from Alan  ---
Dave - ask the bugzilla contact address for your superman powers. I'm sure
you'll have no trouble then

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

[PATCH] drm/msm: Implement msm drm fb_mmap callback function

[h...@codeaurora.org]

Re-send the patch to remove the unnecessary initialization and the comment

> This change implements msm drm specific fb_mmap function for fb device
> to properly map the fb address to userspace.
>
> Signed-off-by: Hai Li 
> Signed-off-by: Stephane Viau 
> ---
>  drivers/gpu/drm/msm/msm_fbdev.c | 38
> --
>  1 file changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_fbdev.c
> b/drivers/gpu/drm/msm/msm_fbdev.c
> index a752ab8..2694e90 100644
> --- a/drivers/gpu/drm/msm/msm_fbdev.c
> +++ b/drivers/gpu/drm/msm/msm_fbdev.c
> @@ -19,6 +19,11 @@
>
>  #include "drm_crtc.h"
>  #include "drm_fb_helper.h"
> +#include "msm_gem.h"
> +
> +extern int msm_gem_mmap_obj(struct drm_gem_object *obj,
> + struct vm_area_struct *vma);
> +static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct
> *vma);
>
>  /*
>   * fbdev funcs, to implement legacy fbdev interface on top of drm driver
> @@ -43,6 +48,7 @@ static struct fb_ops msm_fb_ops = {
>   .fb_fillrect = sys_fillrect,
>   .fb_copyarea = sys_copyarea,
>   .fb_imageblit = sys_imageblit,
> + .fb_mmap = msm_fbdev_mmap,
>
>   .fb_check_var = drm_fb_helper_check_var,
>   .fb_set_par = drm_fb_helper_set_par,
> @@ -51,6 +57,31 @@ static struct fb_ops msm_fb_ops = {
>   .fb_setcmap = drm_fb_helper_setcmap,
>  };
>
> +static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct
> *vma)
> +{
> + struct drm_fb_helper *helper = (struct drm_fb_helper *)info->par;
> + struct msm_fbdev *fbdev = to_msm_fbdev(helper);
> + struct drm_gem_object *drm_obj = fbdev->bo;
> + struct drm_device *dev = helper->dev;
> + int ret;
> +
> + if (drm_device_is_unplugged(dev))
> + return -ENODEV;
> +
> + mutex_lock(>struct_mutex);
> +
> + ret = drm_gem_mmap_obj(drm_obj, drm_obj->size, vma);
> +
> + mutex_unlock(>struct_mutex);
> +
> + if (ret) {
> + pr_err("%s:drm_gem_mmap_obj fail\n", __func__);
> + return ret;
> + }
> +
> + return msm_gem_mmap_obj(drm_obj, vma);
> +}
> +
>  static int msm_fbdev_create(struct drm_fb_helper *helper,
>   struct drm_fb_helper_surface_size *sizes)
>  {
> @@ -104,8 +135,11 @@ static int msm_fbdev_create(struct drm_fb_helper
> *helper,
>
>   mutex_lock(>struct_mutex);
>
> - /* TODO implement our own fb_mmap so we don't need this: */
> - msm_gem_get_iova_locked(fbdev->bo, 0, );
> + ret = msm_gem_get_iova_locked(fbdev->bo, 0, );
> + if (ret) {
> + dev_err(dev->dev, "failed to get buffer obj iova: %d\n", ret);
> + goto fail;
> + }
>
>   fbi = framebuffer_alloc(0, dev->dev);
>   if (!fbi) {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
>

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Paolo Bonzini]

Il 19/06/2014 11:53, Tiejun Chen ha scritto:
> so this mean that isa bridge is still represented with Dev31:Func0
> like the native OS. Furthermore, currently we're pushing VGA
> passthrough support into qemu upstream, and with some discussion,
> we wouldn't set the bridge class type and just expose this devfn.

Even this is not really optimal.  It just happens to work just because 
QEMU's machine is currently a PCI machine with the ISA bridge on 00:01.0.

As soon as you'll try doing integrated graphics passthrough on a PCIe 
machine type (such as QEMU's "-M q35") things will break down just as badly.

Paolo

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Daniel Vetter]

Well I have no clue about forwarding the intel gpu to virtualized
hosts and also no idea who could review this really. There's been a
bit a discussion around the iommu mapping forwarding and similar
topics though. So I really wonder how well our driver works in this
use case ...
-Daniel

On Fri, Jun 20, 2014 at 11:40 AM, Chen, Tiejun  wrote:
> Just ping, any comments?
>
> Thanks
> Tiejun
>
>
> On 2014/6/19 17:53, Tiejun Chen wrote:
>>
>> Originally the reason to probe ISA bridge instead of Dev31:Fun0
>> is to make graphics device passthrough work easy for VMM, that
>> only need to expose ISA bridge to let driver know the real
>> hardware underneath. This is a requirement from virtualization
>> team. Especially in that virtualized environments, XEN, there
>> is irrelevant ISA bridge in the system with that legacy qemu
>> version specific to xen, qemu-xen-traditional. So to work
>> reliably, we should scan through all the ISA bridge devices
>> and check for the first match, instead of only checking the
>> first one.
>>
>> But actually, qemu-xen-traditional, is always enumerated with
>> Dev31:Fun0, 00:1f.0 as follows:
>>
>> hw/pt-graphics.c:
>>
>> intel_pch_init()
>>  |
>>  + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
>>
>> so this mean that isa bridge is still represented with Dev31:Func0
>> like the native OS. Furthermore, currently we're pushing VGA
>> passthrough support into qemu upstream, and with some discussion,
>> we wouldn't set the bridge class type and just expose this devfn.
>>
>> So we just go back to check devfn to make life normal.
>>
>> Signed-off-by: Tiejun Chen 
>> ---
>>   drivers/gpu/drm/i915/i915_drv.c | 19 +++
>>   1 file changed, 3 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 651e65e..cb2526e 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -417,18 +417,8 @@ void intel_detect_pch(struct drm_device *dev)
>> return;
>> }
>>
>> -   /*
>> -* The reason to probe ISA bridge instead of Dev31:Fun0 is to
>> -* make graphics device passthrough work easy for VMM, that only
>> -* need to expose ISA bridge to let driver know the real hardware
>> -* underneath. This is a requirement from virtualization team.
>> -*
>> -* In some virtualized environments (e.g. XEN), there is
>> irrelevant
>> -* ISA bridge in the system. To work reliably, we should scan
>> trhough
>> -* all the ISA bridge devices and check for the first match,
>> instead
>> -* of only checking the first one.
>> -*/
>> -   while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>> +   pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>> +   if (pch) {
>> if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>> unsigned short id = pch->device &
>> INTEL_PCH_DEVICE_ID_MASK;
>> dev_priv->pch_id = id;
>> @@ -462,10 +452,7 @@ void intel_detect_pch(struct drm_device *dev)
>> DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
>> WARN_ON(!IS_HASWELL(dev));
>> WARN_ON(!IS_ULT(dev));
>> -   } else
>> -   continue;
>> -
>> -   break;
>> +   }
>> }
>> }
>> if (!pch)
>>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/3] Remove devm_request_and_ioremap()

[Tushar Behera]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/20/2014 02:15 PM, Wolfram Sang wrote:
> On Thu, Jun 19, 2014 at 07:59:57PM -0700, 'Greg Kroah-Hartman'
> wrote:
>> On Fri, Jun 20, 2014 at 11:36:03AM +0900, Jingoo Han wrote:
>>> On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote:
 
 Pretty much a year ago, Tushar cleaned up a lot of deprecated
 uses of devm_request_and_ioremap, yet some remains are still
 left. Remove the last two users, and let the function rest in
 peace. I'd suggest that this series is picked up as a whole
 to have that case finally closed. Greg? Are you interested in
 picking it up?
>>> 
>>> (+cc Greg Kroah-Hartman)
>>> 
>>> I already sent the same patch as one single patch to Greg
>>> Kroah-Hartman. [1] Also, it was accepted by Greg Kroah-Hartman.
>>> [2] Thank you.
>>> 
>>> [1] https://lkml.org/lkml/2014/6/11/26 [2]
>>> https://lkml.org/lkml/2014/6/11/649
>> 
>> Yeah, I'll go apply that right now while I'm remembering it :)
> 
> For the patch above:
> 
> Reviewed-by: Wolfram Sang 
> 

If it is still not late,

Acked-by: Tushar Behera 

- -- 
Tushar Behera
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTo/YpAAoJELqclMPPkq4NOsIIAIkN+lOgWTIo3IBw7oQ9yO76
Hjn6fR2kjWOdrXrTdW3KQRzElw8hMKdPF5++GkgAkreoLSxRBLnyHdGc0jPdmxXw
gIu4O0WNQYRKYN+fkHPkl/5z10SNmZrnwcq37FK8EMCqpph7JywYOu5WyNVjMKOh
gTJ9zME+iCAzE+KlzBr7pRLySkFvgtITqBRT/lsRmGGpjH+kphSmYuY2kvz2VVLI
DE6Zy8kOyZEEDwDsm62qhoZNtzKcGoZgSqNFKU8fM9duonRhAwUQKImUnKB1H1CD
FQcmZI/4WA/6OLypUSBj/AIciK1MW/Gu6IpILjNVwQA/q3CKEaUkiHf+2HNVohU=
=FBDs
-END PGP SIGNATURE-

[PATCH V4 10/10] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> From: Rahul Sharma 
>
> This patch adds ps8622 lvds bridge discovery code to the dp driver.
>
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 69535f7..87eabe7 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_dp_core.h"
> @@ -999,6 +1000,10 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
> if (find_bridge("nxp,ptn3460", )) {
> bridge_chain = ptn3460_init(dp->drm_dev, encoder, 
> bridge.client,
> bridge.node);
> +   } else if (find_bridge("parade,ps8622", ) ||
> +   find_bridge("parade,ps8625", )) {
> +   bridge_chain = ps8622_init(dp->drm_dev, encoder, 
> bridge.client,
> +   bridge.node);
> }
>
> if (bridge_chain && dp->edp_panel) {
> --
> 1.7.9.5
>

[PATCH V4 09/10] drm/bridge: Add ps8622/ps8625 bridge driver

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> From: Vincent Palatin 
>
> This patch adds drm_bridge driver for parade DisplayPort
> to LVDS bridge chip.
>
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Andrew Bresticker 
> Signed-off-by: Sean Paul 
> Signed-off-by: Rahul Sharma 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>  drivers/gpu/drm/bridge/Kconfig |8 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/ps8622.c|  475 
> 
>  include/drm/bridge/ps8622.h|   41 ++
>  5 files changed, 546 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>  create mode 100644 include/drm/bridge/ps8622.h
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt 
> b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> new file mode 100644
> index 000..1afbd9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
> @@ -0,0 +1,21 @@
> +ps8622-bridge bindings
> +
> +Required properties:
> +   - compatible: "parade,ps8622"
> +   - reg: first i2c address of the bridge
> +   - sleep-gpio: OF device-tree gpio specification
> +   - reset-gpio: OF device-tree gpio specification
> +
> +Optional properties:
> +   - lane-count: number of DP lanes to use
> +   - use-external-pwm: backlight will be controlled by an external PWM
> +
> +Example:
> +   ps8622-bridge at 48 {
> +   compatible = "parade,ps8622";
> +   reg = <0x48>;
> +   sleep-gpio = < 6 1 0 0>;
> +   reset-gpio = < 1 1 0 0>;
> +   display-timings = <_display_timings>;
> +   lane-count = <1>
> +   };
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e3fb487..7b843c8 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
> select DRM_KMS_HELPER
> select DRM_PANEL
> ---help---
> +
> +config DRM_PS8622
> +   tristate "Parade eDP/LVDS bridge"
> +   depends on DRM
> +   select DRM_KMS_HELPER
> +   select BACKLIGHT_LCD_SUPPORT
> +   select BACKLIGHT_CLASS_DEVICE
> +   ---help---
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index ba8b5b8..b494d4b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
>
>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
>  obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
> +obj-$(CONFIG_DRM_PS8622) += ps8622.o
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> new file mode 100644
> index 000..387d332
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -0,0 +1,475 @@
> +/*
> + * Parade PS8622 eDP/LVDS bridge driver
> + *
> + * Copyright (C) 2014 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "drmP.h"
> +#include "drm_crtc.h"
> +#include "drm_crtc_helper.h"
> +
> +struct ps8622_bridge {
> +   struct drm_bridge *bridge;
> +   struct drm_encoder *encoder;
> +   struct i2c_client *client;
> +   struct regulator *v12;
> +   struct backlight_device *bl;
> +   struct mutex enable_mutex;
> +
> +   int gpio_slp_n;
> +   int gpio_rst_n;
> +
> +   u8 max_lane_count;
> +   u8 lane_count;
> +
> +   bool enabled;
> +};
> +
> +struct ps8622_device_data {
> +   u8 max_lane_count;
> +};
> +
> +static const struct ps8622_device_data ps8622_data = {
> +   .max_lane_count = 1,
> +};
> +
> +static const struct ps8622_device_data ps8625_data = {
> +   .max_lane_count = 2,
> +};
> +
> +/* Brightness scale on the Parade chip */
> +#define PS8622_MAX_BRIGHTNESS 0xff
> +
> +/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
> +#define PS8622_POWER_RISE_T1_MIN_US 10
> +#define PS8622_POWER_RISE_T1_MAX_US 1
> +#define PS8622_RST_HIGH_T2_MIN_US 3000
> +#define PS8622_RST_HIGH_T2_MAX_US 3
> +#define PS8622_PWMO_END_T12_MS 200
> +#define PS8622_POWER_FALL_T16_MAX_US 1
> +#define PS8622_POWER_OFF_T17_MS 500
> +
> +#if 

[PATCH V4 08/10] drm/exynos: dp: create bridge chain using ptn3460 and panel_binder

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> exynos_dp supports a simple bridge chain with ptn3460 bridge
> and an LVDS panel attached to it.
> This patch creates the bridge chain with ptn3460 as the head
> of the list and panel_binder being the tail.
>
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index d8546ea..69535f7 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_dp_core.h"
> @@ -992,7 +993,7 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
> struct drm_encoder *encoder)
>  {
> struct bridge_init bridge;
> -   struct drm_bridge *bridge_chain = NULL;
> +   struct drm_bridge *bridge_chain = NULL, *next = NULL;
> bool connector_created = false;
>
> if (find_bridge("nxp,ptn3460", )) {
> @@ -1000,6 +1001,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
> bridge.node);
> }
>
> +   if (bridge_chain && dp->edp_panel) {
> +   next = panel_binder_init(dp->drm_dev, encoder, bridge.client,
> +   bridge.node, dp->edp_panel, DRM_MODE_CONNECTOR_LVDS,
> +   DRM_CONNECTOR_POLL_HPD);
> +   if (next)
> +   connector_created = true;
> +   drm_bridge_add_to_chain(bridge_chain, next);
> +   }
> +
> return connector_created;
>  }
>
> --
> 1.7.9.5
>

[PATCH V4 07/10] drm/bridge: ptn3460: Support bridge chaining

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> Modify the driver to invoke callbacks for the next bridge
> in the bridge chain.
> Also, remove the drm_connector implementation from ptn3460,
> since the same is implemented using panel_binder.
>
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/bridge/ptn3460.c|  136 
> +--
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   16 ++--
>  include/drm/bridge/ptn3460.h|   15 ++--
>  3 files changed, 39 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
> b/drivers/gpu/drm/bridge/ptn3460.c
> index 98fd17a..21e9db8 100644
> --- a/drivers/gpu/drm/bridge/ptn3460.c
> +++ b/drivers/gpu/drm/bridge/ptn3460.c
> @@ -34,37 +34,15 @@
>  #define PTN3460_EDID_SRAM_LOAD_ADDR0x85
>
>  struct ptn3460_bridge {
> -   struct drm_connector connector;
> struct i2c_client *client;
> struct drm_encoder *encoder;
> struct drm_bridge *bridge;
> -   struct edid *edid;
> int gpio_pd_n;
> int gpio_rst_n;
> u32 edid_emulation;
> bool enabled;
>  };
>
> -static int ptn3460_read_bytes(struct ptn3460_bridge *ptn_bridge, char addr,
> -   u8 *buf, int len)
> -{
> -   int ret;
> -
> -   ret = i2c_master_send(ptn_bridge->client, , 1);
> -   if (ret <= 0) {
> -   DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
> -   return ret;
> -   }
> -
> -   ret = i2c_master_recv(ptn_bridge->client, buf, len);
> -   if (ret <= 0) {
> -   DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
> -   return ret;
> -   }
> -
> -   return 0;
> -}
> -
>  static int ptn3460_write_byte(struct ptn3460_bridge *ptn_bridge, char addr,
> char val)
>  {
> @@ -126,6 +104,8 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
> gpio_set_value(ptn_bridge->gpio_rst_n, 1);
> }
>
> +   drm_next_bridge_pre_enable(bridge);
> +
> /*
>  * There's a bug in the PTN chip where it falsely asserts hotplug 
> before
>  * it is fully functional. We're forced to wait for the maximum start 
> up
> @@ -142,6 +122,7 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
>
>  static void ptn3460_enable(struct drm_bridge *bridge)
>  {
> +   drm_next_bridge_enable(bridge);
>  }
>
>  static void ptn3460_disable(struct drm_bridge *bridge)
> @@ -153,6 +134,8 @@ static void ptn3460_disable(struct drm_bridge *bridge)
>
> ptn_bridge->enabled = false;
>
> +   drm_next_bridge_disable(bridge);
> +
> if (gpio_is_valid(ptn_bridge->gpio_rst_n))
> gpio_set_value(ptn_bridge->gpio_rst_n, 1);
>
> @@ -162,6 +145,7 @@ static void ptn3460_disable(struct drm_bridge *bridge)
>
>  static void ptn3460_post_disable(struct drm_bridge *bridge)
>  {
> +   drm_next_bridge_post_disable(bridge);
>  }
>
>  void ptn3460_bridge_destroy(struct drm_bridge *bridge)
> @@ -173,6 +157,9 @@ void ptn3460_bridge_destroy(struct drm_bridge *bridge)
> gpio_free(ptn_bridge->gpio_pd_n);
> if (gpio_is_valid(ptn_bridge->gpio_rst_n))
> gpio_free(ptn_bridge->gpio_rst_n);
> +
> +   drm_next_bridge_destroy(bridge);
> +
> /* Nothing else to free, we've got devm allocated memory */
>  }
>
> @@ -184,81 +171,10 @@ struct drm_bridge_funcs ptn3460_bridge_funcs = {
> .destroy = ptn3460_bridge_destroy,
>  };
>
> -int ptn3460_get_modes(struct drm_connector *connector)
> -{
> -   struct ptn3460_bridge *ptn_bridge;
> -   u8 *edid;
> -   int ret, num_modes;
> -   bool power_off;
> -
> -   ptn_bridge = container_of(connector, struct ptn3460_bridge, 
> connector);
> -
> -   if (ptn_bridge->edid)
> -   return drm_add_edid_modes(connector, ptn_bridge->edid);
> -
> -   power_off = !ptn_bridge->enabled;
> -   ptn3460_pre_enable(ptn_bridge->bridge);
> -
> -   edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
> -   if (!edid) {
> -   DRM_ERROR("Failed to allocate edid\n");
> -   return 0;
> -   }
> -
> -   ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
> -   EDID_LENGTH);
> -   if (ret) {
> -   kfree(edid);
> -   num_modes = 0;
> -   goto out;
> -   }
> -
> -   ptn_bridge->edid = (struct edid *)edid;
> -   drm_mode_connector_update_edid_property(connector, ptn_bridge->edid);
> -
> -   num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
> -
> -out:
> -   if (power_off)
> -   ptn3460_disable(ptn_bridge->bridge);
> -
> -   return num_modes;
> -}
> -
> -struct drm_encoder *ptn3460_best_encoder(struct drm_connector *connector)
> -{
> -   struct ptn3460_bridge *ptn_bridge;
> -
> -   ptn_bridge = container_of(connector, struct ptn3460_bridge, 
> connector);
> -
> -   return 

[PATCH V4 06/10] drm/bridge: Add a driver which binds drm_bridge with drm_panel

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> Add a dummy bridge which binds all of the drm_bridge callbacks
> to corresponding drm_panel callbacks.
>
> In theory, this is just a glue layer for the last bridge and
> the panel attached to it.
>
> This driver also implements the required drm_connector ops
> for the encoder(on which the entire bridge chain is hanging off).
>
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/bridge/Kconfig|7 ++
>  drivers/gpu/drm/bridge/Makefile   |1 +
>  drivers/gpu/drm/bridge/panel_binder.c |  193 
> +
>  include/drm/bridge/panel_binder.h |   44 
>  4 files changed, 245 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/panel_binder.c
>  create mode 100644 include/drm/bridge/panel_binder.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 884923f..e3fb487 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -3,3 +3,10 @@ config DRM_PTN3460
> depends on DRM
> select DRM_KMS_HELPER
> ---help---
> +
> +config DRM_PANEL_BINDER
> +   tristate "bridge panel binder"
> +   depends on DRM
> +   select DRM_KMS_HELPER
> +   select DRM_PANEL
> +   ---help---
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index b4733e1..ba8b5b8 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,3 +1,4 @@
>  ccflags-y := -Iinclude/drm
>
>  obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
> +obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
> diff --git a/drivers/gpu/drm/bridge/panel_binder.c 
> b/drivers/gpu/drm/bridge/panel_binder.c
> new file mode 100644
> index 000..93d976b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/panel_binder.c
> @@ -0,0 +1,193 @@
> +/*
> + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "drmP.h"
> +#include "drm_crtc.h"
> +#include "drm_crtc_helper.h"
> +
> +#include "bridge/panel_binder.h"
> +
> +struct panel_binder {
> +   struct drm_connectorconnector;
> +   struct i2c_client   *client;
> +   struct drm_encoder  *encoder;
> +   struct drm_bridge   *bridge;
> +   struct drm_panel*panel;
> +};
> +
> +static void panel_binder_pre_enable(struct drm_bridge *bridge)
> +{
> +   struct panel_binder *panel_binder = bridge->driver_private;
> +
> +   drm_panel_prepare(panel_binder->panel);
> +}
> +
> +static void panel_binder_enable(struct drm_bridge *bridge)
> +{
> +   struct panel_binder *panel_binder = bridge->driver_private;
> +
> +   drm_panel_enable(panel_binder->panel);
> +}
> +
> +static void panel_binder_disable(struct drm_bridge *bridge)
> +{
> +   struct panel_binder *panel_binder = bridge->driver_private;
> +
> +   drm_panel_disable(panel_binder->panel);
> +}
> +
> +static void panel_binder_post_disable(struct drm_bridge *bridge)
> +{
> +   struct panel_binder *panel_binder = bridge->driver_private;
> +
> +   drm_panel_unprepare(panel_binder->panel);
> +}
> +
> +void panel_binder_destroy(struct drm_bridge *bridge)
> +{
> +   struct panel_binder *panel_binder = bridge->driver_private;
> +
> +   drm_panel_detach(panel_binder->panel);
> +   drm_bridge_cleanup(bridge);
> +}
> +
> +struct drm_bridge_funcs panel_binder_funcs = {
> +   .pre_enable = panel_binder_pre_enable,
> +   .enable = panel_binder_enable,
> +   .disable = panel_binder_disable,
> +   .post_disable = panel_binder_post_disable,
> +   .destroy = panel_binder_destroy,
> +};
> +
> +static int panel_binder_mode_valid(struct drm_connector *connector,
> +struct drm_display_mode *mode)
> +{
> +   return MODE_OK;
> +}
> +
> +static int panel_binder_get_modes(struct drm_connector *connector)
> +{
> +   struct panel_binder *panel_binder;
> +
> +   panel_binder = container_of(connector, struct panel_binder, 
> connector);
> +
> +   return panel_binder->panel->funcs->get_modes(panel_binder->panel);
> +}
> +
> +static struct drm_encoder *panel_binder_best_encoder(struct drm_connector
> +   *connector)
> +{
> +   struct panel_binder *panel_binder;
> +
> +   panel_binder = container_of(connector, struct panel_binder, 
> connector);
> +
> +   return panel_binder->encoder;
> 

[PATCH V4 03/10] drm/exynos: dp: modify driver to support drm_panel

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> Add drm_panel controls to support powerup/down of the
> eDP panel, if one is present at the sink side.
>
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/exynos_dp.txt|2 +
>  drivers/gpu/drm/exynos/Kconfig |1 +
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   45 
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
>  4 files changed, 41 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt 
> b/Documentation/devicetree/bindings/video/exynos_dp.txt
> index 53dbccf..c029a09 100644
> --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> @@ -51,6 +51,8 @@ Required properties for dp-controller:
> LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> - display-timings: timings for the connected panel as described by
> Documentation/devicetree/bindings/video/display-timing.txt
> +   -edp-panel:
> +   phandle for the edp/lvds drm_panel node.
>
>  Optional properties for dp-controller:
> -interlaced:
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 178d2a9..fd1c070 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -52,6 +52,7 @@ config DRM_EXYNOS_DP
> bool "EXYNOS DRM DP driver support"
> depends on DRM_EXYNOS_FIMD && ARCH_EXYNOS && (DRM_PTN3460=n || 
> DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS)
> default DRM_EXYNOS
> +   select DRM_PANEL
> help
>   This enables support for DP device.
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 96b4e82..aca739d 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "exynos_drm_drv.h"
> @@ -1029,6 +1030,9 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
> drm_sysfs_connector_add(connector);
> drm_mode_connector_attach_encoder(connector, encoder);
>
> +   if (dp->edp_panel)
> +   drm_panel_attach(dp->edp_panel, >connector);
> +
> return 0;
>  }
>
> @@ -1063,11 +1067,13 @@ static void exynos_dp_poweron(struct exynos_dp_device 
> *dp)
> if (dp->dpms_mode == DRM_MODE_DPMS_ON)
> return;
>
> +   drm_panel_prepare(dp->edp_panel);
> clk_prepare_enable(dp->clock);
> exynos_dp_phy_init(dp);
> exynos_dp_init_dp(dp);
> enable_irq(dp->irq);
> exynos_dp_setup(dp);
> +   drm_panel_enable(dp->edp_panel);
>  }
>
>  static void exynos_dp_poweroff(struct exynos_dp_device *dp)
> @@ -1075,10 +1081,12 @@ static void exynos_dp_poweroff(struct 
> exynos_dp_device *dp)
> if (dp->dpms_mode != DRM_MODE_DPMS_ON)
> return;
>
> +   drm_panel_disable(dp->edp_panel);
> disable_irq(dp->irq);
> flush_work(>hotplug_work);
> exynos_dp_phy_exit(dp);
> clk_disable_unprepare(dp->clock);
> +   drm_panel_unprepare(dp->edp_panel);
>  }
>
>  static void exynos_dp_dpms(struct exynos_drm_display *display, int mode)
> @@ -1209,8 +1217,17 @@ err:
>  static int exynos_dp_dt_parse_panel(struct exynos_dp_device *dp)
>  {
> int ret;
> +   struct device_node *videomode_parent;
> +
> +   /* Receive video timing info from panel node
> +* if there is a panel node
> +*/
> +   if (dp->panel_node)
> +   videomode_parent = dp->panel_node;
> +   else
> +   videomode_parent = dp->dev->of_node;
>
> -   ret = of_get_videomode(dp->dev->of_node, >panel.vm,
> +   ret = of_get_videomode(videomode_parent, >panel.vm,
> OF_USE_NATIVE_MODE);
> if (ret) {
> DRM_ERROR("failed: of_get_videomode() : %d\n", ret);
> @@ -1224,16 +1241,10 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm_dev = data;
> struct resource *res;
> -   struct exynos_dp_device *dp;
> +   struct exynos_dp_device *dp = exynos_dp_display.ctx;
> unsigned int irq_flags;
> -
> int ret = 0;
>
> -   dp = devm_kzalloc(>dev, sizeof(struct exynos_dp_device),
> -   GFP_KERNEL);
> -   if (!dp)
> -   return -ENOMEM;
> -
> dp->dev = >dev;
> dp->dpms_mode = DRM_MODE_DPMS_OFF;
>
> @@ -1307,7 +1318,6 @@ static int exynos_dp_bind(struct device *dev, struct 
> device *master, void *data)
> disable_irq(dp->irq);
>
> dp->drm_dev = drm_dev;
> -   exynos_dp_display.ctx = 

[PATCH V4 05/10] drm/bridge: add helper functions to support bridge chain

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> Add helper functions to create bridge chain and to call the
> corresponding next_bridge functions.
>
> Signed-off-by: Ajay Kumar 
> Suggested-by: Rob Clark 
> ---
>  include/drm/drm_crtc.h |   72 
> 
>  1 file changed, 72 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index a7fac56..ba6a0d2 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -640,6 +640,7 @@ struct drm_bridge_funcs {
>  struct drm_bridge {
> struct drm_device *dev;
> struct list_head head;
> +   struct drm_bridge *next_bridge;
>
> struct drm_mode_object base;
>
> @@ -1148,6 +1149,77 @@ drm_property_blob_find(struct drm_device *dev, 
> uint32_t id)
> return mo ? obj_to_blob(mo) : NULL;
>  }
>
> +static inline int drm_bridge_add_to_chain(struct drm_bridge *head,
> + struct drm_bridge *last)
> +{
> +   struct drm_bridge *temp = head;
> +
> +   if (head && last) {
> +   while (temp->next_bridge)
> +   temp = temp->next_bridge;
> +
> +   temp->next_bridge = last;
> +   return 0;
> +   }
> +
> +   return -EINVAL;
> +}
> +
> +static inline void drm_next_bridge_mode_fixup(struct drm_bridge *bridge,
> +   const struct drm_display_mode *mode,
> +   struct drm_display_mode 
> *adjusted_mode)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->mode_fixup)
> +   bridge->next_bridge->funcs->mode_fixup(bridge->next_bridge,
> +   mode, adjusted_mode);
> +}
> +
> +static inline void drm_next_bridge_disable(struct drm_bridge *bridge)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->disable)
> +   bridge->next_bridge->funcs->disable(bridge->next_bridge);
> +}
> +
> +static inline void drm_next_bridge_post_disable(struct drm_bridge *bridge)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->post_disable)
> +   bridge->next_bridge->funcs->post_disable(bridge->next_bridge);
> +}
> +
> +static inline void drm_next_bridge_mode_set(struct drm_bridge *bridge,
> +   struct drm_display_mode *mode,
> +   struct drm_display_mode 
> *adjusted_mode)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->mode_set)
> +   bridge->next_bridge->funcs->mode_set(bridge->next_bridge,
> +   mode, adjusted_mode);
> +}
> +
> +static inline void drm_next_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->pre_enable)
> +   bridge->next_bridge->funcs->pre_enable(bridge->next_bridge);
> +}
> +
> +static inline void drm_next_bridge_enable(struct drm_bridge *bridge)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->enable)
> +   bridge->next_bridge->funcs->enable(bridge->next_bridge);
> +}
> +
> +static inline void drm_next_bridge_destroy(struct drm_bridge *bridge)
> +{
> +   if (bridge && bridge->next_bridge && bridge->next_bridge->funcs &&
> +   bridge->next_bridge->funcs->destroy)
> +   bridge->next_bridge->funcs->destroy(bridge->next_bridge);
> +}
> +
>  /* Plane list iterator for legacy (overlay only) planes. */
>  #define drm_for_each_legacy_plane(plane, planelist) \
> list_for_each_entry(plane, planelist, head) \
> --
> 1.7.9.5
>

[PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> This patch adds a simple driver to handle all the LCD and LED
> powerup/down routines needed to support eDP/LVDS panels.
>
> The LCD and LED units are usually powered up via regulators,
> and almost on all boards, we will have a BACKLIGHT_EN pin to
> enable/ disable the backlight.
> Sometimes, we can have LCD_EN switches as well.
>
> The routines in this driver can be used to control
> panel power sequence on such boards.
>
> Signed-off-by: Ajay Kumar 
> Signed-off-by: Rahul Sharma 
> ---
>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 
>  drivers/gpu/drm/panel/Kconfig  |   10 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-lvds.c |  262 
> 
>  4 files changed, 323 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>
> diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt 
> b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> new file mode 100644
> index 000..7cb6084
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
> @@ -0,0 +1,50 @@
> +panel interface for eDP/lvds panels
> +
> +Required properties:
> +  - compatible: "panel-lvds"
> +
> +Optional properties:
> +   -lcd-en-gpio:
> +   panel LCD poweron GPIO.
> +   Indicates which GPIO needs to be powered up as output
> +   to powerup/enable the switch to the LCD panel.
> +   -led-en-gpio:
> +   panel LED enable GPIO.
> +   Indicates which GPIO needs to be powered up as output
> +   to enable the backlight.
> +   -panel-prepare-delay:
> +   delay value in ms required for panel_prepare process
> +   Delay in ms needed for the panel LCD unit to
> +   powerup completely.
> +   ex: delay needed till eDP panel throws HPD.
> +   delay needed so that we cans tart reading edid.
> +   -panel-enable-delay:
> +   delay value in ms required for panel_enable process
> +   Delay in ms needed for the panel backlight/LED unit
> +   to powerup, and delay needed between video_enable and
> +   backlight_enable.
> +   -panel-disable-delay:
> +   delay value in ms required for panel_disable process
> +   Delay in ms needed for the panel backlight/LED unit
> +   powerdown, and delay needed between backlight_disable
> +   and video_disable.
> +   -panel-unprepare-delay:
> +   delay value in ms required for panel_post_disable process
> +   Delay in ms needed for the panel LCD unit to
> +   to powerdown completely, and the minimum delay needed
> +   before powering it on again.
> +   -panel-width-mm: physical panel width [mm]
> +   -panel-height-mm: physical panel height [mm]
> +
> +Example:
> +
> +   panel-lvds {
> +   compatible = "panel-lvds";
> +   led-en-gpio = < 0 1>;
> +   panel-prepare-delay = <40>;
> +   panel-enable-delay = <20>;
> +   panel-disable-delay = <20>;
> +   panel-unprepare-delay = <30>;
> +   panel-width-mm = <256>;
> +   panel-height-mm = <144>;
> +   };
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4ec874d..8fe7ee5 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -30,4 +30,14 @@ config DRM_PANEL_S6E8AA0
> select DRM_MIPI_DSI
> select VIDEOMODE_HELPERS
>
> +config DRM_PANEL_EDP_LVDS
> +   tristate "support for eDP/LVDS panels"
> +   depends on OF && DRM_PANEL
> +   select VIDEOMODE_HELPERS
> +   help
> + DRM panel driver for direct eDP panels or LVDS connected
> + via DP bridges, that need at most a regulator for LCD unit,
> + a regulator for LED unit and/or enable GPIOs for LCD or LED units.
> + Delay values can also be specified to support powerup and
> + powerdown process.
>  endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 8b92921..eaafa01 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
>  obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
>  obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
> +obj-$(CONFIG_DRM_PANEL_EDP_LVDS) += panel-lvds.o
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
> b/drivers/gpu/drm/panel/panel-lvds.c
> new file mode 100644
> index 000..2124fcb
> --- 

[PATCH V4 02/10] drm/panel: add prepare and unprepare routines

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar  
wrote:
> Most of the panels need an init sequence as mentioned below:
> -- poweron LCD unit/LCD_EN
> -- start video data
> -- poweron LED unit/BACKLIGHT_EN
> And, a de-init sequence as mentioned below:
> -- poweroff LED unit/BACKLIGHT_EN
> -- stop video data
> -- poweroff LCD unit/LCD_EN
> With existing callbacks for drm panel, we cannot accomodate such panels,
> since only two callbacks, i.e "panel_enable" and panel_disable are supported.
>
> This patch adds:
> -- "prepare" callback which can be called before
> the actual video data is on, and then call the "enable"
> callback after the video data is available.
>
> -- "unprepare" callback which can be called after
> the video data is off, and use "disable" callback
> to do something before switching off the video data.
>
> Now, we can easily map the above scenario as shown below:
> poweron LCD unit/LCD_EN = "prepare" callback
> poweron LED unit/BACKLIGHT_EN = "enable" callback
> poweroff LED unit/BACKLIGHT_EN = "disable" callback
> poweroff LCD unit/LCD_EN = "unprepare" callback
>
> Signed-off-by: Ajay Kumar 
> ---
>  include/drm/drm_panel.h |   18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index c2ab77a..9addc69 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -31,7 +31,9 @@ struct drm_device;
>  struct drm_panel;
>
>  struct drm_panel_funcs {
> +   int (*unprepare)(struct drm_panel *panel);
> int (*disable)(struct drm_panel *panel);
> +   int (*prepare)(struct drm_panel *panel);
> int (*enable)(struct drm_panel *panel);
> int (*get_modes)(struct drm_panel *panel);
>  };
> @@ -46,6 +48,14 @@ struct drm_panel {
> struct list_head list;
>  };
>
> +static inline int drm_panel_unprepare(struct drm_panel *panel)
> +{
> +   if (panel && panel->funcs && panel->funcs->unprepare)
> +   return panel->funcs->unprepare(panel);
> +
> +   return panel ? -ENOSYS : -EINVAL;
> +}
> +
>  static inline int drm_panel_disable(struct drm_panel *panel)
>  {
> if (panel && panel->funcs && panel->funcs->disable)
> @@ -54,6 +64,14 @@ static inline int drm_panel_disable(struct drm_panel 
> *panel)
> return panel ? -ENOSYS : -EINVAL;
>  }
>
> +static inline int drm_panel_prepare(struct drm_panel *panel)
> +{
> +   if (panel && panel->funcs && panel->funcs->prepare)
> +   return panel->funcs->prepare(panel);
> +
> +   return panel ? -ENOSYS : -EINVAL;
> +}
> +
>  static inline int drm_panel_enable(struct drm_panel *panel)
>  {
> if (panel && panel->funcs && panel->funcs->enable)
> --
> 1.7.9.5
>

[PATCH V4 01/10] drm/exynos: Move DP setup out of hotplug workqueue

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar  
wrote:
> Move the DP training and video enable from the hotplug handler into
> a seperate function and call the same during dpms ON.
>
> With existing code, DP HPD should be generated just few ms before
> calling enable_irq in dp_poweron.
>
> This patch removes that stringent time constraint.
>
> Signed-off-by: Ajay Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c |   11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 5e05dbc..96b4e82 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -875,10 +875,18 @@ static irqreturn_t exynos_dp_irq_handler(int irq, void 
> *arg)
>  static void exynos_dp_hotplug(struct work_struct *work)
>  {
> struct exynos_dp_device *dp;
> -   int ret;
>
> dp = container_of(work, struct exynos_dp_device, hotplug_work);
>
> +   if (dp->drm_dev)
> +   drm_helper_hpd_irq_event(dp->drm_dev);
> +}
> +
> +static void exynos_dp_setup(void *in_ctx)
> +{
> +   struct exynos_dp_device *dp = in_ctx;
> +   int ret;
> +
> ret = exynos_dp_detect_hpd(dp);
> if (ret) {
> /* Cable has been disconnected, we're done */
> @@ -1059,6 +1067,7 @@ static void exynos_dp_poweron(struct exynos_dp_device 
> *dp)
> exynos_dp_phy_init(dp);
> exynos_dp_init_dp(dp);
> enable_irq(dp->irq);
> +   exynos_dp_setup(dp);
>  }
>
>  static void exynos_dp_poweroff(struct exynos_dp_device *dp)
> --
> 1.7.9.5
>

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

[Ajay kumar]

ping.

On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar  
wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> I have tested this after adding few DT changes for exynos5250-snow,
> exynos5420-peach-pit and exynos5800-peach-pi boards.
>
> This patchset also consolidates various inputs from the drm community
> regarding the bridge chaining concept:
> (1) [RFC V2 0/3] drm/bridge: panel and chaining
> http://www.spinics.net/lists/linux-samsung-soc/msg30160.html
> (2) [RFC V3 0/3] drm/bridge: panel and chaining
> http://www.spinics.net/lists/linux-samsung-soc/msg30507.html
>
> Changes since V2:
> -- Address comments from Jingoo Han for ps8622 driver
> -- Address comments from Daniel, Rob and Thierry regarding
>bridge chaining
> -- Address comments from Thierry regarding the names for
>new drm_panel functions
>
> Changes since V3:
> -- Remove hotplug based initialization of exynos_dp
> -- Make exynos_dp work directly with drm_panel, remove
>dependency on panel_binder
> -- Minor cleanups in panel_binder and panel_lvds driver
>
> The following patches can be divided into 2 groups:
> patches 1 to 4: add drm_panel support to exynos_dp(peach-pi)
> patches 5 to 10: chaining of bridges and drm_panel(snow and peach-pit)
>
> Ajay Kumar (8):
>   [PATCH V4 1/10] drm/exynos: Move DP setup out of hotplug workqueue
>   [PATCH V4 2/10] drm/panel: add prepare and unprepare routines
>   [PATCH V4 3/10] drm/exynos: dp: modify driver to support drm_panel
>   [PATCH V4 4/10] drm/panel: Add driver for lvds/edp based panels
>   [PATCH V4 5/10] drm/bridge: add helper functions to support bridge chain
>   [PATCH V4 6/10] drm/bridge: Add a driver which binds drm_bridge with 
> drm_panel
>   [PATCH V4 7/10] drm/bridge: ptn3460: Support bridge chaining
>   [PATCH V4 8/10] drm/exynos: dp: create bridge chain using ptn3460 and
>   panel_binder
>
> Vincent Palatin (1):
>   [PATCH V4 9/10] drm/bridge: Add ps8622/ps8625 bridge driver
>
> Rahul Sharma (1):
>   [PATCH V4 10/10] drm/exynos: Add ps8622 lvds bridge discovery to DP driver
>
>  .../devicetree/bindings/drm/bridge/ps8622.txt  |   21 +
>  .../devicetree/bindings/panel/panel-lvds.txt   |   50 +++
>  .../devicetree/bindings/video/exynos_dp.txt|2 +
>  drivers/gpu/drm/bridge/Kconfig |   15 +
>  drivers/gpu/drm/bridge/Makefile|2 +
>  drivers/gpu/drm/bridge/panel_binder.c  |  193 
>  drivers/gpu/drm/bridge/ps8622.c|  475 
> 
>  drivers/gpu/drm/bridge/ptn3460.c   |  136 +-
>  drivers/gpu/drm/exynos/Kconfig |1 +
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   87 +++-
>  drivers/gpu/drm/exynos/exynos_dp_core.h|2 +
>  drivers/gpu/drm/panel/Kconfig  |   10 +
>  drivers/gpu/drm/panel/Makefile |1 +
>  drivers/gpu/drm/panel/panel-lvds.c |  262 +++
>  include/drm/bridge/panel_binder.h  |   44 ++
>  include/drm/bridge/ps8622.h|   41 ++
>  include/drm/bridge/ptn3460.h   |   15 +-
>  include/drm/drm_crtc.h |   72 +++
>  include/drm/drm_panel.h|   18 +
>  19 files changed, 1309 insertions(+), 138 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
>  create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
>  create mode 100644 drivers/gpu/drm/bridge/panel_binder.c
>  create mode 100644 drivers/gpu/drm/bridge/ps8622.c
>  create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
>  create mode 100644 include/drm/bridge/panel_binder.h
>  create mode 100644 include/drm/bridge/ps8622.h
>
> --
> 1.7.9.5
>

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #25 from Alex Deucher  ---
(In reply to comment #24)
> Created attachment 101420 [details]
> dmesg with working bapm patch
> 
> I can confirm that the latter patch (attachment 101191 [details] [review])
> solves the issue for me, I haven't tried the earlier patch because it didn't
> work for Collin. I can re-test that if that's still useful.
> 

Probably not necessary.

> Attaching dmesg; I compared the probed power states and they appear similar.
> What's bapm?

It allows the CPU and GPU to share TDP headroom.  E.g., if the CPU isn't busy,
the the GPU can user higher performance states longer and vice versa.

-- 
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/20140620/3cb256cd/attachment.html>

[PATCH 0/3] Remove devm_request_and_ioremap()

[Jingoo Han]

On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote:
> 
> Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of
> devm_request_and_ioremap, yet some remains are still left. Remove the last two
> users, and let the function rest in peace. I'd suggest that this series is
> picked up as a whole to have that case finally closed. Greg? Are you 
> interested
> in picking it up?

(+cc Greg Kroah-Hartman)

I already sent the same patch as one single patch to Greg Kroah-Hartman. [1]
Also, it was accepted by Greg Kroah-Hartman. [2] Thank you.

[1] https://lkml.org/lkml/2014/6/11/26
[2] https://lkml.org/lkml/2014/6/11/649

Best regards,
Jingoo Han

> 
>Wolfram
> 
> 
> Tushar Behera (2):
>   DRM: Armada: Use devm_ioremap_resource
>   lib: devres: Remove deprecated devm_request_and_ioremap
> 
> Wolfram Sang (1):
>   bus: brcmstb_gisb: Use devm_ioremap_resource
> 
>  Documentation/driver-model/devres.txt |  1 -
>  drivers/bus/brcmstb_gisb.c|  6 +++---
>  drivers/gpu/drm/armada/armada_crtc.c  |  8 +++-
>  include/linux/device.h|  2 --
>  lib/devres.c  | 28 
>  5 files changed, 6 insertions(+), 39 deletions(-)
> 
> --
> 2.0.0

[PATCH 14/9] drm: Kick start vblank interrupts at drm_vblank_on()

[Matt Roper]

On Mon, Jun 02, 2014 at 11:15:51AM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrj?l? 
> 
> If the user is interested in getting accurate vblank sequence
> numbers all the time they may disable the vblank disable timer
> entirely. In that case it seems appropriate to kick start the
> vblank interrupts already from drm_vblank_on().
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/drm_irq.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 82a039a..6376d96 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1126,9 +1126,12 @@ void drm_vblank_on(struct drm_device *dev, int crtc)
>   vblank->last =
>   (dev->driver->get_vblank_counter(dev, crtc) - 1) &
>   dev->max_vblank_count;
> -
> - /* re-enable interrupts if there's are users left */
> - if (atomic_read(>refcount) != 0)
> + /*
> +  * re-enable interrupts if there are users left, or the
> +  * user wishes vblank interrupts to be enabled all the time.
> +  */
> + if (atomic_read(>refcount) != 0 ||
> + (!dev->vblank_disable_immediate && drm_vblank_offdelay < 0))

As noted on patch 10, wouldn't it make sense for the user-provided
module parameter override the driver ability to disable immediately in
this case where they've specifically asked for "never disable?"

Otherwise, patches 12-14 are 

Reviewed-by: Matt Roper 

>   WARN_ON(drm_vblank_enable(dev, crtc));
>   spin_unlock_irqrestore(>vbl_lock, irqflags);
>  }
> -- 
> 1.8.5.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[Intel-gfx] [PATCH v2 9/9] drm/i915: Leave interrupts enabled while disabling crtcs during suspend

[Matt Roper]

On Mon, May 26, 2014 at 02:46:32PM +0300, ville.syrjala at linux.intel.com 
wrote:
> From: Ville Syrj?l? 
> 
> The new watermaek update mechanism requires interrupts to work

s/watermaek/watermark/

> correctly. Because of this we need interrupts while disabling crtcs
> during suspend. So move the irq disable to happen a bit later.

I'm not super familiar with this code, so I might be missing something,
but won't this cause us to call drm_irq_uninstall() and then potentially
dev->driver->get_vblank_counter() while the pipe is disabled (which will
result in get_vblank_counter() returning 0)?

Also, does it cause any problems if if our interrupt handler races with
intel_disable_pipe()?


Matt

> 
> This also avoid clobbering the vblank.last count in case the
> vblank interrupt was already disabled earlier by the timer.
> In that case drm_vblank_off() will need .last to be correct so
> that it can update the user visible vblank counter value
> approapriately.
> 
> v2: Note vblank counter in commit message
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4619c9e..21554a0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -524,7 +524,6 @@ static int i915_drm_freeze(struct drm_device *dev)
>   return error;
>   }
>  
> - drm_irq_uninstall(dev);
>   dev_priv->enable_hotplug_processing = false;
>  
>   intel_disable_gt_powersave(dev);
> @@ -541,6 +540,8 @@ static int i915_drm_freeze(struct drm_device *dev)
>   }
>   mutex_unlock(>mode_config.mutex);
>  
> + drm_irq_uninstall(dev);
> +
>   intel_modeset_suspend_hw(dev);
>   }
>  
> -- 
> 1.8.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH] drm/msm: Implement msm drm fb_mmap callback function

[Hai Li]

This change implements msm drm specific fb_mmap function for fb device
to properly map the fb address to userspace.

Signed-off-by: Hai Li 
Signed-off-by: Stephane Viau 
---
 drivers/gpu/drm/msm/msm_fbdev.c | 38 --
 1 file changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index a752ab8..2694e90 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -19,6 +19,11 @@

 #include "drm_crtc.h"
 #include "drm_fb_helper.h"
+#include "msm_gem.h"
+
+extern int msm_gem_mmap_obj(struct drm_gem_object *obj,
+   struct vm_area_struct *vma);
+static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma);

 /*
  * fbdev funcs, to implement legacy fbdev interface on top of drm driver
@@ -43,6 +48,7 @@ static struct fb_ops msm_fb_ops = {
.fb_fillrect = sys_fillrect,
.fb_copyarea = sys_copyarea,
.fb_imageblit = sys_imageblit,
+   .fb_mmap = msm_fbdev_mmap,

.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
@@ -51,6 +57,31 @@ static struct fb_ops msm_fb_ops = {
.fb_setcmap = drm_fb_helper_setcmap,
 };

+static int msm_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *helper = (struct drm_fb_helper *)info->par;
+   struct msm_fbdev *fbdev = to_msm_fbdev(helper);
+   struct drm_gem_object *drm_obj = fbdev->bo;
+   struct drm_device *dev = helper->dev;
+   int ret;
+
+   if (drm_device_is_unplugged(dev))
+   return -ENODEV;
+
+   mutex_lock(>struct_mutex);
+
+   ret = drm_gem_mmap_obj(drm_obj, drm_obj->size, vma);
+
+   mutex_unlock(>struct_mutex);
+
+   if (ret) {
+   pr_err("%s:drm_gem_mmap_obj fail\n", __func__);
+   return ret;
+   }
+
+   return msm_gem_mmap_obj(drm_obj, vma);
+}
+
 static int msm_fbdev_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
 {
@@ -104,8 +135,11 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,

mutex_lock(>struct_mutex);

-   /* TODO implement our own fb_mmap so we don't need this: */
-   msm_gem_get_iova_locked(fbdev->bo, 0, );
+   ret = msm_gem_get_iova_locked(fbdev->bo, 0, );
+   if (ret) {
+   dev_err(dev->dev, "failed to get buffer obj iova: %d\n", ret);
+   goto fail;
+   }

fbi = framebuffer_alloc(0, dev->dev);
if (!fbi) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/3] Remove devm_request_and_ioremap()

[Wolfram Sang]

On Thu, Jun 19, 2014 at 07:59:57PM -0700, 'Greg Kroah-Hartman' wrote:
> On Fri, Jun 20, 2014 at 11:36:03AM +0900, Jingoo Han wrote:
> > On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote:
> > > 
> > > Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of
> > > devm_request_and_ioremap, yet some remains are still left. Remove the 
> > > last two
> > > users, and let the function rest in peace. I'd suggest that this series is
> > > picked up as a whole to have that case finally closed. Greg? Are you 
> > > interested
> > > in picking it up?
> > 
> > (+cc Greg Kroah-Hartman)
> > 
> > I already sent the same patch as one single patch to Greg Kroah-Hartman. [1]
> > Also, it was accepted by Greg Kroah-Hartman. [2] Thank you.
> > 
> > [1] https://lkml.org/lkml/2014/6/11/26
> > [2] https://lkml.org/lkml/2014/6/11/649
> 
> Yeah, I'll go apply that right now while I'm remembering it :)

For the patch above:

Reviewed-by: Wolfram Sang 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/a3f4ece6/attachment-0001.sig>

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Daniel Vetter]

On Fri, Jun 20, 2014 at 1:42 AM, Greg KH  wrote:
>> I'm actually concerned about this trend.  Downgrading things to WARN_ON
>> can allow a security bug in the kernel to continue to exist, for
>> example, or make the error message disappear.
>
> A BUG_ON makes any error message disappear pretty quickly :)
>
> I'm talking about foolish "ASSERT-like" BUG_ON that driver authors like
> to add to their code when writing it to catch things they are messing
> up.  After the code is working, they should be removed, like this one.

Well except for cases where it's super performance critical I like to
retain these WARN_ON asserts (not BUG_ON). "Is the logic sufficient
locked down with WARN_ONs?" is actually one of the main review
criteria I have for i915 patches, especially on the modeset side.
They're a bit an annoyance for distro's since they result in a
constant (but ever shifting) stream of backtraces, but for me they
serve as an excellent early warning sign when our driver has yet again
lost its marbles (or at least some) way before something user-visibly
bad happens.

And for those screaming that these checks should be hidden behind a
config option and only enabled for validation: Nope, there's too many
combinations of display hardware out there and I simply need our
entire user base to serve as guinea pigs. There's really no other way
to validate this mess called drm/i915.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

AGP GART clarifications, please!

[Émeric MASCHINO]

2014-06-20 2:06 GMT+02:00 Dave Airlie :
> So to run in AGP mode you need a chipset specific driver to manage the
> chipsets AGP GART and other features, that the GPU drivers can talk
> to.

Do the GPU drivers then talk differently to the graphics card when
there's a GART? I mean, are there different code paths in the GPU
drivers depending on the presence of GART or not? Or is the command
stream built by the DRI module exactly the same with or without GART?
Next, in the kernel DRM, are there different code paths taken
depending on the presence of GART or not? Or is it something
"transparently" (from the DRI module/kernel DRM point of view) managed
at the hardware level: I mean, the exact same data are sent to the
graphics card through the DRI module and kernel DRM, but depending on
the presence of GART or not, the data aren't handled the same at the
hardware level and are "intercepted" and managed differently (e.g.
reorganized) by the GART before being effectively delivered to the
graphics adapter?

> I'm not sure how best to measure a speed difference, it should be noticable 
> with
> games and stuff, maybe not with plain desktop usage, anything that up
> or downloads
> lots of stuff or uses main RAM for textures.

So, my OpenSceneGraph datasets, old Quake II/III demos and
SPECviewperf 7.1.1 benchmark are too limited nowadays ;-) But they
were contemporary to my hardware, so should be representative of this
era.

Thanks Dave for this first batch of explanations,

 ?meric

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Daniel Vetter]

On Fri, Jun 20, 2014 at 12:39 AM, H. Peter Anvin  wrote:
>>> Aside: This is a pet peeve of mine and recently I've switched to
>>> rejecting all patch that have a BUG_ON, period.
>>
>> Please do, I have been for a few years now as well for the same reasons
>> you cite.
>>
>
> I'm actually concerned about this trend.  Downgrading things to WARN_ON
> can allow a security bug in the kernel to continue to exist, for
> example, or make the error message disappear.
>
> I am wondering if the right thing here isn't to have a user (command
> line?) settable policy as to how to proceed on an assert violation,
> instead of hardcoding it at compile time.

I should clarify: If it smells like the issue is a failure of our
ioctl/syscall validation code to catch crap, BUG_ON is the right
choice. And fundamentally I've had this rule since 1-2 years now, the
only recent change I've done is switch my scripts from warning by
default if there's a new BUG_ON to rejecting by default. Mostly
because I'm lazy and let too many BUG_ONs pass through by default.

Also if you add a new interface to i915 I'll make damn sure you supply
a full set of nasty testcases to abuse the ioctl hard. In the end it's
a tradeoff and overall I don't think I'm compromising security with my
current set of rules.

Also, people don't (yet) terribly care about data integrity as soon as
their data has passed once through a gpu.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

[Alex Deucher]

On Fri, Jun 20, 2014 at 10:11 AM, Laszlo Kertesz
 wrote:
>
> On 6/20/2014 4:30 PM, bugzilla-daemon at freedesktop.org wrote:
>
> Comment # 25 on bug 72921 from Alex Deucher
>
> (In reply to comment #24)
>> Created attachment 101420 [details]
>> dmesg with working bapm patch
>>
>> I can confirm that the latter patch (attachment 101191 [details] [review]
>> [review])
>> solves the issue for me, I haven't tried the earlier patch because it
>> didn't
>> work for Collin. I can re-test that if that's still useful.
>>
>
> Probably not necessary.
>
>> Attaching dmesg; I compared the probed power states and they appear
>> similar.
>> What's bapm?
>
> It allows the CPU and GPU to share TDP headroom.  E.g., if the CPU isn't
> busy,
> the the GPU can user higher performance states longer and vice versa.
>
> And what happens if its disabled?
> Because as it stands now, the CPU and GPU are still throttled if heated up.
> The CPU's turbo core is disabled, is it the same for the GPU?
>

Right.  They don't share the headroom if it is disabled.

Alex

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

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 19.06.2014 19:20, Marek Ol??k wrote:
> Hi Michel,
> 
> 3.15 doesn't contain Christian's fix yet, so it should be always
> broken for everybody. The fix is currently only in 3.16.
> 
> Alternatively, you can cherry-pick the fix to 3.15, but it doesn't
> apply cleanly.

That's a good point. Sorry, I should have mentioned I've been testing
with the GART poisoning fix backported to 3.15.


> There is a workaround in 3.15 which disables sDMA and uses CP DMA for
> copying buffers. It seems to help Christian's machine, but not mine.

I've been testing with CP DMA on Bonaire FWIW.


-- 
Earthling Michel D?nzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

AGP GART clarifications, please!

[Dave Airlie]

On 20 June 2014 03:17, ?meric MASCHINO  wrote:
> DRI gurus,
>
> If I'm not mistaken, the current Linux graphics stack is as follows
> (excluding Wayland protocol and LLVM or GLAMOR-based approaches):
>
> X11/OpenGL app -> libX/Mesa -> DDX driver/Mesa DRI module -> kernel
> DRM -> hardware
>
> What's unclear to me is, in the case of an AGP graphics adapter, where
> does the AGP GART takes place in this stack (if applicable)?
>

AGP support is just by the kernel drivers now with KMS.

AGP is just a GART that sits on the chipset side of the AGP port, along
with faster lanes speed than plain PCI and wierd enhancement like fastwrite.

With early PCI GPUs they couldn't access data in main memory like
textures you had to DMA stuff to the GPU. Some GPUs got PCI GARTs
which were very simple lookup tables from GPU linear to host page address,
however these suffered from lots of bandwidth issues when updating them,
so AGP put a GART on the chipset side to do the same. PCIE uses GARTs
back on the GPU side.

So to run in AGP mode you need a chipset specific driver to manage the
chipsets AGP GART and other features, that the GPU drivers can talk
to.

> Obviously, this AGP graphics adapter nevertheless works flawlessly
> without AGP GART compiled in kernel or as module. This is at least
> true for the open source stack, I've tested it. Is my AGP graphics
> adapter thus running in what's known as PCI/PCIe mode? I've read all
> the AGP scatter/gather, texturing and fast writes things, but I can't
> see any difference performance-wise between having AGP GART compiled
> in kernel or as a module and no AGP GART. Is it because my usage
> doesn't stress the graphics subsystem enough or is it because PCI/PCIe
> mode is so amazing that AGP GART doesn't provide any performance
> enhancements? AGP GART however provides me nice stability issues ;-)

I'm not sure how best to measure a speed difference, it should be noticable with
games and stuff, maybe not with plain desktop usage, anything that up
or downloads
lots of stuff or uses main RAM for textures.

Dave.

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #24 from Arno Schuring  ---
Created attachment 101420
  --> https://bugs.freedesktop.org/attachment.cgi?id=101420=edit
dmesg with working bapm patch

I can confirm that the latter patch (attachment 101191) solves the issue for
me, I haven't tried the earlier patch because it didn't work for Collin. I can
re-test that if that's still useful.

Attaching dmesg; I compared the probed power states and they appear similar.
What's bapm?

-- 
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/20140620/229a312f/attachment.html>

[PATCH 0/3] Remove devm_request_and_ioremap()

[Wolfram Sang]

> > I already sent the same patch as one single patch to Greg Kroah-Hartman. [1]
> > Also, it was accepted by Greg Kroah-Hartman. [2] Thank you.
> > 
> > [1] https://lkml.org/lkml/2014/6/11/26
> > [2] https://lkml.org/lkml/2014/6/11/649
> 
> Yeah, I'll go apply that right now while I'm remembering it :)

Yay, great! Thank you both!

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/55c601e2/attachment.sig>

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Dave Airlie]

On 20 June 2014 04:19, Greg KH  wrote:
> On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote:
>> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH  
>> wrote:
>> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote:
>> >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH  
>> >> wrote:
>> >> > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
>> >> >> +#define CREATE_TRACE_POINTS
>> >> >> +#include 
>> >> >> +
>> >> >> +EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on);
>> >> >> +EXPORT_TRACEPOINT_SYMBOL(fence_emit);
>> >> >
>> >> > Are you really willing to live with these as tracepoints for forever?
>> >> > What is the use of them in debugging?  Was it just for debugging the
>> >> > fence code, or for something else?
>> >> >
>> >> >> +/**
>> >> >> + * fence_context_alloc - allocate an array of fence contexts
>> >> >> + * @num: [in]amount of contexts to allocate
>> >> >> + *
>> >> >> + * This function will return the first index of the number of fences 
>> >> >> allocated.
>> >> >> + * The fence context is used for setting fence->context to a unique 
>> >> >> number.
>> >> >> + */
>> >> >> +unsigned fence_context_alloc(unsigned num)
>> >> >> +{
>> >> >> + BUG_ON(!num);
>> >> >> + return atomic_add_return(num, _context_counter) - num;
>> >> >> +}
>> >> >> +EXPORT_SYMBOL(fence_context_alloc);
>> >> >
>> >> > EXPORT_SYMBOL_GPL()?  Same goes for all of the exports in here.
>> >> > Traditionally all of the driver core exports have been with this
>> >> > marking, any objection to making that change here as well?
>> >>
>> >> tbh, I prefer EXPORT_SYMBOL()..  well, I'd prefer even more if there
>> >> wasn't even a need for EXPORT_SYMBOL_GPL(), but sadly it is a fact of
>> >> life.  We already went through this debate once with dma-buf.  We
>> >> aren't going to change $evil_vendor's mind about non-gpl modules.  The
>> >> only result will be a more flugly convoluted solution (ie. use syncpt
>> >> EXPORT_SYMBOL() on top of fence EXPORT_SYMBOL_GPL()) just as a
>> >> workaround, with the result that no-one benefits.
>> >
>> > It has been proven that using _GPL() exports have caused companies to
>> > release their code "properly" over the years, so as these really are
>> > Linux-only apis, please change them to be marked this way, it helps
>> > everyone out in the end.
>>
>> Well, maybe that is the true in some cases.  But it certainly didn't
>> work out that way for dma-buf.  And I think the end result is worse.
>>
>> I don't really like coming down on the side of EXPORT_SYMBOL() instead
>> of EXPORT_SYMBOL_GPL(), but if we do use EXPORT_SYMBOL_GPL() then the
>> result will only be creative workarounds using the _GPL symbols
>> indirectly by whatever is available via EXPORT_SYMBOL().  I don't
>> really see how that will be better.
>
> You are saying that you _know_ companies will violate our license, so
> you should just "give up"?  And how do you know people aren't working on
> preventing those "indirect" usages as well?  :)
>
> Sorry, I'm not going to give up here, again, it has proven to work in
> the past in changing the ways of _very_ large companies, why stop now?

I've found large companies shipping lots of hw putting pressure on
other large/small companies seems to be only way this has ever
happened, we'd like to cover that up and say its some great GPL
enforcement thing.

To be honest, author's choice is how I'd treat this.

Personally I think _GPL is broken by design, and that Linus's initial
point for them has been so diluted by random lobby groups asking for
every symbol to be _GPL that they are becoming effectively pointless
now. I also dislike the fact that the lobby groups don't just bring
violators to court. I'm also sure someone like the LF could have a
nice income stream if Linus gave them permission to enforce his
copyrights.

But anyways, has someone checked that iOS or Windows don't have a
fence interface? so we know that this is a Linux only interface and
any works using it are derived? Say the nvidia driver isn't a derived
work now, will using this interface magically translate it into a
derived work, so we can go sue them? I don't think so.

But its up to Maarten and Rob, and if they say no _GPL then I don't
think we should be overriding authors intents.

Dave.

[Bug 65121] Possible memory leak in qxl drm driver

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

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

--- Comment #11 from xerofoify at gmail.com ---
It seems to be only the opener or maintainer of this subsystem who can close
it.
Cheers Nick

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

[Bug 65121] Possible memory leak in qxl drm driver

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

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

--- Comment #10 from xerofoify at gmail.com ---
Our you sure, other people seem to 
be able to do it with other bugs.
Thanks Nick

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

[Bug 65121] Possible memory leak in qxl drm driver

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

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

--- Comment #9 from Dave Airlie  ---
kernel bugzilla sucks I can't change bug states.

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

[Bug 62541] Kernel oops/panic during system boot with systemd - "Unable to handle kernel NULL pointer dereference"

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

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

xerofoify at gmail.com changed:

   What|Removed |Added

 CC||xerofoify at gmail.com

--- Comment #2 from xerofoify at gmail.com ---
Is this bug closed? Seems the problem is with systemd and not the 
kernel. Can we please close this bug as it's fairly old as of me
writing this in June 2014.
Thanks A Fellow Developer,
Nick

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

[Bug 65121] Possible memory leak in qxl drm driver

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

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

xerofoify at gmail.com changed:

   What|Removed |Added

 CC||xerofoify at gmail.com

--- Comment #8 from xerofoify at gmail.com ---
IF the attachment here seems to fix this I would close this.
Just a friendly reminder,
Nick

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

[PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}

[Siarhei Siamashka]

On Fri,  4 Apr 2014 17:22:01 +0800
Daniel Kurtz  wrote:

> Kernel access to the eyxnos fbdev framebuffer is via its gem object's
> kernel mapping (kvaddr, stored in info->screen_base).
> 
> User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
> These functions also only use screen_base/screen_size().
> 
> Therefore, it is not necessary to set fix->smem_{start,len} or
> fix->mmio_{start,len} fields.
> 
> This avoids leaking kernel, physical and dma mapped addresses to user
> space via the ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO.
> 
> Signed-off-by: Daniel Kurtz 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 5fa342e..2dcc589 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -123,14 +123,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
> *helper,
>  
>   dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
>   fbi->screen_base = buffer->kvaddr + offset;
> - if (is_drm_iommu_supported(dev))
> - fbi->fix.smem_start = (unsigned long)
> - (page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
> - else
> - fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
> -
>   fbi->screen_size = size;
> - fbi->fix.smem_len = size;

Can we keep proper initialization of 'smem_len'? Some userland
applications use it for calculating the size for mmap:


http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571

>  
>   return 0;
>  }

Basically, this patch breaks the xf86-video-fbdev ddx and some users
are already unhappy.

-- 
Best regards,
Siarhei Siamashka

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

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

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

--- Comment #6 from Michel D?nzer  ---
Can you try if it still happens with Alex's drm-fixes-3.16 tree?

-- 
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/20140620/6acfe9b1/attachment.html>

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

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

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

--- Comment #5 from Michel D?nzer  ---
Please attach the Xorg.0.log file and the output of dmesg, preferably captured
after the problem occurred.

-- 
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/20140620/5d1e448f/attachment-0001.html>

[PATCH] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig

[Fabio Estevam]

From: Fabio Estevam 

SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry.

Signed-off-by: Fabio Estevam 
---
 drivers/gpu/ipu-v3/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
index 2f228a2..8696d20 100644
--- a/drivers/gpu/ipu-v3/Kconfig
+++ b/drivers/gpu/ipu-v3/Kconfig
@@ -1,6 +1,6 @@
 config IMX_IPUV3_CORE
tristate "IPUv3 core support"
-   depends on SOC_IMX5 || SOC_IMX6Q || SOC_IMX6SL || ARCH_MULTIPLATFORM
+   depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
depends on RESET_CONTROLLER
help
  Choose this if you have a i.MX5/6 system and want to use the Image
-- 
1.8.3.2