[REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station

[Theodore Ts'o]

On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
> On 2 September 2014 14:05, Theodore Ts'o  wrote:
> > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
> > longer see the my Dell 30" monitor when it is connected via the
> > docking station using a Displayport connector.  This worked using 3.16
> > kernel.
> >
> > If I connect to the monitor using the mini-display, by passing the
> > docking station, things work fine (but of course it's annoying not to
> > be able to use the docking station).
> >
> > Is this a known problem?  This is not the first time that we've had
> > regressions with this docking station.   It's vaguely reminsicent of
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=71267
> >
> > Except the system isn't hanging; it's just not seeing the monitor at all.
> 
> Have you the Dell 30" set to Displayport 1.2 enabled mode?
> 
> If so, then see if disabling that in the monitor menus helps.
> 
> This is probably due to the fact we now attempt to talk to new DP devices
> with the protocol they provide. So previously the monitor exposed DP 1.2
> and we just didn't care, now if it exposes it we attempt to talk to it.

Hi Dave,

I've since upgraded to a newer X server, which may have been
responsible for the symptoms somewhat.  It now doesn't seem to matter
whether the Dell 30" monitor is set to DP 1.2 or not.  It now will
find the Dell 30" monitor reliably when the system is freshly booted,
attached to the Dock.  If I then suspend the laptop, remove it from
the dock, unsuspend it from the laptop, then resuspend the laptop, and
return it to the dock, it can no longer see the monitor until I
reboot.

I am currently running 3.17-rc4 based kernel, and I have the following
X server components:

ii  xserver-xorg1:7.7+7  amd64
X.Org X server
ii  xserver-xorg-core   2:1.16.0.901-1   amd64
Xorg X server - core server
ii  xserver-xorg-video-intel2:2.21.15-2+b2   amd64
X.Org X server -- Intel i8xx, i9xx display driver

Here is the dmesg file with drm.debug=6.  Could you take a quick look
and see if anything obvious jumps out at you?

Thanks,

- Ted

-- next part --
A non-text attachment was scrubbed...
Name: dmesg-repro.gz
Type: application/gzip
Size: 32179 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/6255d4d4/attachment-0001.bin>

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Rafael J. Wysocki]

On Thursday, September 25, 2014 11:15:35 AM Aaron Lu wrote:
> Hi Hans,
> 
> Thanks for following up and explaining the situation to Pali.
> 
> On 09/25/2014 02:21 AM, Pali Roh?r wrote:
> > On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
> >> Ok, so the dell-laptop interface is just an obsolete wrapper
> >> around the i915 opregion code, which shows that the right
> >> interface to use is the i915 one, which we do if you don't
> >> specify any kernel commandline parameters, case closed.
> >>
> >> Regards,
> >>
> >> Hans
> > 
> > Nope, its not closed.
> > 
> > Still i915 interface has problem with setting backlight. It 
> > exports lot of levels which turning display off. Which breaking 
> > exiting applications for configuring display brightness. This is 
> > still big regression as black screen is not want people want to 
> > see.
> > 
> > Driver dell-laptop has exported only few - not thousands level 
> > (which is insane) and only usefull levels (not lot of levels 
> > which turn display off).
> > 
> > So for this reason using i915 backlight interface is not possible 
> > and also Dell (for E6440) set kernel param acpi_backlight=vendor 
> > to use dell_laptop module for controlling brightness.
> > 
> > On my laptop E6440 is better for using dell-laptop and not acpi 
> > or i915.
> 
> Hi Pali,
> 
> Please test this patch:
> 
> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
> b/drivers/gpu/drm/i915/intel_opregion.c
> index ca52ad2ae7d1..15534345bd57 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -396,6 +396,24 @@ int intel_opregion_notify_adapter(struct drm_device 
> *dev, pci_power_t state)
>   return -EINVAL;
>  }
>  
> +/*
> + * Some of the Thinkpads' firmware will issue a backlight change operation
> + * region request unconditionally on AC plug/unplug, this is undesirable and
> + * should be ignored. Then there is a Dell laptop whose vendor backlight
> + * interface also makes use of operation region request to change backlight
> + * level and we have to keep it work. The rule used here is: if the vendor
> + * backlight interface is not in use and the ACPI backlight interface is
> + * broken, we ignore the requests; oterwise, we keep processing them.
> + */
> +static bool should_ignore_backlight_request(void)
> +{
> + if (acpi_video_backlight_support() &&
> + !acpi_video_verify_backlight_support())
> + return true;
> +
> + return false;
> +}

Well, what about

return acpi_video_backlight_support() && 
!acpi_video_verify_backlight_support();

?

> +
>  static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -404,11 +422,7 @@ static u32 asle_set_backlight(struct drm_device *dev, 
> u32 bclp)
>  
>   DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);
>  
> - /*
> -  * If the acpi_video interface is not supposed to be used, don't
> -  * bother processing backlight level change requests from firmware.
> -  */
> - if (!acpi_video_verify_backlight_support()) {
> + if (should_ignore_backlight_request()) {
>   DRM_DEBUG_KMS("opregion backlight request ignored\n");
>   return 0;
>   }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Rafael J. Wysocki]

On Thursday, September 25, 2014 04:27:58 PM Wolfram Sang wrote:
> 
> --Bn2rw/3z4jIqBvZU
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Thu, Sep 25, 2014 at 09:22:01AM -0500, Felipe Balbi wrote:
> > On Thu, Sep 25, 2014 at 01:27:18PM +0530, Vinod Koul wrote:
> > > On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote:
> > > > > > > OK, I guess this is as good as it gets.
> > > > > > >=20
> > > > > > > What tree would you like it go through?
> > > > > >=20
> > > > > > Do we really need this new helper ? I mean, the very moment when =
> we
> > > > > > decide to implement ->runtime_idle() we will need to get rid of t=
> his
> > > > > > change. I wonder if it's really valid...
> > > > >=20
> > > > > I'm not sure I'm following?  This seems to simply implement what dr=
> ivers
> > > > > have been doing already as one function.  Why would it be invalid t=
> o reduce
> > > > > code duplication?
> > > >=20
> > > > For two reasons:
> > > >=20
> > > > 1) the helper has no inteligence whatsoever. It just calls the same
> > > > functions.
> > > >=20
> > > > 2) the duplication will vanish whenever someone implements
> > > > ->runtime_idle() and have that call pm_runtime_autosuspend() (like PCI
> > > > and USB buses are doing today). This will just be yet another line th=
> at
> > > > needs to change.
> > > >=20
> > > > Frankly though, no strong feelings, I just think it's a commit that
> > > > doesn't bring that any benefits other than looking like one line was
> > > > removed.
> > > and yes that is what it tries to do nothing more nothing less. If in fu=
> ture
> > > there are no users (today we have quite a few), then we can remove the =
> dead
> > > macro, no harm. But that is not the situation today.
> >=20
> > as I said, a commit that's bound to be useless. It's not like you're
> > saving 10 lines of code, it's only one. Replacing two simple lines with
> > a function which takes  almost as many characters to type .
> >=20
> > IMO, this is pretty useless and I'd rather not see them in the drivers I
> > maintain, sorry.
> 
> It is not a NACK from me; yet from a high-level perspective I agree with
> Felipe.

OK

I'd rather not merge something that driver people don't want to use.

Vinod?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH v4 05/23] drm/radeon: Add radeon <--> amdkfd interface

[Oded Gabbay]

On 24/09/14 23:45, Oded Gabbay wrote:
> This patch adds the interface between the radeon driver and the amdkfd driver.
> The interface implementation is contained in radeon_kfd.c and radeon_kfd.h.
> 
> The interface itself is represented by a pointer to struct
> kfd_dev. The pointer is located inside radeon_device structure.
> 
> All the register accesses that amdkfd need are done using this interface. This
> allows us to avoid direct register accesses in amdkfd proper,  while also
> avoiding locking between amdkfd and radeon.
> 
> The single exception is the doorbells that are used in both of the drivers.
> However, because they are located in separate pci bar pages, the danger of
> sharing registers between the drivers is minimal.
> 
> Having said that, we are planning to move the doorbells as well to radeon.
> 
> v3:
> 
> Add interface for sa manager init and fini. The init function will allocate a
> buffer on system memory and pin it to the GART address space via the radeon sa
> manager.
> 
> All mappings of buffers to GART address space are done via the radeon sa
> manager. The interface of allocate memory will use the radeon sa manager to 
> sub
> allocate from the single buffer that was allocated during the init function.
> 
> Change lower_32/upper_32 calls to use linux macros
> 
> Add documentation for the interface
> 
> v4:
> 
> Change ptr field type in kgd_mem from uint32_t* to void* to match to type that
> is returned by radeon_sa_bo_cpu_addr
> 
> Signed-off-by: Oded Gabbay 
> ---
>  drivers/gpu/drm/radeon/Makefile |   1 +
>  drivers/gpu/drm/radeon/cik.c|   9 +
>  drivers/gpu/drm/radeon/cik_reg.h|  65 +
>  drivers/gpu/drm/radeon/cikd.h   |  51 +++-
>  drivers/gpu/drm/radeon/radeon.h |   4 +
>  drivers/gpu/drm/radeon/radeon_drv.c |   5 +
>  drivers/gpu/drm/radeon/radeon_kfd.c | 538 
> 
>  drivers/gpu/drm/radeon/radeon_kfd.h | 177 
>  drivers/gpu/drm/radeon/radeon_kms.c |   7 +
>  9 files changed, 856 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
>  create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h
> 
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index d01b879..bad6caa 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -104,6 +104,7 @@ radeon-y += \
>   radeon_vce.o \
>   vce_v1_0.o \
>   vce_v2_0.o \
> + radeon_kfd.o
>  
>  radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
>  radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 69b9027..27c983c 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -32,6 +32,7 @@
>  #include "cik_blit_shaders.h"
>  #include "radeon_ucode.h"
>  #include "clearstate_ci.h"
> +#include "radeon_kfd.h"
>  
>  MODULE_FIRMWARE("radeon/BONAIRE_pfp.bin");
>  MODULE_FIRMWARE("radeon/BONAIRE_me.bin");
> @@ -7792,6 +7793,9 @@ restart_ih:
>   while (rptr != wptr) {
>   /* wptr/rptr are in bytes! */
>   ring_index = rptr / 4;
> +
> + radeon_kfd_interrupt(rdev, (const void *) 
> >ih.ring[ring_index]);
> +
>   src_id =  le32_to_cpu(rdev->ih.ring[ring_index]) & 0xff;
>   src_data = le32_to_cpu(rdev->ih.ring[ring_index + 1]) & 
> 0xfff;
>   ring_id = le32_to_cpu(rdev->ih.ring[ring_index + 2]) & 0xff;
> @@ -8481,6 +8485,10 @@ static int cik_startup(struct radeon_device *rdev)
>   if (r)
>   return r;
>  
> + r = radeon_kfd_resume(rdev);
> + if (r)
> + return r;
> +
>   return 0;
>  }
>  
> @@ -8529,6 +8537,7 @@ int cik_resume(struct radeon_device *rdev)
>   */
>  int cik_suspend(struct radeon_device *rdev)
>  {
> + radeon_kfd_suspend(rdev);
>   radeon_pm_suspend(rdev);
>   dce6_audio_fini(rdev);
>   radeon_vm_manager_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/cik_reg.h 
> b/drivers/gpu/drm/radeon/cik_reg.h
> index ca1bb61..1ab3dbc 100644
> --- a/drivers/gpu/drm/radeon/cik_reg.h
> +++ b/drivers/gpu/drm/radeon/cik_reg.h
> @@ -147,4 +147,69 @@
>  
>  #define CIK_LB_DESKTOP_HEIGHT 0x6b0c
>  
> +struct cik_hqd_registers {
> + u32 cp_mqd_base_addr;
> + u32 cp_mqd_base_addr_hi;
> + u32 cp_hqd_active;
> + u32 cp_hqd_vmid;
> + u32 cp_hqd_persistent_state;
> + u32 cp_hqd_pipe_priority;
> + u32 cp_hqd_queue_priority;
> + u32 cp_hqd_quantum;
> + u32 cp_hqd_pq_base;
> + u32 cp_hqd_pq_base_hi;
> + u32 cp_hqd_pq_rptr;
> + u32 cp_hqd_pq_rptr_report_addr;
> + u32 cp_hqd_pq_rptr_report_addr_hi;
> + u32 cp_hqd_pq_wptr_poll_addr;
> + u32 cp_hqd_pq_wptr_poll_addr_hi;
> + u32 cp_hqd_pq_doorbell_control;
> + u32 cp_hqd_pq_wptr;
> + u32 cp_hqd_pq_control;
> + u32 cp_hqd_ib_base_addr;
> + u32 cp_hqd_ib_base_addr_hi;
> + u32 cp_hqd_ib_rptr;
> 

page allocator bug in 3.16?

[Maarten Lankhorst]

Hey,

On 25-09-14 20:55, Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
> 
> Mostly the slowdowns are associated with gpu-related tasks, like
> opening new emacs windows, switching workspaces, laughing at internet
> gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue
> it right away -- 3.15 is the first time suspend has worked reliably.
> 
> This week I started looking into what the slowdown was and discovered
> it's happening during dma allocation through swiotlb (the cpus can do
> intel iommu but I don't use it because it's not the default for most users).
> 
> I'm still working on a bisection but each step takes 8+ hours to
> validate and even then I'm no longer sure I still have the 'bad'
> commit in the bisection. [edit: yup, I started over]
> 
> I just discovered a smattering of these in my logs and only on 3.16-rc+ 
> kernels:
> Sep 25 07:57:59 thor kernel: [28786.001300] alloc_contig_range 
> test_pages_isolated(2bf560, 2bf562) failed
> 
> This dual-Xeon box has 10GB and sysrq Show Memory isn't showing heavy
> fragmentation [1].
> 
> Besides Mel's page allocator changes in 3.16, another suspect commit is:
Maybe related, but I've been seeing page corruption in nouveau as well, with 
3.15.9:

http://paste.debian.net/122800/

I think it might be an even older bug because I've been using nouveau on my 
desktop and it hasn't been stable for the past few releases. I'm also lazy with 
updating kernel, still do it from time to time.

The lookup and nvapeek warnings/crashes are not important btw, I was testing 
some nouveau things.
The linker trap probably is. After the second BUG Xorg was no longer able to 
recover.

But this was after various suspend/resume cycles, although I suspect I've hit 
some corruption on radeon too (on a somewhat more recent kernel) when I fiddle 
with vgaswitcheroo, ending up with a real massive amount of spam there, etc.

Unfortunately I haven't been able to find out what caused it yet, nor am I sure 
what debug options I should set in the kernel to debug this.

~Maarten

[PATCH v4 1/5] drm/rockchip: Add basic drm driver

[Daniel Vetter]

On Thu, Sep 25, 2014 at 2:54 AM, Mark yao  wrote:
> Hi, Daniel
> this version is old, newest is v5. and I remove uapi at v5.
> you can see v5 patch at:
> https://lkml.org/lkml/2014/9/23/1061
> thanks
>
> This version doesn't seem to be cc'ed to dri-devel, at least it didn't
> yet show up. Can you please double-check?
>
> actually I cc the v5 version to dri-devel at lists.freedesktop.org.
> and we can found the patch at https://patchwork.kernel.org/patch/4967501/(
> Project: dri-devel)

Yeah it eventually showed up here too. Looks sane from a really high
level up I think, so Ack: me.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v6 3/3] dt-bindings: video: Add documentation for rockchip vop

[Mark yao]

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

 .../devicetree/bindings/video/rockchip-vop.txt |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt 
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
new file mode 100644
index 000..d15351f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -0,0 +1,58 @@
+device-tree bindings for rockchip soc display controller (vop)
+
+VOP (Visual Output Processor) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vop";
+
+- interrupts: should contain a list of all VOP IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: Must contain
+   aclk_vop: for ddr buffer transfer.
+   hclk_vop: for ahb bus to R/W the phy regs.
+   dclk_vop: pixel clock.
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - axi
+  - ahb
+  - dclk
+
+- iommus: required a iommu node
+
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+SoC specific DT entry:
+   vopb: vopb at ff93 {
+   compatible = "rockchip,rk3288-vop";
+   reg = <0xff93 0x19c>;
+   interrupts = ;
+   clocks = < ACLK_VOP0>, < DCLK_VOP0>, < HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = < SRST_LCDC1_AXI>, < SRST_LCDC1_AHB>, < 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint=<_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint=<_in_vopb>;
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH v6 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark yao]

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt 
b/Documentation/devicetree/bindings/video/rockchip-drm.txt
new file mode 100644
index 000..7fff582
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt
@@ -0,0 +1,19 @@
+Rockchip DRM master device
+
+
+The Rockchip DRM master device is a virtual device needed to list all
+vop devices or other display interface nodes that comprise the
+graphics subsystem.
+
+Required properties:
+- compatible: Should be "rockchip,display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+  of vop devices. vop definitions as defined in
+  Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <_out>, <_out>;
+};
-- 
1.7.9.5

[PATCH v6 1/3] drm/rockchip: Add basic drm driver

[Mark yao]

This patch adds the basic structure of a DRM Driver for Rockchip Socs.

Signed-off-by: Mark yao 
---
Changes in v2:
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use vop reset at first init
- reference framebuffer when used and unreference when swap out vop

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  516 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   61 ++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  345 ++
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1418 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
 14 files changed, 3098 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b066bb3..7c4c3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -171,6 +171,8 @@ config DRM_SAVAGE

 source "drivers/gpu/drm/exynos/Kconfig"

+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"

 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..d03387a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
+obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
 obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
new file mode 100644
index 000..87255f7
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -0,0 +1,17 @@
+config DRM_ROCKCHIP
+   tristate "DRM Support for Rockchip"
+   depends on DRM && ROCKCHIP_IOMMU && ARM_DMA_USE_IOMMU && IOMMU_API
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_PANEL
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
+   select VIDEOMODE_HELPERS
+   help
+ Choose this option if you have a Rockchip soc chipset.
+   

[PATCH v6 0/3] Add drm driver for Rockchip Socs

[Mark yao]

This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.

The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar
Vop devices. Vop devices support iommu mapping, we use dma-mapping API with
ARM_DMA_USE_IOMMU.

Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- add vop reset.

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Mark yao (3):
  drm/rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  516 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   61 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  201 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  230 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  345 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1418 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
 16 files changed, 3175 insertions(+)

-- 
1.7.9.5

[Bug 75276] Implement VGPR Register Spilling

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

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

--- Comment #49 from Fred Santos  ---
Hello,

I don't know if that helps, but the bug is still present on the brand new
openSUSE 13.2 beta1, for example. (With libLLVM 3.4.2 and mesa 10.3.0)

In my case, it can be easily reproduced when trying to launch Tomb Raider 2013
through Wine or Playonlinux. The game seems to start normally but crashes after
a few seconds and I get this error message :
'LLVM ERROR: ran out of registers during register allocation'

For the record, I have an AMD APU A8-7600 with Radeon R7 Graphics.

-- 
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/20140925/42367d73/attachment.html>

[PATCH v5 1/3] drm/rockchip: Add basic drm driver

[Mark yao]

On 2014?09?25? 16:58, Mark yao wrote:
> On 2014?09?25? 00:20, Daniel Kurtz wrote:
>> Hi Mark,
>>
>> Please review comments inline...
>>
>> On Wed, Sep 24, 2014 at 10:12 AM, Mark yao  
>> wrote:
>> To match the enum name, use ROCKCHIP_OUTPUT_TYPE_*.
>> Also, no need to explicitly set the first one to 0.
>> However, see below.  I don't think we to modify the drm_display_mode
>> to include an output type.
> but vop devices need know the connector type, connector enable 
> register is in vop.
> can I do that like under to  get connector type for crtc?
>
> static int rockchip_get_connector_type(struct drm_crtc *crtc)
> {
>   struct drm_device *dev = crtc->dev;
>   struct drm_connector * connector;
>
>   list_for_each_entry(connector, 
> >mode_config.connector_list, head) {
>   if (!connector->encoder)
>   continue;
>   /*
>* one crtc only has one connector in my case, so just find 
> the first connector at list.
>*/
>   if (connector->encoder->crtc == crtc)
>   break;
> }
>
> if (!connector)
> return -EINVAL;
>
> return connector->connector_type;
> } 
Oh, sorry, forgot to drop this comment,
for connector type problem, I try to new a help function for encoder to 
call as Daniel advices.
>>>
>>> +#define to_rockchip_plane(x) container_of(x, struct rockchip_plane, base)
>>> +
>>> +struct rockchip_plane {
>>> +   int id;
>>> +   struct drm_plane base;
>>> +   const struct vop_win *win;
>>> +   struct vop_context *ctx;
>> Isn't ctx just: to_vop_ctx(base->crtc)
>>
> OK. we can use to_vop_ctx(base->crtc) to get ctx. 
I have do a test to use "to_vop_ctx(base->crtc)", but found that 
"base->crtc" maybe not init.
for cursor plane, base->crtc always is NULL. and disable_plane will fail.
maybe we can add "base->crtc = crtc" at update_plane, but it seems not good.
so I think still use "rockchip_plane->ctx" would be better.

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

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Sjoerd Simons]

On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> > On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> > >Playing a bit with todays linux-next on my jetson, it seems this patch is
> > >still required for enabling the GPU. Is there anything blocking it 
> > >(firmware
> > >not available yet in liux-firmware?)
> > 
> > I think initially I was waiting for the DRM patch "drm/nouvea: support for
> > probing platform devices" to be applied, but it looks like that's been
> > applied already, so only patches 4 and 5 in this series are still
> > outstanding.
> > 
> > Alex, wasn't there also some issue where the VPR register had to be
> > programmed, and if it wasn't there'd be a hang when the GPU registers were
> > touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> > the problem, then I guess we can commit these last two patches for 3.19. A
> > resend after the 3.18 merge window might help.
> 
> A patch that programs VPR was merged into U-Boot (though I don't think
> it's made it into master yet).

Assuming you're talking about "ARM: tegra: Disable VPR",that has landed
in u-boot master and released as part of v2014.10-rc2 [0]

>  I'm not sure we can reasonably check for
> that in Nouveau, given that the register is somewhere completely
> unrelated. In fact I think the U-Boot patch was triggered by some
> discussion about how to solve this and it was decided that it shouldn't
> be done in the kernel, but U-Boot should set it up.
> 
> That said, perhaps one solution would be to make U-Boot enable the gk20a
> device if it's set up the VPR and disable it otherwise?

I guess in that case the vdd-supply should still be added to the dts
with u-boot toggling the status field of the node?


0: 
http://git.denx.de/?p=u-boot.git;a=commit;h=df3443dfa449ad02bef8ddf6e2c90a6fd9394fc9
-- 
Sjoerd Simons 

[PATCH v5 00/11] drm: add support for Atmel HLCDC Display Controller

[Rob Clark]

On Mon, Sep 8, 2014 at 4:43 AM, Boris BREZILLON
 wrote:
> Hello,
>
> This patch series adds support for Atmel HLCDC (HLCD Controller) available
> on some Atmel SoCs (i.e. the sama5d3 family).
>
> The HLCDC actually provides a Display Controller and a PWM device, hence I
> decided to declare an MFD device exposing 2 subdevices: a display
> controller and a PWM chip.
> This also solves a circular dependency issue preventing HLCDC driver from
> unloading.
> The HLCDC request a drm_panel device, which request a backlight device
> (a PWM backlight), which depends on a PWM which is provided by the HLCDC
> driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)).
>
> The current implementation only supports sama5d3 SoCs but other SoCs should
> be easily ported by defining new compatible strings and adding HLCDC
> description structures for these SoCs (Ludovic tested this driver on an
> at91sam9x5 board).
>
> The drivers supports basic CRTC functionalities, several overlays and an
> hardware cursor.
>
> At the moment, it only supports connection to LCD panels through an RGB
> connector (defined as an LVDS connector in my implementation), though
> connection to other kind of devices (like DRM bridges) could be added later.
>
> It also supports several RGB formats on all planes and some YUV formats on
> the HEO overlay plane.
>
> This series depends those series: [1] and [2].
>
> I know you're all quite busy, but I was expecting to get support for
> atmel's HLCDC block in 3.18, and given the lack of review I got on the
> DRM and PWM parts I doubt it can happen :-(.
>
> Moreover, the dependencies ([1] and [2]) are stuck too.
> The first one has been reviewed by Rob, but didn't get any feedback after
> that. David, Rob, is there anything blocking this series ?
> The second patch series contains some rework I've done to describe the
> transfer format used on a connector bus. Laurent, Thierry, you're the one
> who suggested this rework. Could you give your opinion on my
> implementation ?


hmm, looks like I still owe you a review after conversion to flip-work
helpers..  Sorry, I thought I'd already reviewed one of the later
versions.  It is on my list for tomorrow.

Definitely we should get the flip-work helper patches landed, that
part already has my r-b

BR,
-R

> Best Regards,
>
> Boris
>
> [1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
> [2]http://www.spinics.net/lists/kernel/msg1791681.html
>
> Changes since v4:
> - fix a few more bugs in rotation handling (rotation was buggy on some
>   formats)
> - return connector_status_unknown until a panel is exposed by the
>   drm_panel infrastructure (prevent fbdev creation until everyting is
>   in place)
> - rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration
>   (automatically select this option when selecting the HLCDC PMW or DRM
>   driver, instead of depending on this option)
>
> Changes since v3:
> - rework the layer code to simplify several parts (locking and layer
>   disabling)
> - make use of the drm_flip_work infrastructure
> - rely on default HW cursor implementation using on the cursor plane
> - rework the display controller DT bindings (based on OF graph
>   representation)
> - add rotation support
> - retrive RGB bus format from drm_display_info
> - drop the dynamic pinctrl state selection
> - rework HLCDC output handling (previously specialized to interface
>   with LCD panels)
> - drop ".module = THIS_MODULE" lines
> - change display controller compatible string
>
> Changes since v2:
> - fix coding style issues (macro indentation)
> - make use of GENMASK in several places
> - declare regmap config as a static structure
> - rework hlcdc plane update API
> - rework cursor handling to make use of the new plane update API
> - fix backporch config
> - do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
>   clk disable calls when accessing registers
> - explicitely include regmap and clk headers instead of relying on
>   atmel-hlcdc.h inclusions
> - make the atmel-hlcdc driver depends on CONFIG_OF
> - separate DT bindings documentation from driver implementation
> - support several pin muxing for HLCDC pins on sama5d3 SoCs
>
> Changes since v1:
> - replace the backlight driver by a PWM driver
> - make use of drm_panel infrastructure
> - split driver code in several subsystem: MFD, PWM and DRM
> - add support for overlays
> - add support for hardware cursor
>
> Boris BREZILLON (11):
>   mfd: add atmel-hlcdc driver
>   mfd: add documentation for atmel-hlcdc DT bindings
>   pwm: add support for atmel-hlcdc-pwm device
>   pwm: add DT bindings documentation for atmel-hlcdc-pwm driver
>   drm: add Atmel HLCDC Display Controller support
>   drm: add DT bindings documentation for atmel-hlcdc-dc driver
>   ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode
> configs
>   ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins
>   ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs
>   ARM: 

[PATCH v5 1/3] drm/rockchip: Add basic drm driver

[Rob Clark]

On Tue, Sep 23, 2014 at 10:12 PM, Mark yao  wrote:
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark yao 

Looks like my comments are addressed, so:

Reviewed-by: Rob Clark 

> ---
> Changes in v2:
> - use the component framework to defer main drm driver probe
>   until all VOP devices have been probed.
> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
>   master device and each vop device can shared the drm dma mapping.
> - use drm_crtc_init_with_planes and drm_universal_plane_init.
> - remove unnecessary middle layers.
> - add cursor set, move funcs to rockchip drm crtc.
> - use vop reset at first init
> - reference framebuffer when used and unreference when swap out vop
>
> Changes in v3:
> - change "crtc->fb" to "crtc->primary-fb"
> Adviced by Daniel Vetter
> - init cursor plane with universal api, remove unnecessary cursor set,move
>
> Changes in v4:
> Adviced by David Herrmann
> - remove drm_platform_*() usage, use register drm device directly.
> Adviced by Rob Clark
> - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap 
> offset
>
> Changes in v5:
> Adviced by Arnd Bergmann
> - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
> - fix some incorrect dependencies.
> Adviced by Boris BREZILLON
> - fix some mistake and bugs.
> Adviced by Daniel Vetter
> - drop all special ioctl and use generic kms ioctl instead.
> Adviced by Rob Clark
> - use unlocked api for drm_fb_helper_restore_fbdev_mode.
> - remove unused rockchip_gem_prime_import_sg_table.
>
>  drivers/gpu/drm/Kconfig   |2 +
>  drivers/gpu/drm/Makefile  |1 +
>  drivers/gpu/drm/rockchip/Kconfig  |   17 +
>  drivers/gpu/drm/rockchip/Makefile |8 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  509 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  120 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 +
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  341 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1373 
> +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  187 
>  14 files changed, 3092 insertions(+)
>  create mode 100644 drivers/gpu/drm/rockchip/Kconfig
>  create mode 100644 drivers/gpu/drm/rockchip/Makefile
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

page allocator bug in 3.16?

[Peter Hurley]

On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
> There are six ttm patches queued for 3.16.4:
> 
> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
> drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
> drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
> drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
> drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch

Thanks for info, Chuck.

Unfortunately, none of these fix TTM dma allocation doing CMA dma allocation,
which is the root problem.

Regards,
Peter Hurley

[PATCH] drm/omap: handle incompatible buffer stride and pixel size

[Tomi Valkeinen]

omapdrm doesn't check if the pitch of the framebuffer and the color
format's bits-per-pixel are compatible. omapdss requires that the stride
of a buffer is an integer number of pixels

For example, when using modetest with a display that has x resolution of
1280, and using packed 24 RGB mode (3 bytes per pixel), modetest
allocates a buffer with a byte stride of 4 * 1280 = 5120. But 5120 / 3 =
1706.666... pixels, which causes wrong colors and a tilt on the screen.

Add a check into omapdrm to return an error if the user tries to use
such a combination.

Note: this is not a HW requirement at least for non-rotation use cases,
but a SW driver requirement. In the future we should study if also
rotation use cases are fine with any stride size, and if so, change the
driver to allow these strides.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fb.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..e123b4dee670 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,
goto fail;
}

+   if (pitch % format->planes[i].stride_bpp != 0) {
+   dev_err(dev->dev,
+   "buffer pitch (%d bytes) is not a multiple of 
pixel size (%d bytes)\n",
+   pitch, format->planes[i].stride_bpp);
+   ret = -EINVAL;
+   goto fail;
+   }
+
size = pitch * mode_cmd->height / format->planes[i].sub_y;

if (size > (omap_gem_mmap_size(bos[i]) - mode_cmd->offsets[i])) 
{
-- 
2.3.1



-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #9 from lorenz.bona at gmail.com ---
Created attachment 106873
  --> https://bugs.freedesktop.org/attachment.cgi?id=106873=edit
dmesg | grep drm

-- 
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/20140925/73530568/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #112 from Aaron B  ---
OKay, I'm testing it now. Can't game at any good framerate, but that is fine.
If I get no crashes here, does that mean the random crashes are from changes in
power state? It would make sense, sense most of the time is on page loading, or
most of the screens pixels changing at the same time. I'm on a 1080p screen via
hdmi, maybe that could help you try to replicate it some more.

-- 
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/20140925/2a9d2d79/attachment.html>

[Bug 82889] [drm:si_dpm_set_power_state] *ERROR* si_disable_ulv failed

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

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

--- Comment #8 from lorenz.bona at gmail.com ---
Same warning here with 3.17rc5. Building from this repository

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.17

-- 
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/20140925/05748620/attachment.html>

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Thierry Reding]

On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> >Playing a bit with todays linux-next on my jetson, it seems this patch is
> >still required for enabling the GPU. Is there anything blocking it (firmware
> >not available yet in liux-firmware?)
> 
> I think initially I was waiting for the DRM patch "drm/nouvea: support for
> probing platform devices" to be applied, but it looks like that's been
> applied already, so only patches 4 and 5 in this series are still
> outstanding.
> 
> Alex, wasn't there also some issue where the VPR register had to be
> programmed, and if it wasn't there'd be a hang when the GPU registers were
> touched? If we've added code to Nouveau/tegradrm to detect that and avoid
> the problem, then I guess we can commit these last two patches for 3.19. A
> resend after the 3.18 merge window might help.

A patch that programs VPR was merged into U-Boot (though I don't think
it's made it into master yet). I'm not sure we can reasonably check for
that in Nouveau, given that the register is somewhere completely
unrelated. In fact I think the U-Boot patch was triggered by some
discussion about how to solve this and it was decided that it shouldn't
be done in the kernel, but U-Boot should set it up.

That said, perhaps one solution would be to make U-Boot enable the gk20a
device if it's set up the VPR and disable it otherwise?

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

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #111 from Alex Deucher  ---
(In reply to comment #110)
> I found this post, stating some of the ASUS hardware comes PRE-OVERCLOCKED
> from the factory. Good chance this is the cause of my instability?
> 
> http://www.tomshardware.com/answers/id-2041324/problem-asus-270x-screen-
> blank-game.html
> 
> My GPU:
> 
> http://www.newegg.com/Product/Product.aspx?Item=N82E16814121802_mc=KNC-
> GoogleAdwords_mmc=KNC-GoogleAdwords-_-pla-_-Desktop+Graphics+Cards-_-
> N82E16814121802=COjjs6v3_MACFRAR7Aod_2EAqQ
> 
> Core clock is listed at 1120 Mhz, not 1050 Mhz.

Radeon already limits the clocks in certain cases depending on the vbios
tables.  You can disable dpm which will keep the chip at the default boot up
levels (usually some where in the range of 300e/150m) for testing.  Append
radeon.dpm=0 to the kernel command line in grub.

-- 
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/20140925/f2abd821/attachment.html>

[GIT PULL] IPUv3 fixes for v3.18

[Philipp Zabel]

Hi Dave,

please pull these fixes for the IPUv3 core driver.

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  git://git.pengutronix.de/git/pza/linux.git tags/ipu-fixes-3.18

for you to fetch changes up to c7750e8321155d39625c1ffb03227af4fa7f9122:

  gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig 
(2014-09-24 23:50:25 +0200)


IPUv3 fixes for v3.18


Axel Lin (2):
  gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error
  gpu: ipu-v3: Return proper error on ipu_add_client_devices error path

Fabio Estevam (2):
  gpu: ipu-v3: ipu-smfc: Do not leave DEBUG defined
  gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig

 drivers/gpu/ipu-v3/Kconfig  | 3 ++-
 drivers/gpu/ipu-v3/ipu-common.c | 4 +++-
 drivers/gpu/ipu-v3/ipu-smfc.c   | 1 -
 3 files changed, 5 insertions(+), 3 deletions(-)

regards
Philipp

[PATCH] drm/exynos/fbdev: set smem_len for fbdev

[Daniel Kurtz]

On Thu, Sep 25, 2014 at 5:32 PM, Geert Uytterhoeven
 wrote:
> On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz  wrote:
>> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
>> the fbdev.
>>
>> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
>>   drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
>>
>> However, smem_len is used by some userland applications to calculate the
>> size for mmap.  In particular, it is used by xf86-video-fbdev:
>>
>> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571
>>
>> So, let's restore setting the smem_len to unbreak things for these users.
>>
>> Note: we are still leaving smem_start set to 0.
>
> Doesn't this cause a system crash when userspace (e.g. fbtest) writes into
> the mmap()ed /dev/fb*, as the wrong MMIO region is mapped?

Do you see a crash during testing, or is your question hypothetical?

I don't think there will be one.  exynos's fbev defines its own
fb_ops.fb_mmap, which uses dma_mmap_attrs() to mmap the fb's gem
buffer, which was allocated by dma_alloc_attrs().  This bypasses the
code in drivers/video/fbmem.c:fb_mmap() that references
fix.smem_start.

But, perhaps I am missing something?

-Dan

>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
> linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #110 from Aaron B  ---
I found this post, stating some of the ASUS hardware comes PRE-OVERCLOCKED from
the factory. Good chance this is the cause of my instability?

http://www.tomshardware.com/answers/id-2041324/problem-asus-270x-screen-blank-game.html

My GPU:

http://www.newegg.com/Product/Product.aspx?Item=N82E16814121802_mc=KNC-GoogleAdwords_mmc=KNC-GoogleAdwords-_-pla-_-Desktop+Graphics+Cards-_-N82E16814121802=COjjs6v3_MACFRAR7Aod_2EAqQ

Core clock is listed at 1120 Mhz, not 1050 Mhz.

-- 
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/20140925/94c5c961/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #109 from Aaron B  ---
Crashing still persists with -mtune=native and -march=native on my kernel and
mesa 64, and mesa 32 with LLVM 3.5 from Arch's repos. :c

-- 
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/20140925/80d14732/attachment.html>

page allocator bug in 3.16?

[Peter Hurley]

On 09/25/2014 04:33 PM, Alex Deucher wrote:
> On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley  
> wrote:
>> After several days uptime with a 3.16 kernel (generally running
>> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
>> desktop workspaces) I've been seeing some really extreme slowdowns.
>>
>> Mostly the slowdowns are associated with gpu-related tasks, like
>> opening new emacs windows, switching workspaces, laughing at internet
>> gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue
>> it right away -- 3.15 is the first time suspend has worked reliably.
>>
>> This week I started looking into what the slowdown was and discovered
>> it's happening during dma allocation through swiotlb (the cpus can do
>> intel iommu but I don't use it because it's not the default for most users).
>>
>> I'm still working on a bisection but each step takes 8+ hours to
>> validate and even then I'm no longer sure I still have the 'bad'
>> commit in the bisection. [edit: yup, I started over]
>>
>> I just discovered a smattering of these in my logs and only on 3.16-rc+ 
>> kernels:
>> Sep 25 07:57:59 thor kernel: [28786.001300] alloc_contig_range 
>> test_pages_isolated(2bf560, 2bf562) failed
>>
>> This dual-Xeon box has 10GB and sysrq Show Memory isn't showing heavy
>> fragmentation [1].
>>
>> Besides Mel's page allocator changes in 3.16, another suspect commit is:
>>
>> commit b13b1d2d8692b437203de7a404c6b809d2cc4d99
>> Author: Shaohua Li 
>> Date:   Tue Apr 8 15:58:09 2014 +0800
>>
>> x86/mm: In the PTE swapout page reclaim case clear the accessed bit 
>> instead of flushing the TLB
>>
>> Specifically, this statement:
>>
>> It could cause incorrect page aging and the (mistaken) reclaim of
>> hot pages, but the chance of that should be relatively low.
>>
>> I'm wondering if this could cause worse-case behavior with TTM? I'm
>> testing a revert of this on mainline 3.16-final now, with no results yet.
>>
>> Thoughts?
> 
> You may also be seeing this:
> https://lkml.org/lkml/2014/8/8/445

Thanks Alex. That is indeed the problem.

Still reading the email thread to find out where the patches
are that fix this. Although it doesn't make much sense to me
that nouveau sets up a 1GB GART and then uses TTM which is
trying to shove all the DMA through a 16MB CMA window
(which turns out to be the base Ubuntu config).

Regards,
Peter Hurley

[PATCH v5 1/3] drm/rockchip: Add basic drm driver

[Mark yao]

On 2014?09?25? 00:20, Daniel Kurtz wrote:
> Hi Mark,
>
> Please review comments inline...
>
> On Wed, Sep 24, 2014 at 10:12 AM, Mark yao  wrote:
>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>
>> Signed-off-by: Mark yao 
>> ---
>> Changes in v2:
>> - use the component framework to defer main drm driver probe
>>until all VOP devices have been probed.
>> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
>>master device and each vop device can shared the drm dma mapping.
>> - use drm_crtc_init_with_planes and drm_universal_plane_init.
>> - remove unnecessary middle layers.
>> - add cursor set, move funcs to rockchip drm crtc.
>> - use vop reset at first init
>> - reference framebuffer when used and unreference when swap out vop
>>
>> Changes in v3:
>> - change "crtc->fb" to "crtc->primary-fb"
>> Adviced by Daniel Vetter
>> - init cursor plane with universal api, remove unnecessary cursor set,move
>>
>> Changes in v4:
>> Adviced by David Herrmann
>> - remove drm_platform_*() usage, use register drm device directly.
>> Adviced by Rob Clark
>> - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap 
>> offset
>>
>> Changes in v5:
>> Adviced by Arnd Bergmann
>> - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
>> - fix some incorrect dependencies.
>> Adviced by Boris BREZILLON
>> - fix some mistake and bugs.
>> Adviced by Daniel Vetter
>> - drop all special ioctl and use generic kms ioctl instead.
>> Adviced by Rob Clark
>> - use unlocked api for drm_fb_helper_restore_fbdev_mode.
>> - remove unused rockchip_gem_prime_import_sg_table.
>>
>>   drivers/gpu/drm/Kconfig   |2 +
>>   drivers/gpu/drm/Makefile  |1 +
>>   drivers/gpu/drm/rockchip/Kconfig  |   17 +
>>   drivers/gpu/drm/rockchip/Makefile |8 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  509 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  120 +++
>>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
>>   drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  341 ++
>>   drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1373 
>> +
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  187 
>>   14 files changed, 3092 insertions(+)
>>   create mode 100644 drivers/gpu/drm/rockchip/Kconfig
>>   create mode 100644 drivers/gpu/drm/rockchip/Makefile
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>   create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index b066bb3..7c4c3c6 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -171,6 +171,8 @@ config DRM_SAVAGE
>>
>>   source "drivers/gpu/drm/exynos/Kconfig"
>>
>> +source "drivers/gpu/drm/rockchip/Kconfig"
>> +
>>   source "drivers/gpu/drm/vmwgfx/Kconfig"
>>
>>   source "drivers/gpu/drm/gma500/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 4a55d59..d03387a 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
>>   obj-$(CONFIG_DRM_VIA)  +=via/
>>   obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
>>   obj-$(CONFIG_DRM_EXYNOS) +=exynos/
>> +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
>>   obj-$(CONFIG_DRM_GMA500) += gma500/
>>   obj-$(CONFIG_DRM_UDL) += udl/
>>   obj-$(CONFIG_DRM_AST) += ast/
>> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
>> b/drivers/gpu/drm/rockchip/Kconfig
>> new file mode 100644
>> index 000..87255f7
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/Kconfig
>> @@ -0,0 +1,17 @@
>> +config DRM_ROCKCHIP
>> +   tristate "DRM Support for Rockchip"
>> +   depends on DRM && ROCKCHIP_IOMMU && ARM_DMA_USE_IOMMU && IOMMU_API
>> +   select DRM_KMS_HELPER
>> +   select DRM_KMS_FB_HELPER
>> +   select DRM_PANEL
>> +   select FB_CFB_FILLRECT
>> +   select FB_CFB_COPYAREA
>> +   select FB_CFB_IMAGEBLIT
>> +   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>> +   select VIDEOMODE_HELPERS
>> +   help
>> + Choose this option 

page allocator bug in 3.16?

[Peter Hurley]

On 09/25/2014 02:55 PM, Peter Hurley wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
> 
> Mostly the slowdowns are associated with gpu-related tasks, like
> opening new emacs windows, switching workspaces, laughing at internet
> gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue
> it right away -- 3.15 is the first time suspend has worked reliably.
> 
> This week I started looking into what the slowdown was and discovered
> it's happening during dma allocation through swiotlb (the cpus can do
> intel iommu but I don't use it because it's not the default for most users).
> 
> I'm still working on a bisection but each step takes 8+ hours to
> validate and even then I'm no longer sure I still have the 'bad'
> commit in the bisection. [edit: yup, I started over]
> 
> I just discovered a smattering of these in my logs and only on 3.16-rc+ 
> kernels:
> Sep 25 07:57:59 thor kernel: [28786.001300] alloc_contig_range 
> test_pages_isolated(2bf560, 2bf562) failed
> 
> This dual-Xeon box has 10GB and sysrq Show Memory isn't showing heavy
> fragmentation [1].

It's swapping, which is crazy because there's 7+GB of file cache [1] which
should be dropped before swapping.

The alloc_contig_range() failure precedes the swapping but not immediately
(44 mins. earlier).

How I reproduce this is to simply do a full distro kernel build.
Skipping the TLB flush is not the problem; the results below are from
3.16-final with that commit reverted.

The slowdown is really obvious because workspace switching redraw takes
multiple seconds to complete (all-cpu perf record of that below [2])

Regards,
Peter Hurley

[1]
SysRq : Show Memory
Mem-Info:
Node 0 DMA per-cpu:
CPU0: hi:0, btch:   1 usd:   0
CPU1: hi:0, btch:   1 usd:   0
CPU2: hi:0, btch:   1 usd:   0
CPU3: hi:0, btch:   1 usd:   0
CPU4: hi:0, btch:   1 usd:   0
CPU5: hi:0, btch:   1 usd:   0
CPU6: hi:0, btch:   1 usd:   0
CPU7: hi:0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU0: hi:  186, btch:  31 usd:  71
CPU1: hi:  186, btch:  31 usd: 166
CPU2: hi:  186, btch:  31 usd: 183
CPU3: hi:  186, btch:  31 usd: 109
CPU4: hi:  186, btch:  31 usd: 106
CPU5: hi:  186, btch:  31 usd: 161
CPU6: hi:  186, btch:  31 usd: 120
CPU7: hi:  186, btch:  31 usd:  54
Node 0 Normal per-cpu:
CPU0: hi:  186, btch:  31 usd: 159
CPU1: hi:  186, btch:  31 usd:  66
CPU2: hi:  186, btch:  31 usd: 178
CPU3: hi:  186, btch:  31 usd: 173
CPU4: hi:  186, btch:  31 usd:  91
CPU5: hi:  186, btch:  31 usd:  57
CPU6: hi:  186, btch:  31 usd:  58
CPU7: hi:  186, btch:  31 usd: 158
active_anon:170368 inactive_anon:173964 isolated_anon:0
 active_file:982209 inactive_file:973911 isolated_file:0
 unevictable:15 dirty:15 writeback:1 unstable:0
 free:96067 slab_reclaimable:107401 slab_unreclaimable:12572
 mapped:58271 shmem:10857 pagetables:9898 bounce:0
 free_cma:18
Node 0 DMA free:15860kB min:104kB low:128kB high:156kB active_anon:0kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15960kB managed:15876kB 
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB 
slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2974 9980 9980
Node 0 DMA32 free:117740kB min:20108kB low:25132kB high:30160kB 
active_anon:205232kB inactive_anon:196308kB active_file:1186764kB 
inactive_file:1173760kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:3127336kB managed:3048212kB mlocked:0kB dirty:24kB writeback:4kB 
mapped:71600kB shmem:8776kB slab_reclaimable:129132kB 
slab_unreclaimable:13468kB kernel_stack:2864kB pagetables:11536kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 7006 7006
Node 0 Normal free:250668kB min:47368kB low:59208kB high:71052kB 
active_anon:476240kB inactive_anon:499548kB active_file:2742072kB 
inactive_file:2721884kB unevictable:60kB isolated(anon):0kB isolated(file):0kB 
present:7340032kB managed:7174484kB mlocked:60kB dirty:36kB writeback:0kB 
mapped:161484kB shmem:34652kB slab_reclaimable:300472kB 
slab_unreclaimable:36804kB kernel_stack:7232kB pagetables:28056kB unstable:0kB 
bounce:0kB free_cma:72kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 1*4kB (U) 0*8kB 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 
1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15860kB
Node 0 DMA32: 4099*4kB (UEM) 4372*8kB (UEM) 668*16kB (UEM) 294*32kB (UEM) 
47*64kB (UEM) 24*128kB (UEM) 19*256kB (UM) 5*512kB (UM) 0*1024kB 6*2048kB (M) 
5*4096kB (M) = 117740kB
Node 0 Normal: 

page allocator bug in 3.16?

[Alex Deucher]

On Thu, Sep 25, 2014 at 2:55 PM, Peter Hurley  
wrote:
> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
>
> Mostly the slowdowns are associated with gpu-related tasks, like
> opening new emacs windows, switching workspaces, laughing at internet
> gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue
> it right away -- 3.15 is the first time suspend has worked reliably.
>
> This week I started looking into what the slowdown was and discovered
> it's happening during dma allocation through swiotlb (the cpus can do
> intel iommu but I don't use it because it's not the default for most users).
>
> I'm still working on a bisection but each step takes 8+ hours to
> validate and even then I'm no longer sure I still have the 'bad'
> commit in the bisection. [edit: yup, I started over]
>
> I just discovered a smattering of these in my logs and only on 3.16-rc+ 
> kernels:
> Sep 25 07:57:59 thor kernel: [28786.001300] alloc_contig_range 
> test_pages_isolated(2bf560, 2bf562) failed
>
> This dual-Xeon box has 10GB and sysrq Show Memory isn't showing heavy
> fragmentation [1].
>
> Besides Mel's page allocator changes in 3.16, another suspect commit is:
>
> commit b13b1d2d8692b437203de7a404c6b809d2cc4d99
> Author: Shaohua Li 
> Date:   Tue Apr 8 15:58:09 2014 +0800
>
> x86/mm: In the PTE swapout page reclaim case clear the accessed bit 
> instead of flushing the TLB
>
> Specifically, this statement:
>
> It could cause incorrect page aging and the (mistaken) reclaim of
> hot pages, but the chance of that should be relatively low.
>
> I'm wondering if this could cause worse-case behavior with TTM? I'm
> testing a revert of this on mainline 3.16-final now, with no results yet.
>
> Thoughts?

You may also be seeing this:
https://lkml.org/lkml/2014/8/8/445

Alex

[Nouveau] [PATCH] drm/nv84+: fix fence context seqno's

[Ted Percival]

On 09/23/2014 08:24 AM, Maarten Lankhorst wrote:
> Op 23-09-14 om 07:35 schreef Ben Skeggs:
>>> On 09/22/2014 03:08 AM, Maarten Lankhorst wrote:
 This fixes a regression introduced by "drm/nouveau: rework to new fence 
 interface"
 (commit 29ba89b2371d466).
>>
>> I'm still seeing issues with suspend, even with this patch, and the
>> one you pastebinned recently.
>>
> Annoying, and I'm out of ideas. The pastebinned patch is posted to dri-devel 
> as:
> [PATCH 2/8] drm/nouveau: specify if interruptible wait is desired in 
> nouveau_fence_sync.
> 
> Could you bisect to where the suspend issues started? With this patch applied 
> after
> "drm/nouveau: rework to new fence interface", and the other patch applied 
> after
> "drm/nouveau: use shared fences for readable objects"

I started bisecting to track down the suspend issue, but X won't start
at all with today's dri-next tree @ d743ecf36063 ("drm/doc: Fixup
drm_irq kerneldoc includes") plus the two patches, so I'll have to get
that out of the way first.

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Wolfram Sang]

On Thu, Sep 25, 2014 at 09:22:01AM -0500, Felipe Balbi wrote:
> On Thu, Sep 25, 2014 at 01:27:18PM +0530, Vinod Koul wrote:
> > On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote:
> > > > > > OK, I guess this is as good as it gets.
> > > > > > 
> > > > > > What tree would you like it go through?
> > > > > 
> > > > > Do we really need this new helper ? I mean, the very moment when we
> > > > > decide to implement ->runtime_idle() we will need to get rid of this
> > > > > change. I wonder if it's really valid...
> > > > 
> > > > I'm not sure I'm following?  This seems to simply implement what drivers
> > > > have been doing already as one function.  Why would it be invalid to 
> > > > reduce
> > > > code duplication?
> > > 
> > > For two reasons:
> > > 
> > > 1) the helper has no inteligence whatsoever. It just calls the same
> > > functions.
> > > 
> > > 2) the duplication will vanish whenever someone implements
> > > ->runtime_idle() and have that call pm_runtime_autosuspend() (like PCI
> > > and USB buses are doing today). This will just be yet another line that
> > > needs to change.
> > > 
> > > Frankly though, no strong feelings, I just think it's a commit that
> > > doesn't bring that any benefits other than looking like one line was
> > > removed.
> > and yes that is what it tries to do nothing more nothing less. If in future
> > there are no users (today we have quite a few), then we can remove the dead
> > macro, no harm. But that is not the situation today.
> 
> as I said, a commit that's bound to be useless. It's not like you're
> saving 10 lines of code, it's only one. Replacing two simple lines with
> a function which takes  almost as many characters to type .
> 
> IMO, this is pretty useless and I'd rather not see them in the drivers I
> maintain, sorry.

It is not a NACK from me; yet from a high-level perspective I agree with
Felipe.

-- 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/20140925/739eb5dd/attachment.sig>

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Pali Rohár]

On Thursday 25 September 2014 05:15:35 Aaron Lu wrote:
> Hi Hans,
> 
> Thanks for following up and explaining the situation to Pali.
> 
> On 09/25/2014 02:21 AM, Pali Roh?r wrote:
> > On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
> >> Ok, so the dell-laptop interface is just an obsolete
> >> wrapper around the i915 opregion code, which shows that
> >> the right interface to use is the i915 one, which we do if
> >> you don't specify any kernel commandline parameters, case
> >> closed.
> >> 
> >> Regards,
> >> 
> >> Hans
> > 
> > Nope, its not closed.
> > 
> > Still i915 interface has problem with setting backlight. It
> > exports lot of levels which turning display off. Which
> > breaking exiting applications for configuring display
> > brightness. This is still big regression as black screen is
> > not want people want to see.
> > 
> > Driver dell-laptop has exported only few - not thousands
> > level (which is insane) and only usefull levels (not lot of
> > levels which turn display off).
> > 
> > So for this reason using i915 backlight interface is not
> > possible and also Dell (for E6440) set kernel param
> > acpi_backlight=vendor to use dell_laptop module for
> > controlling brightness.
> > 
> > On my laptop E6440 is better for using dell-laptop and not
> > acpi or i915.
> 
> Hi Pali,
> 
> Please test this patch:
> 

Hi! this patch fixing this problem. With acpi_backlight=vendor 
dell-laptop will register backlight interface which is working 
again. Also userspace application dellLcdBrightness is working 
now without problem.

Can you going to send this patch also to stable 3.16 branch? As 
it fixing commit 0b9f7d93ca6109048a4eb06332b666b6e29df4fe.

> diff --git a/drivers/gpu/drm/i915/intel_opregion.c
> b/drivers/gpu/drm/i915/intel_opregion.c index
> ca52ad2ae7d1..15534345bd57 100644
> --- a/drivers/gpu/drm/i915/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/intel_opregion.c
> @@ -396,6 +396,24 @@ int intel_opregion_notify_adapter(struct
> drm_device *dev, pci_power_t state) return -EINVAL;
>  }
> 
> +/*
> + * Some of the Thinkpads' firmware will issue a backlight
> change operation + * region request unconditionally on AC
> plug/unplug, this is undesirable and + * should be ignored.
> Then there is a Dell laptop whose vendor backlight + *
> interface also makes use of operation region request to
> change backlight + * level and we have to keep it work. The
> rule used here is: if the vendor + * backlight interface is
> not in use and the ACPI backlight interface is + * broken, we
> ignore the requests; oterwise, we keep processing them. + */
> +static bool should_ignore_backlight_request(void)
> +{
> + if (acpi_video_backlight_support() &&
> + !acpi_video_verify_backlight_support())
> + return true;
> +
> + return false;
> +}
> +
>  static u32 asle_set_backlight(struct drm_device *dev, u32
> bclp) {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -404,11 +422,7 @@ static u32 asle_set_backlight(struct
> drm_device *dev, u32 bclp)
> 
>   DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);
> 
> - /*
> -  * If the acpi_video interface is not supposed to be used,
> don't -* bother processing backlight level change requests
> from firmware. -   */
> - if (!acpi_video_verify_backlight_support()) {
> + if (should_ignore_backlight_request()) {
>   DRM_DEBUG_KMS("opregion backlight request ignored\n");
>   return 0;
>   }

-- 
Pali Roh?r
pali.rohar at gmail.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140925/8935d34d/attachment-0001.sig>

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Sjoerd Simons]

Playing a bit with todays linux-next on my jetson, it seems this patch is
still required for enabling the GPU. Is there anything blocking it (firmware
not available yet in liux-firmware?)

On Mon, May 19, 2014 at 06:24:10PM +0900, Alexandre Courbot wrote:
> Signed-off-by: Alexandre Courbot 
> ---
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
> b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> index e31fb61a81d3..15a194d1277f 100644
> --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
> @@ -30,6 +30,12 @@
>   };
>   };
>  
> + gpu at 0,5700 {
> + status = "okay";
> +
> + vdd-supply = <_gpu>;
> + };
> +
>   pinmux: pinmux at 0,7868 {
>   pinctrl-names = "default";
>   pinctrl-0 = <_default>;
> @@ -1505,7 +1511,7 @@
>   regulator-always-on;
>   };
>  
> - sd6 {
> + vdd_gpu: sd6 {
>   regulator-name = "+VDD_GPU_AP";
>   regulator-min-microvolt = <65>;
>   regulator-max-microvolt = <120>;

-- 
If you put it off long enough, it might go away.

[PATCH 00/12] Renesas R-Car DU HDMI support

[Philipp Zabel]

Hi Laurent,

Am Mittwoch, den 24.09.2014, 23:04 +0300 schrieb Laurent Pinchart:
> Hello,
> 
> This patch set adds support for the HDMI output port present on the Renesas
> Koelsch board. Doing so requires two components, a driver for the external
> ADV7511W HDMI encoder, and support for HDMI encoders in the DU driver.
> 
> The HDMI encoder drivers uses the DRM slave encoder framework and the
> component framework to communicate with the DU driver. The DT bindings are
> based on the OF graph bindings to link the display controller and encoder.
> 
> The first two patches have been taken from Philipp Zabel's "[PATCH v3 0/8]
> Add of-graph helpers to loop over endpoints and find ports by id" series.
> Philipp, I don't see that series in linux-next, what's the merge status ?

There is a remaining comment by Guennadi on the soc_camera patch.

regards
Philipp

page allocator bug in 3.16?

[Peter Hurley]

After several days uptime with a 3.16 kernel (generally running
Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
desktop workspaces) I've been seeing some really extreme slowdowns.

Mostly the slowdowns are associated with gpu-related tasks, like
opening new emacs windows, switching workspaces, laughing at internet
gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue
it right away -- 3.15 is the first time suspend has worked reliably.

This week I started looking into what the slowdown was and discovered
it's happening during dma allocation through swiotlb (the cpus can do
intel iommu but I don't use it because it's not the default for most users).

I'm still working on a bisection but each step takes 8+ hours to
validate and even then I'm no longer sure I still have the 'bad'
commit in the bisection. [edit: yup, I started over]

I just discovered a smattering of these in my logs and only on 3.16-rc+ kernels:
Sep 25 07:57:59 thor kernel: [28786.001300] alloc_contig_range 
test_pages_isolated(2bf560, 2bf562) failed

This dual-Xeon box has 10GB and sysrq Show Memory isn't showing heavy
fragmentation [1].

Besides Mel's page allocator changes in 3.16, another suspect commit is:

commit b13b1d2d8692b437203de7a404c6b809d2cc4d99
Author: Shaohua Li 
Date:   Tue Apr 8 15:58:09 2014 +0800

x86/mm: In the PTE swapout page reclaim case clear the accessed bit instead 
of flushing the TLB

Specifically, this statement:

It could cause incorrect page aging and the (mistaken) reclaim of
hot pages, but the chance of that should be relatively low.

I'm wondering if this could cause worse-case behavior with TTM? I'm
testing a revert of this on mainline 3.16-final now, with no results yet.

Thoughts?

Regards,
Peter Hurley

[1]
SysRq : Show Memory
Mem-Info:
Node 0 DMA per-cpu:
CPU0: hi:0, btch:   1 usd:   0
CPU1: hi:0, btch:   1 usd:   0
CPU2: hi:0, btch:   1 usd:   0
CPU3: hi:0, btch:   1 usd:   0
CPU4: hi:0, btch:   1 usd:   0
CPU5: hi:0, btch:   1 usd:   0
CPU6: hi:0, btch:   1 usd:   0
CPU7: hi:0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU0: hi:  186, btch:  31 usd:  18
CPU1: hi:  186, btch:  31 usd:  82
CPU2: hi:  186, btch:  31 usd:  46
CPU3: hi:  186, btch:  31 usd:  30
CPU4: hi:  186, btch:  31 usd:  18
CPU5: hi:  186, btch:  31 usd:  43
CPU6: hi:  186, btch:  31 usd: 157
CPU7: hi:  186, btch:  31 usd:  26
Node 0 Normal per-cpu:
CPU0: hi:  186, btch:  31 usd:  25
CPU1: hi:  186, btch:  31 usd:  33
CPU2: hi:  186, btch:  31 usd:  28
CPU3: hi:  186, btch:  31 usd:  46
CPU4: hi:  186, btch:  31 usd:  23
CPU5: hi:  186, btch:  31 usd:   8
CPU6: hi:  186, btch:  31 usd: 112
CPU7: hi:  186, btch:  31 usd:  18
active_anon:382833 inactive_anon:12103 isolated_anon:0
 active_file:1156997 inactive_file:733988 isolated_file:0
 unevictable:15 dirty:35833 writeback:0 unstable:0
 free:129383 slab_reclaimable:95038 slab_unreclaimable:11095
 mapped:81924 shmem:12509 pagetables:9039 bounce:0
 free_cma:0
Node 0 DMA free:15860kB min:104kB low:128kB high:156kB active_anon:0kB 
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
isolated(anon):0kB isolated(file):0kB present:15960kB managed:15876kB 
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB 
slab_unreclaimable:16kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB 
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
lowmem_reserve[]: 0 2974 9980 9980
Node 0 DMA32 free:166712kB min:20108kB low:25132kB high:30160kB 
active_anon:475548kB inactive_anon:15204kB active_file:1368716kB 
inactive_file:865832kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:3127336kB managed:3048188kB mlocked:0kB dirty:38228kB writeback:0kB 
mapped:94340kB shmem:15436kB slab_reclaimable:116424kB 
slab_unreclaimable:12756kB kernel_stack:2512kB pagetables:11532kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 7006 7006
Node 0 Normal free:334960kB min:47368kB low:59208kB high:71052kB 
active_anon:1055784kB inactive_anon:33208kB active_file:3259272kB 
inactive_file:2070120kB unevictable:60kB isolated(anon):0kB isolated(file):0kB 
present:7340032kB managed:7174484kB mlocked:60kB dirty:105104kB writeback:0kB 
mapped:233356kB shmem:34600kB slab_reclaimable:263728kB 
slab_unreclaimable:31608kB kernel_stack:7344kB pagetables:24624kB unstable:0kB 
bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 1*4kB (U) 0*8kB 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 
1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15860kB
Node 0 DMA32: 209*4kB (UEM) 394*8kB (UEM) 303*16kB (UEM) 60*32kB (UEM) 314*64kB 
(UEM) 117*128kB (UEM) 9*256kB (EM) 3*512kB (UEM) 2*1024kB (EM) 2*2048kB (UM) 
27*4096kB (MR) = 166404kB
Node 0 Normal: 

page allocator bug in 3.16?

[Chuck Ebbert]

On Thu, 25 Sep 2014 14:55:02 -0400
Peter Hurley  wrote:

> After several days uptime with a 3.16 kernel (generally running
> Thunderbird, emacs, kernel builds, several Chrome tabs on multiple
> desktop workspaces) I've been seeing some really extreme slowdowns.
> 
> Mostly the slowdowns are associated with gpu-related tasks, like
> opening new emacs windows, switching workspaces, laughing at internet
> gifs, etc. Because this x86_64 desktop is nouveau-based, I didn't pursue
> it right away -- 3.15 is the first time suspend has worked reliably.
> 
> This week I started looking into what the slowdown was and discovered
> it's happening during dma allocation through swiotlb (the cpus can do
> intel iommu but I don't use it because it's not the default for most users).
> 
> I'm still working on a bisection but each step takes 8+ hours to
> validate and even then I'm no longer sure I still have the 'bad'
> commit in the bisection. [edit: yup, I started over]
> 

There are six ttm patches queued for 3.16.4:

drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
drm-ttm-fix-possible-division-by-0-in-ttm_dma_pool_shrink_scan.patch
drm-ttm-fix-possible-stack-overflow-by-recursive-shrinker-calls.patch
drm-ttm-pass-gfp-flags-in-order-to-avoid-deadlock.patch
drm-ttm-use-mutex_trylock-to-avoid-deadlock-inside-shrinker-functions.patch

[Bug 84327] crash in gnome-shell when typing in the app view

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

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

--- Comment #3 from Ray Strode [halfline]  ---
This is fedora 21.

I've tried with:

mesa-libGL-10.3-0.rc1.20140824.fc21.x86_64

and

mesa-libGL-10.3-0.rc3.1.20140906.fc21.x86_64

-- 
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/20140925/b8fe62ad/attachment.html>

[Bug 84327] crash in gnome-shell when typing in the app view

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

  4 1 None
0x140 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0  0  0  0  0  0  0  6 1 None
0x141 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  2 1 None
0x142 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  4 1 None
0x143 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  6 1 None
0x144 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  2 1 None
0x145 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  4 1 None
0x146 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0  0  0  0  0  0  0  6 1 None
0x147 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 16  0  0  0  0  0  2 1 None
0x148 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 16  0  0  0  0  0  4 1 None
0x149 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 16  0  0  0  0  0  6 1 None
0x14a 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 16  0  0  0  0  0  2 1 None
0x14b 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 16  0  0  0  0  0  4 1 None
0x14c 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 16  0  0  0  0  0  6 1 None
0x14d 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 16  0  0  0  0  0  2 1 None
0x14e 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 16  0  0  0  0  0  4 1 None
0x14f 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 16  0  0  0  0  0  6 1 None
0x150 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  0  0  0  0  0  2 1 None
0x151 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  0  0  0  0  0  4 1 None
0x152 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  0  0  0  0  0  6 1 None
0x153 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  0  0  0  0  0  2 1 None
0x154 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  0  0  0  0  0  4 1 None
0x155 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  0  0  0  0  0  6 1 None
0x156 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  0  0  0  0  0  2 1 None
0x157 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  0  0  0  0  0  4 1 None
0x158 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  0  0  0  0  0  6 1 None
0x159 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  2 1 None
0x15a 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  4 1 None
0x15b 24 dc  0  24  0 r  . .   8  8  8  0 .  .  0 24  8  0  0  0  0  6 1 None
0x15c 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  2 1 None
0x15d 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  4 1 None
0x15e 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  6 1 None
0x15f 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  2 1 None
0x160 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  4 1 None
0x161 24 dc  0  24  0 r  y .   8  8  8  0 .  .  0 24  8  0  0  0  0  6 1 None
0x162  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x163  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0  0  0 16 16 16  0  0 0 Slow
0x164  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x165  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0 16 16 16  0  0 0 Slow
0x166  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0  0  0  0  0  0 0 None
0x167  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0  0  0 16 16 16  0  0 0 Slow
0x168  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x169  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x16a  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x16b  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x16c  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0  0  0  0  0  0 0 None
0x16d  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 16  0 16 16 16  0  0 0 Slow
0x16e  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 24  0  0  0  0  0  0 0 None
0x16f  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 24  0 16 16 16  0  0 0 Slow
0x170  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  0  0  0  0  0  0 0 None
0x171  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  0 16 16 16  0  0 0 Slow
0x172  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  0  0  0  0  0  0 0 None
0x173  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  0 16 16 16  0  0 0 Slow
0x174  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x175  0 dc  0  16  0 r  . .   5  6  5  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x176  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x177  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8 16 16 16  0  0 0 Slow
0x178  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8  0  0  0  0  0 0 None
0x179  0 dc  0  16  0 r  y .   5  6  5  0 .  .  0 24  8 16 16 16  0  0 0 Slow

-- 
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/20140925/11080996/attachment-0001.html>

[Bug 84327] crash in gnome-shell when typing in the app view

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

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

Ray Strode [halfline]  changed:

   What|Removed |Added

 CC||rstrode at redhat.com

--- Comment #1 from Ray Strode [halfline]  ---
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] R580
[
Radeon X1900 XT] (prog-if 00 [VGA controller])
Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Radeon X1900 XT/XTX
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Step
ping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: radeon
Kernel modules: radeon

-- 
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/20140925/e0810964/attachment-0001.html>

[Bug 84327] New: crash in gnome-shell when typing in the app view

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

de_bottom_start);
}

float hfade_scale = width / hfade_offset;
if (fade_left) {
ratio *= x / hfade_offset;
}

if (fade_right) {
ratio *= (fade_area_bottomright[0] - x) / (fade_area_bottomright[0]
- fade_right_start);
}

cogl_color_out *= ratio;
}
}

Segmentation fault (core dumped)

-- 
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/20140925/f510811c/attachment.html>

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Vinod Koul]

On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote:
> > > > OK, I guess this is as good as it gets.
> > > > 
> > > > What tree would you like it go through?
> > > 
> > > Do we really need this new helper ? I mean, the very moment when we
> > > decide to implement ->runtime_idle() we will need to get rid of this
> > > change. I wonder if it's really valid...
> > 
> > I'm not sure I'm following?  This seems to simply implement what drivers
> > have been doing already as one function.  Why would it be invalid to reduce
> > code duplication?
> 
> For two reasons:
> 
> 1) the helper has no inteligence whatsoever. It just calls the same
> functions.
> 
> 2) the duplication will vanish whenever someone implements
> ->runtime_idle() and have that call pm_runtime_autosuspend() (like PCI
> and USB buses are doing today). This will just be yet another line that
> needs to change.
> 
> Frankly though, no strong feelings, I just think it's a commit that
> doesn't bring that any benefits other than looking like one line was
> removed.
and yes that is what it tries to do nothing more nothing less. If in future
there are no users (today we have quite a few), then we can remove the dead
macro, no harm. But that is not the situation today.

Thanks
-- 
~Vinod

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

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Vinod Koul]

On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
> 
> OK, I guess this is as good as it gets.
> 
> What tree would you like it go through?

Since rest of the patches are dependent upon 1st patch which should go thru
your tree, we should merge this thru your tree

Thanks
-- 
~Vinod

[PATCH 10/12] video: Add ADV751[13] DT bindings documentation

[Laurent Pinchart]

Hi Geert,

On Thursday 25 September 2014 09:06:46 Geert Uytterhoeven wrote:
> Hi Laurent,
> 
> On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
> 
>  wrote:
> > +- adi,input-style: The input components arrangement variant (1, 2 or 3).
> 
> What's the meaning of the numerical values 1, 2, and 3?
> 
> I found this code in "[PATCH 11/12] drm: Add adv7511 encoder driver":
> 
> +   input_style = config->input_style == 1 ? 2
> +   : (config->input_style == 2 ? 1 : 3);
> 
> which didn't really help much ;-)

:-)

The ADV751[13]W? datasheets document all the supported input formats. They're 
split in categories, each of them having multiple variants called styles. The 
styles are just numbered 1, 2 and 3 in the tables that describe the formats, 
and there's a register field used to select a style. For some reason style 1 
maps to register value 2, style 2 to register value 1, and style 3 to register 
value 3. Go figure...

-- 
Regards,

Laurent Pinchart

Testing LibDRM with Multi-Monitors on VMWare Fusion / Workstation

[Rian Quinn]

I have been doing a lot of work with LibDRM, including Multi-Monitor work on 
Intel and VMWare. Do you guy?s know if there is an easy way to tell VMWare to 
add more virtual display?s for testing? LibDRM reports something like 8 
different connectors, and several CRTCs, so I know it at least supports 
Multi-Monitor, I?m just not sure how to tell the hypervisor to enable more than 
one for testing. 

I?m sure this is a question for a better list, but I figured I cannot be the 
only one interested in working with LibDRM on VMWare. 

Thanks in advance, 
- Rian

[PATCH v2 6/8] drm/radeon: cope with foreign fences inside the reservation object

[Maarten Lankhorst]

Not the whole world is a radeon! :-)

Signed-off-by: Maarten Lankhorst 
---
Changes:
- Removed interruptible parameter, only 1 place has a use for it,
  and it's the only place that can hit it.
- Fail faster in radeon_semaphore_sync_resv.
- Make the break on error in radeon_cs.c more explicit.
- Upgrade the unlikely() to a WARN_ON_ONCE() in radeon_fence_wait, with a 
comment explaining why.

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0d761f73a7fa..7bdf80c2603d 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3993,7 +3993,7 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index c01a6100c318..c473c9125295 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -571,7 +571,7 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c 
b/drivers/gpu/drm/radeon/evergreen_dma.c
index 946f37d0b469..66bcfadeedd1 100644
--- a/drivers/gpu/drm/radeon/evergreen_dma.c
+++ b/drivers/gpu/drm/radeon/evergreen_dma.c
@@ -133,7 +133,7 @@ struct radeon_fence *evergreen_copy_dma(struct 
radeon_device *rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 25f367ac4637..f8eb519c3286 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2912,7 +2912,7 @@ struct radeon_fence *r600_copy_cpdma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
diff --git a/drivers/gpu/drm/radeon/r600_dma.c 
b/drivers/gpu/drm/radeon/r600_dma.c
index fc54224ce87b..a49db830a47f 100644
--- a/drivers/gpu/drm/radeon/r600_dma.c
+++ b/drivers/gpu/drm/radeon/r600_dma.c
@@ -470,7 +470,7 @@ struct radeon_fence *r600_copy_dma(struct radeon_device 
*rdev,
return ERR_PTR(r);
}

-   radeon_semaphore_sync_resv(sem, resv, false);
+   radeon_semaphore_sync_resv(rdev, sem, resv, false);
radeon_semaphore_sync_rings(rdev, sem, ring->idx);

for (i = 0; i < num_loops; i++) {
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 864457cd7c98..07aa961bf5ca 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -589,9 +589,10 @@ bool radeon_semaphore_emit_wait(struct radeon_device 
*rdev, int ring,
struct radeon_semaphore *semaphore);
 void radeon_semaphore_sync_fence(struct radeon_semaphore *semaphore,
 struct radeon_fence *fence);
-void radeon_semaphore_sync_resv(struct radeon_semaphore *semaphore,
-   struct reservation_object *resv,
-   bool shared);
+int radeon_semaphore_sync_resv(struct radeon_device *rdev,
+  struct radeon_semaphore *semaphore,
+  struct reservation_object *resv,
+  bool shared);
 int radeon_semaphore_sync_rings(struct radeon_device *rdev,
struct radeon_semaphore *semaphore,
int waiting_ring);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index f662de41ba49..1c893447d7cd 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -249,9 +249,9 @@ static int radeon_cs_get_ring(struct radeon_cs_parser *p, 
u32 ring, s32 priority
return 0;
 }

-static void radeon_cs_sync_rings(struct radeon_cs_parser *p)
+static int radeon_cs_sync_rings(struct radeon_cs_parser *p)
 {
-   int i;
+   int i, r = 0;

for (i = 0; i < p->nrelocs; i++) {
struct reservation_object *resv;
@@ -260,9 +260,13 @@ static void radeon_cs_sync_rings(struct radeon_cs_parser 
*p)
continue;

resv = 

[PATCH] drm/exynos/fbdev: set smem_len for fbdev

[Geert Uytterhoeven]

On Thu, Sep 25, 2014 at 12:07 PM, Daniel Kurtz  wrote:
> On Thu, Sep 25, 2014 at 5:32 PM, Geert Uytterhoeven
>  wrote:
>> On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz  
>> wrote:
>>> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
>>> the fbdev.
>>>
>>> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
>>>   drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
>>>
>>> However, smem_len is used by some userland applications to calculate the
>>> size for mmap.  In particular, it is used by xf86-video-fbdev:
>>>
>>> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571
>>>
>>> So, let's restore setting the smem_len to unbreak things for these users.
>>>
>>> Note: we are still leaving smem_start set to 0.
>>
>> Doesn't this cause a system crash when userspace (e.g. fbtest) writes into
>> the mmap()ed /dev/fb*, as the wrong MMIO region is mapped?
>
> Do you see a crash during testing, or is your question hypothetical?

It was hypothetical.

> I don't think there will be one.  exynos's fbev defines its own
> fb_ops.fb_mmap, which uses dma_mmap_attrs() to mmap the fb's gem
> buffer, which was allocated by dma_alloc_attrs().  This bypasses the
> code in drivers/video/fbmem.c:fb_mmap() that references
> fix.smem_start.
>
> But, perhaps I am missing something?

Thanks, having your own mapping function explains the lack of crashes.

Still, some weird software may map /dev/mem instead of /dev/fb0, and
use fb_fix.smem_start. But that's also unsafe in the context of LPAE.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 10/12] video: Add ADV751[13] DT bindings documentation

[Geert Uytterhoeven]

Hi Laurent,

On Thu, Sep 25, 2014 at 11:57 AM, Laurent Pinchart
 wrote:
> On Thursday 25 September 2014 09:06:46 Geert Uytterhoeven wrote:
>> On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
>>  wrote:
>> > +- adi,input-style: The input components arrangement variant (1, 2 or 3).
>>
>> What's the meaning of the numerical values 1, 2, and 3?
>>
>> I found this code in "[PATCH 11/12] drm: Add adv7511 encoder driver":
>>
>> +   input_style = config->input_style == 1 ? 2
>> +   : (config->input_style == 2 ? 1 : 3);
>>
>> which didn't really help much ;-)
>
> :-)
>
> The ADV751[13]W? datasheets document all the supported input formats. They're
> split in categories, each of them having multiple variants called styles. The
> styles are just numbered 1, 2 and 3 in the tables that describe the formats,
> and there's a register field used to select a style. For some reason style 1
> maps to register value 2, style 2 to register value 1, and style 3 to register
> value 3. Go figure...

Thanks, that explains it.

Then I suggest to reflect this in the binding:

- adi,input-style: The input components arrangement variant (1, 2 or 3),
   as listed in the datasheet.

and in the code, e.g. by translating the values using a mapping array?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Stephen Warren]

On 09/25/2014 10:41 AM, Thierry Reding wrote:
> On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote:
>> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>>> still required for enabling the GPU. Is there anything blocking it (firmware
>>> not available yet in liux-firmware?)
>>
>> I think initially I was waiting for the DRM patch "drm/nouvea: support for
>> probing platform devices" to be applied, but it looks like that's been
>> applied already, so only patches 4 and 5 in this series are still
>> outstanding.
>>
>> Alex, wasn't there also some issue where the VPR register had to be
>> programmed, and if it wasn't there'd be a hang when the GPU registers were
>> touched? If we've added code to Nouveau/tegradrm to detect that and avoid
>> the problem, then I guess we can commit these last two patches for 3.19. A
>> resend after the 3.18 merge window might help.
>
> A patch that programs VPR was merged into U-Boot (though I don't think
> it's made it into master yet). I'm not sure we can reasonably check for
> that in Nouveau, given that the register is somewhere completely
> unrelated. In fact I think the U-Boot patch was triggered by some
> discussion about how to solve this and it was decided that it shouldn't
> be done in the kernel, but U-Boot should set it up.
>
> That said, perhaps one solution would be to make U-Boot enable the gk20a
> device if it's set up the VPR and disable it otherwise?

For that to work, we'd need the DT to say status="disabled" by default 
for the GPU, and for the fixed U-Boot (and indeed every other 
bootloader...) to enable the GPU node. This would allow people with old 
versions of U-Boot (or other bootloaders) to continue to boot. This 
means bootloaders would only have to set status="okay", but never have 
to set status="disabled", which at least simplifies them a tiny bit.

[PATCH 6/8] drm/radeon: cope with foreign fences inside the reservation object

[Maarten Lankhorst]

Op 17-09-14 om 15:09 schreef Christian K?nig:
> Am 17.09.2014 um 14:35 schrieb Maarten Lankhorst:
>> Not the whole world is a radeon! :-)
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>   drivers/gpu/drm/radeon/cik.c  |  2 +-
>>   drivers/gpu/drm/radeon/cik_sdma.c |  2 +-
>>   drivers/gpu/drm/radeon/evergreen_dma.c|  2 +-
>>   drivers/gpu/drm/radeon/r600.c |  2 +-
>>   drivers/gpu/drm/radeon/r600_dma.c |  2 +-
>>   drivers/gpu/drm/radeon/radeon.h   |  7 ---
>>   drivers/gpu/drm/radeon/radeon_cs.c| 27 ---
>>   drivers/gpu/drm/radeon/radeon_fence.c |  3 +++
>>   drivers/gpu/drm/radeon/radeon_semaphore.c | 24 ++--
>>   drivers/gpu/drm/radeon/radeon_vm.c|  4 ++--
>>   drivers/gpu/drm/radeon/rv770_dma.c|  2 +-
>>   drivers/gpu/drm/radeon/si_dma.c   |  2 +-
>>   12 files changed, 54 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index 0d761f73a7fa..1440b6e9281e 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -3993,7 +3993,7 @@ struct radeon_fence *cik_copy_cpdma(struct 
>> radeon_device *rdev,
>>   return ERR_PTR(r);
>>   }
>>   -radeon_semaphore_sync_resv(sem, resv, false);
>> +radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>> for (i = 0; i < num_loops; i++) {
>> diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
>> b/drivers/gpu/drm/radeon/cik_sdma.c
>> index c01a6100c318..315c595418ec 100644
>> --- a/drivers/gpu/drm/radeon/cik_sdma.c
>> +++ b/drivers/gpu/drm/radeon/cik_sdma.c
>> @@ -571,7 +571,7 @@ struct radeon_fence *cik_copy_dma(struct radeon_device 
>> *rdev,
>>   return ERR_PTR(r);
>>   }
>>   -radeon_semaphore_sync_resv(sem, resv, false);
>> +radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>> for (i = 0; i < num_loops; i++) {
>> diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c 
>> b/drivers/gpu/drm/radeon/evergreen_dma.c
>> index 946f37d0b469..5a5686792068 100644
>> --- a/drivers/gpu/drm/radeon/evergreen_dma.c
>> +++ b/drivers/gpu/drm/radeon/evergreen_dma.c
>> @@ -133,7 +133,7 @@ struct radeon_fence *evergreen_copy_dma(struct 
>> radeon_device *rdev,
>>   return ERR_PTR(r);
>>   }
>>   -radeon_semaphore_sync_resv(sem, resv, false);
>> +radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>> for (i = 0; i < num_loops; i++) {
>> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
>> index 25f367ac4637..35c22ee9bc4a 100644
>> --- a/drivers/gpu/drm/radeon/r600.c
>> +++ b/drivers/gpu/drm/radeon/r600.c
>> @@ -2912,7 +2912,7 @@ struct radeon_fence *r600_copy_cpdma(struct 
>> radeon_device *rdev,
>>   return ERR_PTR(r);
>>   }
>>   -radeon_semaphore_sync_resv(sem, resv, false);
>> +radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>> radeon_ring_write(ring, PACKET3(PACKET3_SET_CONFIG_REG, 1));
>> diff --git a/drivers/gpu/drm/radeon/r600_dma.c 
>> b/drivers/gpu/drm/radeon/r600_dma.c
>> index fc54224ce87b..674af8db7a35 100644
>> --- a/drivers/gpu/drm/radeon/r600_dma.c
>> +++ b/drivers/gpu/drm/radeon/r600_dma.c
>> @@ -470,7 +470,7 @@ struct radeon_fence *r600_copy_dma(struct radeon_device 
>> *rdev,
>>   return ERR_PTR(r);
>>   }
>>   -radeon_semaphore_sync_resv(sem, resv, false);
>> +radeon_semaphore_sync_resv(rdev, sem, resv, false, false);
>>   radeon_semaphore_sync_rings(rdev, sem, ring->idx);
>> for (i = 0; i < num_loops; i++) {
>> diff --git a/drivers/gpu/drm/radeon/radeon.h 
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 9aa75c1af4f4..6cdc5e62fe12 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -587,9 +587,10 @@ bool radeon_semaphore_emit_wait(struct radeon_device 
>> *rdev, int ring,
>>   struct radeon_semaphore *semaphore);
>>   void radeon_semaphore_sync_fence(struct radeon_semaphore *semaphore,
>>struct radeon_fence *fence);
>> -void radeon_semaphore_sync_resv(struct radeon_semaphore *semaphore,
>> -struct reservation_object *resv,
>> -bool shared);
>> +int radeon_semaphore_sync_resv(struct radeon_device *rdev,
>> +   struct radeon_semaphore *semaphore,
>> +   struct reservation_object *resv,
>> +   bool shared, bool intr);
>>   int radeon_semaphore_sync_rings(struct radeon_device *rdev,
>>   struct radeon_semaphore *semaphore,
>>   int waiting_ring);
>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
>> 

[PATCH 2/2] drm/nouveau: Allow noaccel to be a pci address

[Pierre Moreau]

noaccel option now defaults to null which has no effect, it can still equal 1,
which disables acceleration for all cards, or be a pci address and disable
acceleration for that card only

Signed-off-by: Pierre Moreau 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 244d78f..04bd8f1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -61,9 +61,10 @@ MODULE_PARM_DESC(debug, "debug string to pass to driver 
core");
 static char *nouveau_debug;
 module_param_named(debug, nouveau_debug, charp, 0400);

-MODULE_PARM_DESC(noaccel, "disable kernel/abi16 acceleration");
-static int nouveau_noaccel = 0;
-module_param_named(noaccel, nouveau_noaccel, int, 0400);
+MODULE_PARM_DESC(noaccel, "disable kernel/abi16 acceleration for all cards,"
+ "or only for the card given its pci bus name");
+static char *nouveau_noaccel;
+module_param_named(noaccel, nouveau_noaccel, charp, 0400);

 MODULE_PARM_DESC(modeset, "enable driver (default: auto, "
  "0 = disabled, 1 = enabled, 2 = headless)");
@@ -149,8 +150,13 @@ nouveau_accel_init(struct nouveau_drm *drm)
u32 sclass[16];
int ret, i;

-   if (nouveau_noaccel)
+   if (nouveau_noaccel != NULL &&
+   (!strcmp(nouveau_noaccel, "1") ||
+!strcmp(nouveau_noaccel, nvkm_device(device)->name)))
+   {
+   NV_WARN(drm, "Acceleration disabled for card on bus %s\n", 
nvkm_device(device)->name);
return;
+   }

/* initialise synchronisation routines */
/*XXX: this is crap, but the fence/channel stuff is a little
@@ -1039,7 +1045,7 @@ static void nouveau_display_options(void)
DRM_DEBUG_DRIVER("... nofbaccel: %d\n", nouveau_nofbaccel);
DRM_DEBUG_DRIVER("... config   : %s\n", nouveau_config);
DRM_DEBUG_DRIVER("... debug: %s\n", nouveau_debug);
-   DRM_DEBUG_DRIVER("... noaccel  : %d\n", nouveau_noaccel);
+   DRM_DEBUG_DRIVER("... noaccel  : %s\n", nouveau_noaccel);
DRM_DEBUG_DRIVER("... modeset  : %d\n", nouveau_modeset);
DRM_DEBUG_DRIVER("... runpm: %d\n", nouveau_runtime_pm);
DRM_DEBUG_DRIVER("... vram_pushbuf : %d\n", nouveau_vram_pushbuf);
-- 
2.1.0

[PATCH 1/2] drm/nouveau/disp/nv50: Add PFB writes

[Pierre Moreau]

This fix a GPU lockup on 9400M (NVAC) when using acceleration, see #27501.

Signed-off-by: Pierre Moreau 
---
 drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
index a7efbff..e425604 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
@@ -1137,6 +1137,15 @@ nv50_disp_base_init(struct nouveau_object *object)
if (ret)
return ret;

+   if (nv_device(priv)->chipset == 0xac) {
+   nv_mask(priv, 0x100c18, 0x, 0x27ff);
+   nv_mask(priv, 0x100c14, 0x, 0x0001);
+   nv_mask(priv, 0x100c1c, 0x, 0x27fc);
+   nv_mask(priv, 0x100c14, 0x, 0x0002);
+   nv_mask(priv, 0x100c24, 0x0002, 0x27fd);
+   nv_mask(priv, 0x100c14, 0x, 0x0001);
+   }
+
/* The below segments of code copying values from one register to
 * another appear to inform EVO of the display capabilities or
 * something similar.  NFI what the 0x614004 caps are for..
-- 
2.1.0

[PATCH] drm/exynos/fbdev: set smem_len for fbdev

[Geert Uytterhoeven]

On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz  wrote:
> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating
> the fbdev.
>
> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3
>   drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}
>
> However, smem_len is used by some userland applications to calculate the
> size for mmap.  In particular, it is used by xf86-video-fbdev:
>
> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571
>
> So, let's restore setting the smem_len to unbreak things for these users.
>
> Note: we are still leaving smem_start set to 0.

Doesn't this cause a system crash when userspace (e.g. fbtest) writes into
the mmap()ed /dev/fb*, as the wrong MMIO region is mapped?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

ACPI/i915: Cannot configure display brightness on Dell Latitude E6440

[Aaron Lu]

Hi Hans,

Thanks for following up and explaining the situation to Pali.

On 09/25/2014 02:21 AM, Pali Roh?r wrote:
> On Wednesday 24 September 2014 16:34:21 Hans de Goede wrote:
>> Ok, so the dell-laptop interface is just an obsolete wrapper
>> around the i915 opregion code, which shows that the right
>> interface to use is the i915 one, which we do if you don't
>> specify any kernel commandline parameters, case closed.
>>
>> Regards,
>>
>> Hans
> 
> Nope, its not closed.
> 
> Still i915 interface has problem with setting backlight. It 
> exports lot of levels which turning display off. Which breaking 
> exiting applications for configuring display brightness. This is 
> still big regression as black screen is not want people want to 
> see.
> 
> Driver dell-laptop has exported only few - not thousands level 
> (which is insane) and only usefull levels (not lot of levels 
> which turn display off).
> 
> So for this reason using i915 backlight interface is not possible 
> and also Dell (for E6440) set kernel param acpi_backlight=vendor 
> to use dell_laptop module for controlling brightness.
> 
> On my laptop E6440 is better for using dell-laptop and not acpi 
> or i915.

Hi Pali,

Please test this patch:

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index ca52ad2ae7d1..15534345bd57 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -396,6 +396,24 @@ int intel_opregion_notify_adapter(struct drm_device *dev, 
pci_power_t state)
return -EINVAL;
 }

+/*
+ * Some of the Thinkpads' firmware will issue a backlight change operation
+ * region request unconditionally on AC plug/unplug, this is undesirable and
+ * should be ignored. Then there is a Dell laptop whose vendor backlight
+ * interface also makes use of operation region request to change backlight
+ * level and we have to keep it work. The rule used here is: if the vendor
+ * backlight interface is not in use and the ACPI backlight interface is
+ * broken, we ignore the requests; oterwise, we keep processing them.
+ */
+static bool should_ignore_backlight_request(void)
+{
+   if (acpi_video_backlight_support() &&
+   !acpi_video_verify_backlight_support())
+   return true;
+
+   return false;
+}
+
 static u32 asle_set_backlight(struct drm_device *dev, u32 bclp)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -404,11 +422,7 @@ static u32 asle_set_backlight(struct drm_device *dev, u32 
bclp)

DRM_DEBUG_DRIVER("bclp = 0x%08x\n", bclp);

-   /*
-* If the acpi_video interface is not supposed to be used, don't
-* bother processing backlight level change requests from firmware.
-*/
-   if (!acpi_video_verify_backlight_support()) {
+   if (should_ignore_backlight_request()) {
DRM_DEBUG_KMS("opregion backlight request ignored\n");
return 0;
}

[5/5] ARM: tegra: jetson-tk1: enable GK20A GPU

[Stephen Warren]

On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
> Playing a bit with todays linux-next on my jetson, it seems this patch is
> still required for enabling the GPU. Is there anything blocking it (firmware
> not available yet in liux-firmware?)

I think initially I was waiting for the DRM patch "drm/nouvea: support 
for probing platform devices" to be applied, but it looks like that's 
been applied already, so only patches 4 and 5 in this series are still 
outstanding.

Alex, wasn't there also some issue where the VPR register had to be 
programmed, and if it wasn't there'd be a hang when the GPU registers 
were touched? If we've added code to Nouveau/tegradrm to detect that and 
avoid the problem, then I guess we can commit these last two patches for 
3.19. A resend after the 3.18 merge window might help.

> On Mon, May 19, 2014 at 06:24:10PM +0900, Alexandre Courbot wrote:
>> Signed-off-by: Alexandre Courbot 
>> ---
>>   arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
>> b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> index e31fb61a81d3..15a194d1277f 100644
>> --- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> +++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
>> @@ -30,6 +30,12 @@
>>  };
>>  };
>>
>> +gpu at 0,5700 {
>> +status = "okay";
>> +
>> +vdd-supply = <_gpu>;
>> +};
>> +
>>  pinmux: pinmux at 0,7868 {
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_default>;
>> @@ -1505,7 +1511,7 @@
>>  regulator-always-on;
>>  };
>>
>> -sd6 {
>> +vdd_gpu: sd6 {
>>  regulator-name = "+VDD_GPU_AP";
>>  regulator-min-microvolt = <65>;
>>  regulator-max-microvolt = <120>;
>

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Felipe Balbi]

On Thu, Sep 25, 2014 at 01:27:18PM +0530, Vinod Koul wrote:
> On Wed, Sep 24, 2014 at 03:32:19PM -0500, Felipe Balbi wrote:
> > > > > OK, I guess this is as good as it gets.
> > > > > 
> > > > > What tree would you like it go through?
> > > > 
> > > > Do we really need this new helper ? I mean, the very moment when we
> > > > decide to implement ->runtime_idle() we will need to get rid of this
> > > > change. I wonder if it's really valid...
> > > 
> > > I'm not sure I'm following?  This seems to simply implement what drivers
> > > have been doing already as one function.  Why would it be invalid to 
> > > reduce
> > > code duplication?
> > 
> > For two reasons:
> > 
> > 1) the helper has no inteligence whatsoever. It just calls the same
> > functions.
> > 
> > 2) the duplication will vanish whenever someone implements
> > ->runtime_idle() and have that call pm_runtime_autosuspend() (like PCI
> > and USB buses are doing today). This will just be yet another line that
> > needs to change.
> > 
> > Frankly though, no strong feelings, I just think it's a commit that
> > doesn't bring that any benefits other than looking like one line was
> > removed.
> and yes that is what it tries to do nothing more nothing less. If in future
> there are no users (today we have quite a few), then we can remove the dead
> macro, no harm. But that is not the situation today.

as I said, a commit that's bound to be useless. It's not like you're
saving 10 lines of code, it's only one. Replacing two simple lines with
a function which takes  almost as many characters to type .

IMO, this is pretty useless and I'd rather not see them in the drivers I
maintain, sorry.

cheers

-- 
balbi
-- 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/20140925/99ac80ca/attachment-0001.sig>

[PATCH 10/12] video: Add ADV751[13] DT bindings documentation

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
 wrote:
> +- adi,input-style: The input components arrangement variant (1, 2 or 3).

What's the meaning of the numerical values 1, 2, and 3?

I found this code in "[PATCH 11/12] drm: Add adv7511 encoder driver":

+   input_style = config->input_style == 1 ? 2
+   : (config->input_style == 2 ? 1 : 3);

which didn't really help much ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH v4 1/5] drm/rockchip: Add basic drm driver

[Mark yao]

On 2014?09?24? 19:20, Daniel Vetter wrote:
> On Wed, Sep 24, 2014 at 11:31 AM, Mark yao  wrote:
>> On 2014?09?24? 16:20, Daniel Vetter wrote:
>>> On Mon, Sep 22, 2014 at 06:48:54PM +0800, Mark yao wrote:
>>>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>>>
>>>> Signed-off-by: Mark yao 
>>>> ---
>>>> Changes in v2:
>>>> - use the component framework to defer main drm driver probe
>>>> until all VOP devices have been probed.
>>>> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
>>>> master device and each vop device can shared the drm dma mapping.
>>>> - use drm_crtc_init_with_planes and drm_universal_plane_init.
>>>> - remove unnecessary middle layers.
>>>> - add cursor set, move funcs to rockchip drm crtc.
>>>> - use vop reset at first init
>>>> - reference framebuffer when used and unreference when swap out vop
>>>>
>>>> Changes in v3:
>>>> - change "crtc->fb" to "crtc->primary-fb"
>>>> Adviced by Daniel Vetter
>>>> - init cursor plane with universal api, remove unnecessary cursor
>>>> set,move
>>>>
>>>> Changes in v4:
>>>> Adviced by David Herrmann
>>>> - remove drm_platform_*() usage, use register drm device directly.
>>>> Adviced by Rob Clark
>>>> - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap
>>>> offset
>>>>
>>>>drivers/gpu/drm/Kconfig   |2 +
>>>>drivers/gpu/drm/Makefile  |1 +
>>>>drivers/gpu/drm/rockchip/Kconfig  |   19 +
>>>>drivers/gpu/drm/rockchip/Makefile |   10 +
>>>>drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  524 ++
>>>>drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  120 +++
>>>>drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
>>>>drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
>>>>drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  231 +
>>>>drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
>>>>drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  404 
>>>>drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   72 ++
>>>>drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1372
>>>> +
>>>>drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  187 
>>>>include/uapi/drm/rockchip_drm.h   |   75 ++
>>> uapi is still here ... Was this an oversight?
>>> -Daniel
>>>
>> Hi, Daniel
>> this version is old, newest is v5. and I remove uapi at v5.
>> you can see v5 patch at:
>> https://lkml.org/lkml/2014/9/23/1061
>> thanks
> This version doesn't seem to be cc'ed to dri-devel, at least it didn't
> yet show up. Can you please double-check?
actually I cc the v5 version to dri-devel at lists.freedesktop.org.
and we can found the patch at 
https://patchwork.kernel.org/patch/4967501/( *Project*: dri-devel)
>
> Thanks, Daniel
>
>
>

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

[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Thierry Reding]

On Wed, Sep 24, 2014 at 12:08:37PM +0300, Tomi Valkeinen wrote:
> On 23/09/14 17:58, Thierry Reding wrote:
> 
> >> But if a panel driver controls its video source, it makes sense for the
> >> panel driver to get its video source in its probe, and that happens
> >> easiest if the panel has a link to the video source.
> > 
> > That's an orthogonal problem. You speak about the link in software here,
> > whereas the phandles only represent the link in the description of
> > hardware. Now DT describes hardware from the perspective of the CPU, so
> > it's sort of like a cave that you're trying to explore. You start at the
> > top with the address bus, from where a couple of tunnels lead to the
> > various peripherals on the address bus. A display controller might have
> > another tunnel to a panel, etc.
> 
> We don't do that for GPIOs, regulators, etc. either. And for video data
> there are no address buses. Yes, for DSI and similar we have a control
> bus, but that is modeled differently than the video data path.

GPIOs and regulators are just auxiliary devices that some other device
needs to operate. For instance if you want to know how to operate the
GPIO or regulator, the same still applies. You start from the CPU and
look up the GPIO controller and then the index of the GPIO within that
controller. For regulators you'd typically go and look for an I2C bus
that has a PMIC, which will expose the regulator.

Now for a device such as a display panel, what you want to do is control
the display panel. If part of how you control it involves toggling a
GPIO or a regulator, then you get access to those via phandles. And then
controlling the GPIO and regulator becomes the same as above. So it's a
matter of compositing devices in that case.

For the video data you use the phandles to model the path that video
data takes, with all the devices in that path chained together. So while
both approaches use the same mechanism (phandle) to describe the
relationships, the nature of the relationships is quite different.

> Now, I'm fine with starting from the CPU, going outwards. I agree that
> it's probably better to model it in the direction of the data stream,
> even if that would make the SW a bit more complex.
> 
> However, I do think it's not as clear as you make it sound, especially
> if we take cameras/sensors into account as Laurent explained elsewhere
> in this thread.

How are cameras different? The CPU wants to capture video data from the
camera, so it needs to go look for a video capture device, which in turn
needs to involve a sensor.

It isn't so much about following the data stream itself, but rather the
connections between devices that the CPU needs to involve in order to
initiate the data flow.

> > If you go the other way around, how do you detect how things connect?
> > Where do you get the information about the panel so you can trace back
> > to the origin?
> 
> When the panel driver probes, it registers itself as a panel and gets
> its video source. Similarly a bridge in between gets its video source,
> which often would be the SoC, i.e. the origin.

That sounds backwards to me. The device tree serves the purpose of
supplementing missing information that can't be probed if hardware is
too stupid. I guess that's one of the primary reasons for structuring it
the way we do, from the CPU point of view, because it allows the CPU to
probe via the device tree.

Probing is always done downstream, so you'd start by looking at some
type of bus interface and query it for what devices are present on the
bus. Take for example PCI: the CPU only needs to know how to access the
host bridge and will then probe devices behind each of the ports on that
bridge. Some of those devices will be bridges, too, so it will continue
to probe down the hierarchy.

Without DT you don't have a means to know that there was a panel before
you've actually gone and probed your whole hierarchy and found a GPU
with some sort of output that a panel can be connected to. I think it
makes a lot of sense to describe things in the same way in DT.

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

[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address

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

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

--- Comment #17 from Christian K?nig  ---
(In reply to comment #16)
> (In reply to comment #15)
> > 1. I do not add cpu_to_le32() first ,but when I trace the messages from
> > printk,the value of msg_type is reversed.
> 
> That's in radeon_uvd_cs_msg()? Sounds like the Mesa UVD code writes the
> messages in host byte order, not in little endian. Maybe Christian can
> clarify which byte order should be used for them.

The hardware supports byte swapping for the message and feedback buffer, but I
think always writing/reading it in little endian will be simpler to get
working.

The userspace code currently doesn't supports big endian hosts and so will
probably write it in the wrong byte order.

-- 
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/20140925/2be8444d/attachment-0001.html>

[PULL] topic/core-stuff

[Dave Airlie]

On 25 September 2014 03:59, Daniel Vetter  wrote:
> On Wed, Sep 24, 2014 at 6:24 PM, Ilia Mirkin  wrote:
>> On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter  
>> wrote:
>>> Hi Dave,
>>>
>>> Just noticed that you've picked up the header rework stuff already, so
>>> I've rebased that out again. Otherwise just two stragglers from the vblank
>>> rework and the universal cursor planes locking fix. Plus sprinkling
>>> container_of all over fbdev emulation from Fabian.
>>
>> I thought it was questionable whether these were desired... the
>> pattern of casting between structs that contain others as bases is a
>> pretty common one, and container_of just makes it harder to read. Did
>> the discussion end in a way that concluded the opposite? I might have
>> missed it.
>
> I like them since you can employ gcc to check mundane stuff for you.
> And container_of is so massively established in the kernel (with
> list_head alone) that I don't think any serious kernel hacker has
> problem's reading it. Alan Cox complained a bit a bit on imo elitist
> grounds so until someone goes on record with an official Nack I think
> they're worth it.

I like them, but I don't want to encourage them, they are over time
going to just be conflict
creators, which makes it sounds like work for me,

So I don't mind this batch for the fbdev, but I don't want to see
anymore unless they provide more value.

also I'm on holidays until Tuesday, I'll have some access to stuff,
but won't be on top of urgent things, so hopefully nothing urgent
happens.

Dave.

nouveau (NV50) regression 3.17-rc1; dpms stopped working

[Jamie Heilman]

With 3.17-rc1 DPMS stopped working.  I've bisected this to
d55b4af909bc16f7982c2b8b8656f0898158627b testing along the way with
xset dpms force off.  Controller is:

  NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)

That commit doesn't revert cleanly.  I took a look around and found a
couple of bugs that made it sound like DPMS issues with DP have been
ongoing for a while, but this is a DVI connection in my case (to a
single Dell 2405FPW).  Then I found bug 82527, which mentioned the
problem exactly.

My experience with log capture around the xset dpms force off command
is exactly the same as Martin's in that bug.  No additional output.

Prior to d55b4af909bc16f7982c2b8b8656f0898158627b I didn't have any
serious problems (the immediate switching back on of the screen after
a xset dpms force off the first time not withstanding, I've lived with
that for years).

-- 
Jamie Heilman http://audible.transient.net/~jamie/

[Bug 83708] [vdpau,uvd] kernel oops, Unable to handle kernel paging request at virtual address

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

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

--- Comment #16 from Michel D?nzer  ---
(In reply to comment #15)
> 1. I do not add cpu_to_le32() first ,but when I trace the messages from
> printk,the value of msg_type is reversed.

That's in radeon_uvd_cs_msg()? Sounds like the Mesa UVD code writes the
messages in host byte order, not in little endian. Maybe Christian can clarify
which byte order should be used for them.


> 2. #if 0 ...#endif is the original code from kernel. #if 1 ...#endif is
> changed code.

Ah right, never mind, I misread that hunk before.


> By the way, u said writel() and readl() already convert to/from little
> endian. is based on the X86 arch implement?

It's the same on all architectures: writel() takes a datum in host byte order
and writes it in little endian. readl() reads a little endian datum and returns
it in host byte order. (This means that on little endian hosts such as x86, the
datum is transferred unchanged)

-- 
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/20140925/bedd4592/attachment.html>

[Bug 83748] Only black content on screen, in the Tokyo flashback of the game "The Secret World"

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

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

--- Comment #11 from John  ---
I was hoping Marek's latest big patchset would help, but it didn't... (well
maybe the game was a little faster but that is not what I am looking for here).

-- 
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/20140925/ac79655c/attachment.html>

[PATCH v5 1/3] drm/rockchip: Add basic drm driver

[Daniel Kurtz]

Hi Mark,

Please review comments inline...

On Wed, Sep 24, 2014 at 10:12 AM, Mark yao  wrote:
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark yao 
> ---
> Changes in v2:
> - use the component framework to defer main drm driver probe
>   until all VOP devices have been probed.
> - use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
>   master device and each vop device can shared the drm dma mapping.
> - use drm_crtc_init_with_planes and drm_universal_plane_init.
> - remove unnecessary middle layers.
> - add cursor set, move funcs to rockchip drm crtc.
> - use vop reset at first init
> - reference framebuffer when used and unreference when swap out vop
>
> Changes in v3:
> - change "crtc->fb" to "crtc->primary-fb"
> Adviced by Daniel Vetter
> - init cursor plane with universal api, remove unnecessary cursor set,move
>
> Changes in v4:
> Adviced by David Herrmann
> - remove drm_platform_*() usage, use register drm device directly.
> Adviced by Rob Clark
> - remove special mmap ioctl, do userspace mmap with normal mmap() or mmap 
> offset
>
> Changes in v5:
> Adviced by Arnd Bergmann
> - doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
> - fix some incorrect dependencies.
> Adviced by Boris BREZILLON
> - fix some mistake and bugs.
> Adviced by Daniel Vetter
> - drop all special ioctl and use generic kms ioctl instead.
> Adviced by Rob Clark
> - use unlocked api for drm_fb_helper_restore_fbdev_mode.
> - remove unused rockchip_gem_prime_import_sg_table.
>
>  drivers/gpu/drm/Kconfig   |2 +
>  drivers/gpu/drm/Makefile  |1 +
>  drivers/gpu/drm/rockchip/Kconfig  |   17 +
>  drivers/gpu/drm/rockchip/Makefile |8 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  509 +
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |  120 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  201 
>  drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  230 +
>  drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  341 ++
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   55 +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1373 
> +
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  187 
>  14 files changed, 3092 insertions(+)
>  create mode 100644 drivers/gpu/drm/rockchip/Kconfig
>  create mode 100644 drivers/gpu/drm/rockchip/Makefile
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>  create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b066bb3..7c4c3c6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -171,6 +171,8 @@ config DRM_SAVAGE
>
>  source "drivers/gpu/drm/exynos/Kconfig"
>
> +source "drivers/gpu/drm/rockchip/Kconfig"
> +
>  source "drivers/gpu/drm/vmwgfx/Kconfig"
>
>  source "drivers/gpu/drm/gma500/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 4a55d59..d03387a 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
>  obj-$(CONFIG_DRM_VIA)  +=via/
>  obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
>  obj-$(CONFIG_DRM_EXYNOS) +=exynos/
> +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
>  obj-$(CONFIG_DRM_GMA500) += gma500/
>  obj-$(CONFIG_DRM_UDL) += udl/
>  obj-$(CONFIG_DRM_AST) += ast/
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> new file mode 100644
> index 000..87255f7
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -0,0 +1,17 @@
> +config DRM_ROCKCHIP
> +   tristate "DRM Support for Rockchip"
> +   depends on DRM && ROCKCHIP_IOMMU && ARM_DMA_USE_IOMMU && IOMMU_API
> +   select DRM_KMS_HELPER
> +   select DRM_KMS_FB_HELPER
> +   select DRM_PANEL
> +   select FB_CFB_FILLRECT
> +   select FB_CFB_COPYAREA
> +   select FB_CFB_IMAGEBLIT
> +   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> +   select VIDEOMODE_HELPERS
> +   help
> + Choose this option if you have a Rockchip soc chipset.
> + This driver provides kernel mode setting and buffer
> + management to userspace. This driver does not provides
> + 2D or 3D acceleration; 

[PATCH v4 23/23] amdkfd: Implement the Get Process Aperture IOCTL

[Oded Gabbay]

From: Alexey Skidanov 

v3: Fixed debug messages

Signed-off-by: Alexey Skidanov 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c | 47 -
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h|  5 +++
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
index 1e4b731..bf9ea51 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
@@ -406,7 +406,52 @@ static long kfd_ioctl_get_clock_counters(struct file 
*filep, struct kfd_process

 static int kfd_ioctl_get_process_apertures(struct file *filp, struct 
kfd_process *p, void __user *arg)
 {
-   return -ENODEV;
+   struct kfd_ioctl_get_process_apertures_args args;
+   struct kfd_process_device *pdd;
+
+   dev_dbg(kfd_device, "get apertures for PASID %d", p->pasid);
+
+   if (copy_from_user(, arg, sizeof(args)))
+   return -EFAULT;
+
+   args.num_of_nodes = 0;
+
+   mutex_lock(>mutex);
+
+   /*if the process-device list isn't empty*/
+   if (kfd_has_process_device_data(p)) {
+   /* Run over all pdd of the process */
+   pdd = kfd_get_first_process_device_data(p);
+   do {
+
+   args.process_apertures[args.num_of_nodes].gpu_id = 
pdd->dev->id;
+   args.process_apertures[args.num_of_nodes].lds_base = 
pdd->lds_base;
+   args.process_apertures[args.num_of_nodes].lds_limit = 
pdd->lds_limit;
+   args.process_apertures[args.num_of_nodes].gpuvm_base = 
pdd->gpuvm_base;
+   args.process_apertures[args.num_of_nodes].gpuvm_limit = 
pdd->gpuvm_limit;
+   args.process_apertures[args.num_of_nodes].scratch_base 
= pdd->scratch_base;
+   args.process_apertures[args.num_of_nodes].scratch_limit 
= pdd->scratch_limit;
+
+   dev_dbg(kfd_device, "node id %u\n", args.num_of_nodes);
+   dev_dbg(kfd_device, "gpu id %u\n", pdd->dev->id);
+   dev_dbg(kfd_device, "lds_base %llX\n", pdd->lds_base);
+   dev_dbg(kfd_device, "lds_limit %llX\n", pdd->lds_limit);
+   dev_dbg(kfd_device, "gpuvm_base %llX\n", 
pdd->gpuvm_base);
+   dev_dbg(kfd_device, "gpuvm_limit %llX\n", 
pdd->gpuvm_limit);
+   dev_dbg(kfd_device, "scratch_base %llX\n", 
pdd->scratch_base);
+   dev_dbg(kfd_device, "scratch_limit %llX\n", 
pdd->scratch_limit);
+
+   args.num_of_nodes++;
+   } while ((pdd = kfd_get_next_process_device_data(p, pdd)) != 
NULL &&
+   (args.num_of_nodes < NUM_OF_SUPPORTED_GPUS));
+   }
+
+   mutex_unlock(>mutex);
+
+   if (copy_to_user(arg, , sizeof(args)))
+   return -EFAULT;
+
+   return 0;
 }

 static long kfd_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
index 0e3e18f..9f49f11 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
@@ -445,6 +445,11 @@ struct kfd_process_device 
*kfd_get_process_device_data(struct kfd_dev *dev,
struct kfd_process *p,
int create_pdd);

+/* Process device data iterator */
+struct kfd_process_device *kfd_get_first_process_device_data(struct 
kfd_process *p);
+struct kfd_process_device *kfd_get_next_process_device_data(struct kfd_process 
*p, struct kfd_process_device *pdd);
+bool kfd_has_process_device_data(struct kfd_process *p);
+
 /* PASIDs */
 int kfd_pasid_init(void);
 void kfd_pasid_exit(void);
-- 
1.9.1

[PATCH v4 22/23] amdkfd: Implement the Get Clock Counters IOCTL

[Oded Gabbay]

From: Evgeny Pinchuk 

Signed-off-by: Evgeny Pinchuk 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
index d1cc6d8..1e4b731 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
@@ -373,7 +373,34 @@ out:

 static long kfd_ioctl_get_clock_counters(struct file *filep, struct 
kfd_process *p, void __user *arg)
 {
-   return -ENODEV;
+   struct kfd_ioctl_get_clock_counters_args args;
+   struct kfd_dev *dev;
+   struct timespec time;
+
+   if (copy_from_user(, arg, sizeof(args)))
+   return -EFAULT;
+
+   dev = kfd_device_by_id(args.gpu_id);
+   if (dev == NULL)
+   return -EINVAL;
+
+   /* Reading GPU clock counter from KGD */
+   args.gpu_clock_counter = kfd2kgd->get_gpu_clock_counter(dev->kgd);
+
+   /* No access to rdtsc. Using raw monotonic time */
+   getrawmonotonic();
+   args.cpu_clock_counter = (uint64_t)timespec_to_ns();
+
+   get_monotonic_boottime();
+   args.system_clock_counter = (uint64_t)timespec_to_ns();
+
+   /* Since the counter is in nano-seconds we use 1GHz frequency */
+   args.system_clock_freq = 10;
+
+   if (copy_to_user(arg, , sizeof(args)))
+   return -EFAULT;
+
+   return 0;
 }


-- 
1.9.1

[PATCH v4 21/23] amdkfd: Implement the Set Memory Policy IOCTL

[Oded Gabbay]

From: Andrew Lewycky 

Signed-off-by: Andrew Lewycky 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c | 51 -
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
index ac3146d..d1cc6d8 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include "kfd_priv.h"
+#include "kfd_device_queue_manager.h"

 static long kfd_ioctl(struct file *, unsigned int, unsigned long);
 static int kfd_open(struct inode *, struct file *);
@@ -319,7 +320,55 @@ static int kfd_ioctl_update_queue(struct file *filp, 
struct kfd_process *p, void

 static long kfd_ioctl_set_memory_policy(struct file *filep, struct kfd_process 
*p, void __user *arg)
 {
-   return -ENODEV;
+   struct kfd_ioctl_set_memory_policy_args args;
+   struct kfd_dev *dev;
+   int err = 0;
+   struct kfd_process_device *pdd;
+   enum cache_policy default_policy, alternate_policy;
+
+   if (copy_from_user(, arg, sizeof(args)))
+   return -EFAULT;
+
+   if (args.default_policy != KFD_IOC_CACHE_POLICY_COHERENT
+   && args.default_policy != KFD_IOC_CACHE_POLICY_NONCOHERENT) {
+   return -EINVAL;
+   }
+
+   if (args.alternate_policy != KFD_IOC_CACHE_POLICY_COHERENT
+   && args.alternate_policy != KFD_IOC_CACHE_POLICY_NONCOHERENT) {
+   return -EINVAL;
+   }
+
+   dev = kfd_device_by_id(args.gpu_id);
+   if (dev == NULL)
+   return -EINVAL;
+
+   mutex_lock(>mutex);
+
+   pdd = kfd_bind_process_to_device(dev, p);
+   if (IS_ERR(pdd) < 0) {
+   err = PTR_ERR(pdd);
+   goto out;
+   }
+
+   default_policy = (args.default_policy == KFD_IOC_CACHE_POLICY_COHERENT)
+? cache_policy_coherent : cache_policy_noncoherent;
+
+   alternate_policy = (args.alternate_policy == 
KFD_IOC_CACHE_POLICY_COHERENT)
+  ? cache_policy_coherent : cache_policy_noncoherent;
+
+   if (!dev->dqm->set_cache_memory_policy(dev->dqm,
+>qpd,
+default_policy,
+alternate_policy,
+(void __user 
*)args.alternate_aperture_base,
+args.alternate_aperture_size))
+   err = -EINVAL;
+
+out:
+   mutex_unlock(>mutex);
+
+   return err;
 }

 static long kfd_ioctl_get_clock_counters(struct file *filep, struct 
kfd_process *p, void __user *arg)
-- 
1.9.1

[PATCH v4 20/23] amdkfd: Implement the create/destroy/update queue IOCTLs

[Oded Gabbay]

From: Ben Goz 

v3: Removed the use of internal typedefs, fixed debug prints, added checks
for parameters and moved to using doorbell address from user

v4: Extracted some of the code in the create queue ioctl to a different
function that may be also called from other ioctls in the future. Also fixed
the check of the ring size argument.

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c| 191 -
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   |   8 +
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |   5 +-
 include/uapi/linux/kfd_ioctl.h |   7 +-
 4 files changed, 205 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
index c42f53b..ac3146d 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
@@ -117,19 +117,204 @@ static int kfd_open(struct inode *inode, struct file 
*filep)
return 0;
 }

+static int set_queue_properties_from_user(struct queue_properties 
*q_properties,
+   struct kfd_ioctl_create_queue_args *args)
+{
+   if (args->queue_percentage > KFD_MAX_QUEUE_PERCENTAGE) {
+   pr_err("kfd: queue percentage must be between 0 to 
KFD_MAX_QUEUE_PERCENTAGE\n");
+   return -EINVAL;
+   }
+
+   if (args->queue_priority > KFD_MAX_QUEUE_PRIORITY) {
+   pr_err("kfd: queue priority must be between 0 to 
KFD_MAX_QUEUE_PRIORITY\n");
+   return -EINVAL;
+   }
+
+   if ((args->ring_base_address) &&
+   (!access_ok(VERIFY_WRITE, args->ring_base_address, 
sizeof(uint64_t {
+   pr_err("kfd: can't access ring base address\n");
+   return -EFAULT;
+   }
+
+   if (!is_power_of_2(args->ring_size) && (args->ring_size != 0)) {
+   pr_err("kfd: ring size must be a power of 2 or 0\n");
+   return -EINVAL;
+   }
+
+   if (!access_ok(VERIFY_WRITE, args->read_pointer_address, 
sizeof(uint32_t))) {
+   pr_err("kfd: can't access read pointer\n");
+   return -EFAULT;
+   }
+
+   if (!access_ok(VERIFY_WRITE, args->write_pointer_address, 
sizeof(uint32_t))) {
+   pr_err("kfd: can't access write pointer\n");
+   return -EFAULT;
+   }
+
+   q_properties->is_interop = false;
+   q_properties->queue_percent = args->queue_percentage;
+   q_properties->priority = args->queue_priority;
+   q_properties->queue_address = args->ring_base_address;
+   q_properties->queue_size = args->ring_size;
+   q_properties->read_ptr = (uint32_t *) args->read_pointer_address;
+   q_properties->write_ptr = (uint32_t *) args->write_pointer_address;
+
+   pr_debug("Queue Percentage (%d, %d)\n",
+   q_properties->queue_percent, args->queue_percentage);
+
+   pr_debug("Queue Priority (%d, %d)\n",
+   q_properties->priority, args->queue_priority);
+
+   pr_debug("Queue Address (0x%llX, 0x%llX)\n",
+   q_properties->queue_address, args->ring_base_address);
+
+   pr_debug("Queue Size (0x%llX, %u)\n",
+   q_properties->queue_size, args->ring_size);
+
+   pr_debug("Queue r/w Pointers (0x%llX, 0x%llX)\n",
+   (uint64_t) q_properties->read_ptr,
+   (uint64_t) q_properties->write_ptr);
+
+   return 0;
+}
+
 static long kfd_ioctl_create_queue(struct file *filep, struct kfd_process *p, 
void __user *arg)
 {
-   return -ENODEV;
+   struct kfd_ioctl_create_queue_args args;
+   struct kfd_dev *dev;
+   int err = 0;
+   unsigned int queue_id;
+   struct kfd_process_device *pdd;
+   struct queue_properties q_properties;
+
+   memset(_properties, 0, sizeof(struct queue_properties));
+
+   if (copy_from_user(, arg, sizeof(args)))
+   return -EFAULT;
+
+   pr_debug("kfd: creating queue ioctl\n");
+
+   err = set_queue_properties_from_user(_properties, );
+   if (err)
+   return err;
+
+   dev = kfd_device_by_id(args.gpu_id);
+   if (dev == NULL)
+   return -EINVAL;
+
+   mutex_lock(>mutex);
+
+   pdd = kfd_bind_process_to_device(dev, p);
+   if (IS_ERR(pdd) < 0) {
+   err = PTR_ERR(pdd);
+   goto err_bind_process;
+   }
+
+   pr_debug("kfd: creating queue for PASID %d on GPU 0x%x\n",
+   p->pasid,
+   dev->id);
+
+   err = pqm_create_queue(>pqm, dev, filep, _properties, 0, 
KFD_QUEUE_TYPE_COMPUTE, _id);
+   if (err != 0)
+   goto err_create_queue;
+
+   args.queue_id = queue_id;
+
+   /* Return gpu_id as doorbell offset for mmap usage */
+   args.doorbell_offset = args.gpu_id << PAGE_SHIFT;
+
+   if 

[PATCH v4 19/23] amdkfd: Add interrupt handling module

[Oded Gabbay]

From: Andrew Lewycky 

This patch adds the interrupt handling module, in kfd_interrupt.c, and its
related members in different data structures to the amdkfd driver.

The amdkfd interrupt module maintains an internal interrupt ring per amdkfd
device. The internal interrupt ring contains interrupts that needs further
handling. The extra handling is deferred to a later time through a workqueue.

There's no acknowledgment for the interrupts we use. The hardware simply queues
a new interrupt each time without waiting.

The fixed-size internal queue means that it's possible for us to lose
interrupts because we have no back-pressure to the hardware.

v3:

Change device init
Made sure spin lock is taken only if init is complete
Moved bool field to the end of the structure

Signed-off-by: Andrew Lewycky 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile|   3 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c|  23 +++-
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c | 161 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h  |  18 ++-
 4 files changed, 200 insertions(+), 5 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index e3099c8..91d5015 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -8,6 +8,7 @@ amdkfd-y:= kfd_module.o kfd_device.o kfd_chardev.o 
kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
kfd_process.o kfd_queue.o kfd_mqd_manager.o \
kfd_kernel_queue.o kfd_packet_manager.o \
-   kfd_process_queue_manager.o kfd_device_queue_manager.o
+   kfd_process_queue_manager.o kfd_device_queue_manager.o \
+   kfd_interrupt.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_device.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
index 74575de..a364c1c 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
@@ -31,6 +31,7 @@

 static const struct kfd_device_info kaveri_device_info = {
.max_pasid_bits = 16,
+   .ih_ring_entry_size = 4 * sizeof(uint32_t)
 };

 struct kfd_deviceid {
@@ -187,6 +188,13 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
goto kfd_topology_add_device_error;
}

+   if (kfd_interrupt_init(kfd)) {
+   dev_err(kfd_device,
+   "Error initializing interrupts for device (%x:%x)\n",
+   kfd->pdev->vendor, kfd->pdev->device);
+   goto kfd_interrupt_error;
+   }
+
if (!device_iommu_pasid_init(kfd)) {
dev_err(kfd_device,
"Error initializing iommuv2 for device (%x:%x)\n",
@@ -223,6 +231,8 @@ dqm_start_error:
 device_queue_manager_error:
amd_iommu_free_device(kfd->pdev);
 device_iommu_pasid_error:
+   kfd_interrupt_exit(kfd);
+kfd_interrupt_error:
kfd_topology_remove_device(kfd);
 kfd_topology_add_device_error:
kfd2kgd->fini_sa_manager(kfd->kgd);
@@ -238,6 +248,7 @@ void kgd2kfd_device_exit(struct kfd_dev *kfd)
if (kfd->init_complete) {
device_queue_manager_uninit(kfd->dqm);
amd_iommu_free_device(kfd->pdev);
+   kfd_interrupt_exit(kfd);
kfd_topology_remove_device(kfd);
}

@@ -274,6 +285,16 @@ int kgd2kfd_resume(struct kfd_dev *kfd)
return 0;
 }

-void kgd2kfd_interrupt(struct kfd_dev *dev, const void *ih_ring_entry)
+/* This is called directly from KGD at ISR. */
+void kgd2kfd_interrupt(struct kfd_dev *kfd, const void *ih_ring_entry)
 {
+   if (kfd->init_complete) {
+   spin_lock(>interrupt_lock);
+
+   if (kfd->interrupts_active
+   && enqueue_ih_ring_entry(kfd, ih_ring_entry))
+   schedule_work(>interrupt_work);
+
+   spin_unlock(>interrupt_lock);
+   }
 }
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
new file mode 100644
index 000..eed43a7
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the 

[PATCH v4 18/23] amdkfd: Add device queue manager module

[Oded Gabbay]

From: Ben Goz 

The queue scheduler divides into two sections, one section is process bounded
and the other section is device bounded.
The device bounded section is handled by this module.
The DQM module handles queue setup, update and tear-down from the device side.
It also supports suspend/resume operation.

v3: Changed device_init, added the use of the new gart allocation functions an
Added documentation.

v4:

Fixed a race in DQM queue scheduler where dqm->lock must be held when accessing
dqm->queue_count and dqm->processes_count. This fixes runlist IB allocation
failures when DQM is under load.

Fixed race in DQM queue destruction where queues being destroyed must be
removed from qpd->queues_list prior to preemption, or concurrent queue
creation activity may reschedule them while their MQD is destroyed.

Fixed EOP queue size setting in CP_HPD_EOP_CONTROL, because the size is
specified as (log2(size_dwords)-1). The previous calculation assumed the
size was specified in bytes, which caused interference between EOP queues
when multiple MEC pipelines were active.

Signed-off-by: Ben Goz 
Signed-off-by: Jay Cornwall 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile |   2 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c |  28 +-
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   | 995 +
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  43 +
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   |  13 +
 5 files changed, 1079 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index b18a2b5..e3099c8 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -8,6 +8,6 @@ amdkfd-y:= kfd_module.o kfd_device.o kfd_chardev.o 
kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
kfd_process.o kfd_queue.o kfd_mqd_manager.o \
kfd_kernel_queue.o kfd_packet_manager.o \
-   kfd_process_queue_manager.o
+   kfd_process_queue_manager.o kfd_device_queue_manager.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_device.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
index ce90592..74575de 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include "kfd_priv.h"
+#include "kfd_device_queue_manager.h"

 #define MQD_SIZE_ALIGNED 768

@@ -194,12 +195,33 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
}
amd_iommu_set_invalidate_ctx_cb(kfd->pdev, 
iommu_pasid_shutdown_callback);

+   kfd->dqm = device_queue_manager_init(kfd);
+   if (!kfd->dqm) {
+   dev_err(kfd_device,
+   "Error initializing queue manager for device (%x:%x)\n",
+   kfd->pdev->vendor, kfd->pdev->device);
+   goto device_queue_manager_error;
+   }
+
+   if (kfd->dqm->start(kfd->dqm) != 0) {
+   dev_err(kfd_device,
+   "Error starting queuen manager for device (%x:%x)\n",
+   kfd->pdev->vendor, kfd->pdev->device);
+   goto dqm_start_error;
+   }
+
kfd->init_complete = true;
dev_info(kfd_device, "added device (%x:%x)\n", kfd->pdev->vendor,
 kfd->pdev->device);

+   pr_debug("kfd: Starting kfd with the following scheduling policy %d\n", 
sched_policy);
+
goto out;

+dqm_start_error:
+   device_queue_manager_uninit(kfd->dqm);
+device_queue_manager_error:
+   amd_iommu_free_device(kfd->pdev);
 device_iommu_pasid_error:
kfd_topology_remove_device(kfd);
 kfd_topology_add_device_error:
@@ -214,6 +236,7 @@ out:
 void kgd2kfd_device_exit(struct kfd_dev *kfd)
 {
if (kfd->init_complete) {
+   device_queue_manager_uninit(kfd->dqm);
amd_iommu_free_device(kfd->pdev);
kfd_topology_remove_device(kfd);
}
@@ -225,8 +248,10 @@ void kgd2kfd_suspend(struct kfd_dev *kfd)
 {
BUG_ON(kfd == NULL);

-   if (kfd->init_complete)
+   if (kfd->init_complete) {
+   kfd->dqm->stop(kfd->dqm);
amd_iommu_free_device(kfd->pdev);
+   }
 }

 int kgd2kfd_resume(struct kfd_dev *kfd)
@@ -243,6 +268,7 @@ int kgd2kfd_resume(struct kfd_dev *kfd)
if (err < 0)
return -ENXIO;
amd_iommu_set_invalidate_ctx_cb(kfd->pdev, 
iommu_pasid_shutdown_callback);
+   kfd->dqm->start(kfd->dqm);
}

return 0;
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.c
new file mode 100644
index 000..850fcddc
--- /dev/null
+++ 

[PATCH v4 17/23] amdkfd: Add process queue manager module

[Oded Gabbay]

From: Ben Goz 

The queue scheduler divides into two sections, one section is process bounded
and the other section is device bounded.
The process bounded section is handled by this module. The PQM handles usermode
queue setup, updates and tear-down.

v3:

Used kernel parameter to limit queues per process instead of define
Added use of doorbell address from user

v4:

Modified pqm_create_queue so that only when creating usermode queues the
driver should return the queue properties to the userspace.

Added an info message print when no more queues can be opened because of the
queue per process limitation

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile |   3 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   |  17 +
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c|  16 +
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  | 350 +
 4 files changed, 385 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process_queue_manager.c

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index b88e637..b18a2b5 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -7,6 +7,7 @@ ccflags-y := -Iinclude/drm
 amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
kfd_process.o kfd_queue.o kfd_mqd_manager.o \
-   kfd_kernel_queue.o kfd_packet_manager.o
+   kfd_kernel_queue.o kfd_packet_manager.o \
+   kfd_process_queue_manager.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
index 34028f8..600d671 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
@@ -365,6 +365,9 @@ struct kfd_process_device {
struct kfd_dev *dev;


+   /* per-process-per device QCM data structure */
+   struct qcm_process_device qpd;
+
/*Apertures*/
uint64_t lds_base;
uint64_t lds_limit;
@@ -410,6 +413,8 @@ struct kfd_process {
 */
struct list_head per_device_data;

+   struct process_queue_manager pqm;
+
/* The process's queues. */
size_t queue_array_size;

@@ -477,11 +482,23 @@ inline uint32_t upper_32(uint64_t x);

 int init_queue(struct queue **q, struct queue_properties properties);
 void uninit_queue(struct queue *q);
+void print_queue_properties(struct queue_properties *q);
 void print_queue(struct queue *q);

 struct kernel_queue *kernel_queue_init(struct kfd_dev *dev, enum 
kfd_queue_type type);
 void kernel_queue_uninit(struct kernel_queue *kq);

+/* Process Queue Manager */
+struct process_queue_node {
+   struct queue *q;
+   struct kernel_queue *kq;
+   struct list_head process_queue_list;
+};
+
+int pqm_init(struct process_queue_manager *pqm, struct kfd_process *p);
+void pqm_uninit(struct process_queue_manager *pqm);
+int pqm_destroy_queue(struct process_queue_manager *pqm, unsigned int qid);
+
 /* Packet Manager */

 #define KFD_HIQ_TIMEOUT (500)
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_process.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_process.c
index 66a91b9..78b614a 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_process.c
@@ -153,6 +153,9 @@ static void kfd_process_notifier_release(struct 
mmu_notifier *mn,

mutex_lock(>mutex);

+   /* In case our notifier is called before IOMMU notifier */
+   pqm_uninit(>pqm);
+
list_for_each_entry_safe(pdd, temp, >per_device_data, 
per_device_list) {
amd_iommu_unbind_pasid(pdd->dev->pdev, p->pasid);
list_del(>per_device_list);
@@ -217,8 +220,16 @@ static struct kfd_process *create_process(const struct 
task_struct *thread)

INIT_LIST_HEAD(>per_device_data);

+   err = pqm_init(>pqm, process);
+   if (err != 0)
+   goto err_process_pqm_init;
+
return process;

+err_process_pqm_init:
+   hash_del_rcu(>kfd_processes);
+   synchronize_rcu();
+   mmu_notifier_unregister_no_release(>mmu_notifier, process->mm);
 err_mmu_notifier:
kfd_pasid_free(process->pasid);
 err_alloc_pasid:
@@ -243,6 +254,9 @@ struct kfd_process_device 
*kfd_get_process_device_data(struct kfd_dev *dev,
pdd = kzalloc(sizeof(*pdd), GFP_KERNEL);
if (pdd != NULL) {
pdd->dev = dev;
+   INIT_LIST_HEAD(>qpd.queues_list);
+   INIT_LIST_HEAD(>qpd.priv_queue_list);
+   pdd->qpd.dqm = dev->dqm;
list_add(>per_device_list, >per_device_data);
}
}
@@ -302,6 +316,8 @@ void kfd_unbind_process_from_device(struct kfd_dev *dev, 
unsigned int pasid)

 

[PATCH v4 16/23] amdkfd: Add packet manager module

[Oded Gabbay]

From: Ben Goz 

The packet manager module builds PM4 packets for the sole use of the CP
scheduler. Those packets are used by the HIQ to submit runlists to the CP.

v3:

Removed include of cik_mqds.h
Changed lower_32/upper_32 calls to use linux macros
Used new gart allocation functions
Added documentation

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile |   2 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c | 495 +
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   |  72 +++
 3 files changed, 568 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index 020d6c7..b88e637 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -7,6 +7,6 @@ ccflags-y := -Iinclude/drm
 amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
kfd_process.o kfd_queue.o kfd_mqd_manager.o \
-   kfd_kernel_queue.o
+   kfd_kernel_queue.o kfd_packet_manager.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
new file mode 100644
index 000..aabc17e
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c
@@ -0,0 +1,495 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include "kfd_device_queue_manager.h"
+#include "kfd_kernel_queue.h"
+#include "kfd_priv.h"
+#include "kfd_pm4_headers.h"
+#include "kfd_pm4_opcodes.h"
+
+static inline void inc_wptr(unsigned int *wptr, unsigned int increment_bytes, 
unsigned int buffer_size_bytes)
+{
+   unsigned int temp = *wptr + increment_bytes / sizeof(uint32_t);
+
+   BUG_ON((temp * sizeof(uint32_t)) > buffer_size_bytes);
+   *wptr = temp;
+}
+
+static unsigned int build_pm4_header(unsigned int opcode, size_t packet_size)
+{
+   union PM4_TYPE_3_HEADER header;
+
+   header.u32all = 0;
+   header.opcode = opcode;
+   header.count = packet_size/sizeof(uint32_t) - 2;
+   header.type = PM4_TYPE_3;
+
+   return header.u32all;
+}
+
+static void pm_calc_rlib_size(struct packet_manager *pm, unsigned int 
*rlib_size, bool *over_subscription)
+{
+   unsigned int process_count, queue_count;
+
+   BUG_ON(!pm || !rlib_size || !over_subscription);
+
+   process_count = pm->dqm->processes_count;
+   queue_count = pm->dqm->queue_count;
+
+   /* check if there is over subscription*/
+   *over_subscription = false;
+   if ((process_count >= VMID_PER_DEVICE) ||
+   queue_count > PIPE_PER_ME_CP_SCHEDULING * 
QUEUES_PER_PIPE) {
+   *over_subscription = true;
+   pr_debug("kfd: over subscribed runlist\n");
+   }
+
+   /* calculate run list ib allocation size */
+   *rlib_size = process_count * sizeof(struct pm4_map_process) +
+queue_count * sizeof(struct pm4_map_queues);
+
+   /* increase the allocation size in case we need a chained run list when 
over subscription */
+   if (*over_subscription)
+   *rlib_size += sizeof(struct pm4_runlist);
+
+   pr_debug("kfd: runlist ib size %d\n", *rlib_size);
+}
+
+static int pm_allocate_runlist_ib(struct packet_manager *pm, unsigned int 
**rl_buffer, uint64_t *rl_gpu_buffer,
+   unsigned int *rl_buffer_size, bool *is_over_subscription)
+{
+   int retval;
+
+   BUG_ON(!pm);
+   BUG_ON(pm->allocated == true);
+   BUG_ON(is_over_subscription == NULL);
+
+   pm_calc_rlib_size(pm, rl_buffer_size, is_over_subscription);
+
+   retval = 

[PATCH v4 15/23] amdkfd: Add module parameter of scheduling policy

[Oded Gabbay]

From: Ben Goz 

This patch adds a new parameter to the amdkfd driver. This parameter enables
the user to select the scheduling policy of the CP. The choices are:

* CP Scheduling with support for over-subscription
* CP Scheduling without support for over-subscription
* Without CP Scheduling

Note that the third option (Without CP scheduling) is only for debug purposes
and bringup of new H/W. As such, it is _not_ guaranteed to work at all times on
all H/W versions.

v3: Fixed description of parameter, changed the permissions to read_only, added
a verification of the value and added documentation

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c | 12 
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   | 29 +
 2 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_module.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_module.c
index a31bf03..5c58031 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_module.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_module.c
@@ -45,6 +45,11 @@ static const struct kgd2kfd_calls kgd2kfd = {
.resume = kgd2kfd_resume,
 };

+int sched_policy = KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION;
+module_param(sched_policy, int, 0444);
+MODULE_PARM_DESC(sched_policy,
+   "Kernel cmdline parameter that defines the amdkfd scheduling policy");
+
 int max_num_of_processes = KFD_MAX_NUM_OF_PROCESSES_DEFAULT;
 module_param(max_num_of_processes, int, 0444);
 MODULE_PARM_DESC(max_num_of_processes,
@@ -79,6 +84,13 @@ static int __init kfd_module_init(void)
int err;

/* Verify module parameters */
+   if ((sched_policy < KFD_SCHED_POLICY_HWS) ||
+   (sched_policy > KFD_SCHED_POLICY_NO_HWS)) {
+   pr_err("kfd: sched_policy has invalid value\n");
+   return -1;
+   }
+
+   /* Verify module parameters */
if ((max_num_of_processes < 0) ||
(max_num_of_processes > KFD_MAX_NUM_OF_PROCESSES)) {
pr_err("kfd: max_num_of_processes must be between 0 to 
KFD_MAX_NUM_OF_PROCESSES\n");
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
index 66980df..5835d07 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
@@ -65,6 +65,35 @@ extern int max_num_of_queues_per_process;
 #define KFD_MAX_NUM_OF_QUEUES_PER_PROCESS_DEFAULT 128
 #define KFD_MAX_NUM_OF_QUEUES_PER_PROCESS 1024

+/* Kernel module parameter to specify the scheduling policy */
+extern int sched_policy;
+
+/**
+ * enum kfd_sched_policy
+ *
+ * @KFD_SCHED_POLICY_HWS: H/W scheduling policy known as command processor (cp)
+ * scheduling. In this scheduling mode we're using the firmware code to 
schedule
+ * the user mode queues and kernel queues such as HIQ and DIQ.
+ * the HIQ queue is used as a special queue that dispatches the configuration 
to
+ * the cp and the user mode queues list that are currently running.
+ * the DIQ queue is a debugging queue that dispatches debugging commands to the
+ * firmware.
+ * in this scheduling mode user mode queues over subscription feature is 
enabled.
+ *
+ * @KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION: The same as above but the over
+ * subscription feature disabled.
+ *
+ * @KFD_SCHED_POLICY_NO_HWS: no H/W scheduling policy is a mode which directly
+ * set the command processor registers and sets the queues "manually". This 
mode
+ * is used *ONLY* for debugging proposes.
+ *
+ */
+enum kfd_sched_policy {
+   KFD_SCHED_POLICY_HWS = 0,
+   KFD_SCHED_POLICY_HWS_NO_OVERSUBSCRIPTION,
+   KFD_SCHED_POLICY_NO_HWS
+};
+
 enum cache_policy {
cache_policy_coherent,
cache_policy_noncoherent
-- 
1.9.1

[PATCH v4 14/23] amdkfd: Add kernel queue module

[Oded Gabbay]

From: Ben Goz 

The kernel queue module enables the amdkfd to establish kernel queues, not
exposed to user space.

The kernel queues are used for HIQ (HSA Interface Queue) and DIQ (Debug
Interface Queue) operations

v3: Removed use of internal typedefs and added use of the new gart allocation
functions

v4: Fixed a miscalculation in kernel queue wrapping

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile |   3 +-
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   | 101 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   | 330 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |  66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h| 682 +
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h| 107 
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   |  33 +-
 7 files changed, 1320 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index 9f8de8d..020d6c7 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -6,6 +6,7 @@ ccflags-y := -Iinclude/drm

 amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
-   kfd_process.o kfd_queue.o kfd_mqd_manager.o
+   kfd_process.o kfd_queue.o kfd_mqd_manager.o \
+   kfd_kernel_queue.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h 
b/drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
new file mode 100644
index 000..e3a56ec
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_device_queue_manager.h
@@ -0,0 +1,101 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifndef KFD_DEVICE_QUEUE_MANAGER_H_
+#define KFD_DEVICE_QUEUE_MANAGER_H_
+
+#include 
+#include 
+#include "kfd_priv.h"
+#include "kfd_mqd_manager.h"
+
+#define QUEUE_PREEMPT_DEFAULT_TIMEOUT_MS   (500)
+#define QUEUES_PER_PIPE(8)
+#define PIPE_PER_ME_CP_SCHEDULING  (3)
+#define CIK_VMID_NUM   (8)
+#define KFD_VMID_START_OFFSET  (8)
+#define VMID_PER_DEVICECIK_VMID_NUM
+#define KFD_DQM_FIRST_PIPE (0)
+
+struct device_process_node {
+   struct qcm_process_device *qpd;
+   struct list_head list;
+};
+
+struct device_queue_manager {
+   int (*create_queue)(struct device_queue_manager *dqm,
+   struct queue *q,
+   struct qcm_process_device *qpd,
+   int *allocate_vmid);
+   int (*destroy_queue)(struct device_queue_manager *dqm,
+   struct qcm_process_device *qpd,
+   struct queue *q);
+   int (*update_queue)(struct device_queue_manager *dqm,
+   struct queue *q);
+   int (*destroy_queues)(struct device_queue_manager *dqm);
+   struct mqd_manager * (*get_mqd_manager)(struct device_queue_manager 
*dqm,
+   enum KFD_MQD_TYPE type);
+   int (*execute_queues)(struct device_queue_manager *dqm);
+   int (*register_process)(struct device_queue_manager *dqm,
+   struct qcm_process_device *qpd);
+   int 

[PATCH v4 13/23] amdkfd: Add mqd_manager module

[Oded Gabbay]

From: Ben Goz 

The mqd_manager module handles MQD data structures.
MQD stands for Memory Queue Descriptor, which is used by the H/W to
keep the usermode queue state in memory.

v3:

Removed new typedefs
Removed pragma pack 4
Remove cik_mqds.h file
Changed lower_32/upper_32 calls to use linux macros
Used new gart allocation functions
Added documentation

v4:

Added missing initialization of the addr field in init_mqd()

Setting the hqd persistent.preload_req bit ON so that when queues switches
on/off, their context will kept and read from the mqd when the cp reassign
them, and thus the dispatched workload context kept consistent without any
interrupts.

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile  |   2 +-
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h| 221 +
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c | 312 
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h |  88 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h|  11 +
 5 files changed, 633 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index 392728a..9f8de8d 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -6,6 +6,6 @@ ccflags-y := -Iinclude/drm

 amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
-   kfd_process.o kfd_queue.o
+   kfd_process.o kfd_queue.o kfd_mqd_manager.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/cik_regs.h 
b/drivers/gpu/drm/radeon/amdkfd/cik_regs.h
new file mode 100644
index 000..607fc5c
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/cik_regs.h
@@ -0,0 +1,221 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef CIK_REGS_H
+#define CIK_REGS_H
+
+#define IH_VMID_0_LUT  0x3D40u
+
+#define BIF_DOORBELL_CNTL  0x530Cu
+
+#defineSRBM_GFX_CNTL   0xE44
+#definePIPEID(x)   ((x) << 0)
+#defineMEID(x) ((x) << 2)
+#defineVMID(x) ((x) << 4)
+#defineQUEUEID(x)  ((x) << 8)
+
+#defineSQ_CONFIG   0x8C00
+
+#defineSH_MEM_BASES0x8C28
+/* if PTR32, these are the bases for scratch and lds */
+#definePRIVATE_BASE(x) ((x) << 0) /* 
scratch */
+#defineSHARED_BASE(x)  ((x) << 16) /* 
LDS */
+#defineSH_MEM_APE1_BASE0x8C2C
+/* if PTR32, this is the base location of GPUVM */
+#defineSH_MEM_APE1_LIMIT   0x8C30
+/* if PTR32, this is the upper limit of GPUVM */
+#defineSH_MEM_CONFIG   0x8C34
+#definePTR32   (1 << 0)
+#define PRIVATE_ATC(1 << 1)
+#defineALIGNMENT_MODE(x)   ((x) << 2)
+#defineSH_MEM_ALIGNMENT_MODE_DWORD 0
+#defineSH_MEM_ALIGNMENT_MODE_DWORD_STRICT  1
+#defineSH_MEM_ALIGNMENT_MODE_STRICT2
+#defineSH_MEM_ALIGNMENT_MODE_UNALIGNED 3
+#defineDEFAULT_MTYPE(x) 

[PATCH v4 12/23] amdkfd: Add queue module

[Oded Gabbay]

From: Ben Goz 

The queue module enables allocating and initializing queues uniformly.

v3: Removed typedef and redundant memset call. Broke long pr_debug print to one
liners and Added documentation.

Signed-off-by: Ben Goz 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile|   2 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h  | 123 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c |  85 +
 3 files changed, 208 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index 6d6746e..392728a 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -6,6 +6,6 @@ ccflags-y := -Iinclude/drm

 amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o \
kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
-   kfd_process.o
+   kfd_process.o kfd_queue.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
index b55b1cb..cf6d40d 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_priv.h
@@ -56,7 +56,6 @@ extern int max_num_of_queues_per_process;
 #define KFD_MAX_NUM_OF_QUEUES_PER_PROCESS_DEFAULT 128
 #define KFD_MAX_NUM_OF_QUEUES_PER_PROCESS 1024

-
 struct kfd_device_info {
const struct kfd_scheduler_class *scheduler_class;
unsigned int max_pasid_bits;
@@ -116,6 +115,128 @@ void kfd_chardev_exit(void);
 struct device *kfd_chardev(void);


+/**
+ * enum kfd_queue_type
+ *
+ * @KFD_QUEUE_TYPE_COMPUTE: Regular user mode queue type.
+ *
+ * @KFD_QUEUE_TYPE_SDMA: Sdma user mode queue type.
+ *
+ * @KFD_QUEUE_TYPE_HIQ: HIQ queue type.
+ *
+ * @KFD_QUEUE_TYPE_DIQ: DIQ queue type.
+ */
+enum kfd_queue_type  {
+   KFD_QUEUE_TYPE_COMPUTE,
+   KFD_QUEUE_TYPE_SDMA,
+   KFD_QUEUE_TYPE_HIQ,
+   KFD_QUEUE_TYPE_DIQ
+};
+
+/**
+ * struct queue_properties
+ *
+ * @type: The queue type.
+ *
+ * @queue_id: Queue identifier.
+ *
+ * @queue_address: Queue ring buffer address.
+ *
+ * @queue_size: Queue ring buffer size.
+ *
+ * @priority: Defines the queue priority relative to other queues in the 
process.
+ * This is just an indication and HW scheduling may override the priority as
+ * necessary while keeping the relative prioritization.
+ * the priority granularity is from 0 to f which f is the highest priority.
+ * currently all queues are initialized with the highest priority.
+ *
+ * @queue_percent: This field is partially implemented and currently a zero in
+ * this field defines that the queue is non active.
+ *
+ * @read_ptr: User space address which points to the number of dwords the
+ * cp read from the ring buffer. This field updates automatically by the H/W.
+ *
+ * @write_ptr: Defines the number of dwords written to the ring buffer.
+ *
+ * @doorbell_ptr: This field aim is to notify the H/W of new packet written to
+ * the queue ring buffer. This field should be similar to write_ptr and the 
user
+ * should update this field after he updated the write_ptr.
+ *
+ * @doorbell_off: The doorbell offset in the doorbell pci-bar.
+ *
+ * @is_interop: Defines if this is a interop queue. Interop queue means that 
the
+ * queue can access both graphics and compute resources.
+ *
+ * @is_active: Defines if the queue is active or not.
+ *
+ * @vmid: If the scheduling mode is no cp scheduling the field defines the vmid
+ * of the queue.
+ *
+ * This structure represents the queue properties for each queue no matter if
+ * it's user mode or kernel mode queue.
+ *
+ */
+struct queue_properties {
+   enum kfd_queue_type type;
+   unsigned int queue_id;
+   uint64_t queue_address;
+   uint64_t  queue_size;
+   uint32_t priority;
+   uint32_t queue_percent;
+   uint32_t *read_ptr;
+   uint32_t *write_ptr;
+   uint32_t *doorbell_ptr;
+   uint32_t doorbell_off;
+   bool is_interop;
+   bool is_active;
+   /* Not relevant for user mode queues in cp scheduling */
+   unsigned int vmid;
+};
+
+/**
+ * struct queue
+ *
+ * @list: Queue linked list.
+ *
+ * @mqd: The queue MQD.
+ *
+ * @mqd_mem_obj: The MQD local gpu memory object.
+ *
+ * @gart_mqd_addr: The MQD gart mc address.
+ *
+ * @properties: The queue properties.
+ *
+ * @mec: Used only in no cp scheduling mode and identifies to micro engine id
+ * that the queue should be execute on.
+ *
+ * @pipe: Used only in no cp scheduling mode and identifies the queue's pipe 
id.
+ *
+ * @queue: Used only in no cp scheduliong mode and identifies the queue's slot.
+ *
+ * @process: The kfd process that created this queue.
+ *
+ * @device: The kfd device that created this queue.
+ *
+ * This structure represents user mode compute queues.
+ * It contains all the necessary data to handle 

[PATCH v4 11/23] amdkfd: Add binding/unbinding calls to amd_iommu driver

[Oded Gabbay]

This patch adds the functions to bind and unbind pasid
from a device through the amd_iommu driver.

The unbind function is called when the mm_struct of the
process is released.

The bind function is not called here because it is called
only in the IOCTLs which are not yet implemented at this
stage of the patchset.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c  | 86 -
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h|  1 +
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c | 12 
 3 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_device.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
index 8e2b075..ce90592 100644
--- a/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_device.c
@@ -98,6 +98,63 @@ struct kfd_dev *kgd2kfd_probe(struct kgd_dev *kgd, struct 
pci_dev *pdev)
return kfd;
 }

+static bool device_iommu_pasid_init(struct kfd_dev *kfd)
+{
+   const u32 required_iommu_flags = AMD_IOMMU_DEVICE_FLAG_ATS_SUP | 
AMD_IOMMU_DEVICE_FLAG_PRI_SUP
+   | AMD_IOMMU_DEVICE_FLAG_PASID_SUP;
+
+   struct amd_iommu_device_info iommu_info;
+   unsigned int pasid_limit;
+   int err;
+
+   err = amd_iommu_device_info(kfd->pdev, _info);
+   if (err < 0) {
+   dev_err(kfd_device, "error getting iommu info. is the iommu 
enabled?\n");
+   return false;
+   }
+
+   if ((iommu_info.flags & required_iommu_flags) != required_iommu_flags) {
+   dev_err(kfd_device, "error required iommu flags ats(%i), 
pri(%i), pasid(%i)\n",
+  (iommu_info.flags & AMD_IOMMU_DEVICE_FLAG_ATS_SUP) != 0,
+  (iommu_info.flags & AMD_IOMMU_DEVICE_FLAG_PRI_SUP) != 0,
+  (iommu_info.flags & AMD_IOMMU_DEVICE_FLAG_PASID_SUP) != 
0);
+   return false;
+   }
+
+   pasid_limit = min_t(unsigned int,
+   (unsigned int)1 << kfd->device_info->max_pasid_bits,
+   iommu_info.max_pasids);
+   /*
+* last pasid is used for kernel queues doorbells
+* in the future the last pasid might be used for a kernel thread.
+*/
+   pasid_limit = min_t(unsigned int,
+   pasid_limit,
+   kfd->doorbell_process_limit - 1);
+
+   err = amd_iommu_init_device(kfd->pdev, pasid_limit);
+   if (err < 0) {
+   dev_err(kfd_device, "error initializing iommu device\n");
+   return false;
+   }
+
+   if (!kfd_set_pasid_limit(pasid_limit)) {
+   dev_err(kfd_device, "error setting pasid limit\n");
+   amd_iommu_free_device(kfd->pdev);
+   return false;
+   }
+
+   return true;
+}
+
+static void iommu_pasid_shutdown_callback(struct pci_dev *pdev, int pasid)
+{
+   struct kfd_dev *dev = kfd_device_by_pci_dev(pdev);
+
+   if (dev)
+   kfd_unbind_process_from_device(dev, pasid);
+}
+
 bool kgd2kfd_device_init(struct kfd_dev *kfd,
 const struct kgd2kfd_shared_resources *gpu_resources)
 {
@@ -129,6 +186,13 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,
goto kfd_topology_add_device_error;
}

+   if (!device_iommu_pasid_init(kfd)) {
+   dev_err(kfd_device,
+   "Error initializing iommuv2 for device (%x:%x)\n",
+   kfd->pdev->vendor, kfd->pdev->device);
+   goto device_iommu_pasid_error;
+   }
+   amd_iommu_set_invalidate_ctx_cb(kfd->pdev, 
iommu_pasid_shutdown_callback);

kfd->init_complete = true;
dev_info(kfd_device, "added device (%x:%x)\n", kfd->pdev->vendor,
@@ -136,6 +200,8 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd,

goto out;

+device_iommu_pasid_error:
+   kfd_topology_remove_device(kfd);
 kfd_topology_add_device_error:
kfd2kgd->fini_sa_manager(kfd->kgd);
dev_err(kfd_device,
@@ -147,7 +213,10 @@ out:

 void kgd2kfd_device_exit(struct kfd_dev *kfd)
 {
-   kfd_topology_remove_device(kfd);
+   if (kfd->init_complete) {
+   amd_iommu_free_device(kfd->pdev);
+   kfd_topology_remove_device(kfd);
+   }

kfree(kfd);
 }
@@ -155,12 +224,27 @@ void kgd2kfd_device_exit(struct kfd_dev *kfd)
 void kgd2kfd_suspend(struct kfd_dev *kfd)
 {
BUG_ON(kfd == NULL);
+
+   if (kfd->init_complete)
+   amd_iommu_free_device(kfd->pdev);
 }

 int kgd2kfd_resume(struct kfd_dev *kfd)
 {
+   unsigned int pasid_limit;
+   int err;
+
BUG_ON(kfd == NULL);

+   pasid_limit = kfd_get_pasid_limit();
+
+   if (kfd->init_complete) {
+   err = amd_iommu_init_device(kfd->pdev, pasid_limit);
+   if (err < 0)
+   return -ENXIO;
+   amd_iommu_set_invalidate_ctx_cb(kfd->pdev, 

[PATCH v4 10/23] amdkfd: Add basic modules to amdkfd

[Oded Gabbay]

From: Andrew Lewycky 

This patch adds the process module and three helper modules:

- kfd_process, which handles process which open /dev/kfd

- kfd_doorbell, which provides helper functions for doorbell allocation,
  release and mapping to userspace

- kfd_pasid, which provides helper functions for pasid allocation and release

- kfd_aperture, which provides helper functions for managing the LDS, Local GPU
  memory and Scratch memory apertures of the process

This patch only contains the basic kfd_process module, which doesn't contain
the reference to the queue scheduler. This was done to allow easier code review.

Also, this patch doesn't contain the calls to the IOMMU driver for binding the
pasid to the device. Again, this was done to allow easier code review

The kfd_process object is created when a process opens /dev/kfd and is closed
when the mm_struct of that process is teared-down.

v3:

Removed kfd_vidmem.c file
Replaced direct mmput call to mmu_notifier release
Removed typedefs
Moved bool field to end of the structure
Added new kernel params for gart usage limitation
Added initialization of sa manager
Fixed debug messages
Remove support for LDS in 32 bit
Changed code to support mmap of doorbell pages from userspace
Added documentation for apertures

v4:

Replaced RCU by SRCU for kfd_process list management

Signed-off-by: Andrew Lewycky 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile   |   4 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c | 350 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c  |  31 ++-
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c   |  45 +++-
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c | 236 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c   |  32 ++-
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c|  95 
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h | 141 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c  | 322 
 drivers/gpu/drm/radeon/radeon_kfd.c  |  21 +-
 10 files changed, 1250 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_process.c

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index 08ecfcd..6d6746e 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -4,6 +4,8 @@

 ccflags-y := -Iinclude/drm

-amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o
+amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o \
+   kfd_pasid.o kfd_doorbell.o kfd_aperture.o \
+   kfd_process.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
new file mode 100644
index 000..8cfb720
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
@@ -0,0 +1,350 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "kfd_priv.h"
+#include 
+#include 
+#include 
+
+/*
+ * The primary memory I/O features being added for revisions of gfxip
+ * beyond 7.0 (Kaveri) are:
+ *
+ * Access to ATC/IOMMU mapped memory w/ associated extension of VA to 48b
+ *
+ * ?Flat? shader memory access ? These are new shader vector memory operations
+ * that do not reference a T#/V# so a ?pointer? is what is sourced from the
+ * vector gprs for direct access to memory.  This pointer space has the
+ * Shared(LDS) and Private(Scratch) memory mapped into this pointer space as
+ * apertures.  The 

[PATCH v4 09/23] amdkfd: Add topology module to amdkfd

[Oded Gabbay]

From: Evgeny Pinchuk 

This patch adds the topology module to the driver. The topology is exposed to
userspace through the sysfs.

The calls to add and remove a device to/from topology are done by the radeon
driver.

v3:

The CPU information, that is provided in the topology section of the amdkfd
driver, is extracted from the CRAT table. Unlike the CPU information located
in /sys/devices/system/cpu/cpu*, which is extracted from the SRAT table.

While the CPU information provided by the CRAT and the SRAT tables might be
identical, the node topology might be different. The SRAT table contains the
topology of CPU nodes only. The CRAT table contains the topology of CPU and GPU
nodes together (and can be interleaved). For example CPU node 1 in SRAT can be
CPU node 3 in CRAT. Furthermore it's worth to mention that the CRAT table
contains only HSA compatible nodes (nodes which are compliant with the HSA
spec).

To recap, amdkfd exposes a different kind of topology than the one exposed by
/sys/devices/system/cpu/cpu even though it may contain similar information.

v4:

The topology module doesn't support uevent handling and doesn't notify the
userspace about runtime modifications. It is up to the userspace to acquire
snapshots of the topology information created by the amdkfd and exposed
in sysfs.

The following is an example of how the topology looks on a Kaveri A10-7850K
system with amdkfd installed:

/sys/devices/virtual/kfd/kfd/
|
--- topology/
  |
  |--- generation_id
  |--- system_properties
  |--- nodes/
|
|--- 0/
 |
 |--- gpu_id
 |--- name
 |--- properties
 |--- caches/
  |
  |--- 0/
   |
   |--- properties
  |--- 1/
   |
   |--- properties
  |--- 2/
   |
   |--- properties
 |--- io_links/
  |
 |--- mem_banks/
  |
  |--- 0/
   |
   |--- properties
  |--- 1/
   |
   |--- properties
  |--- 2/
   |
   |--- properties
  |--- 3/
   |
   |--- properties

Signed-off-by: Evgeny Pinchuk 
Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/amdkfd/Makefile   |2 +-
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h |  294 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c   |7 +
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c   |7 +
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h |   17 +
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c | 1207 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h |  168 
 7 files changed, 1701 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h

diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
index 9564e75..08ecfcd 100644
--- a/drivers/gpu/drm/radeon/amdkfd/Makefile
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -4,6 +4,6 @@

 ccflags-y := -Iinclude/drm

-amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o
+amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o kfd_topology.o

 obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_crat.h 
b/drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
new file mode 100644
index 000..a374fa3
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_crat.h
@@ -0,0 +1,294 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF 

[PATCH v4 08/23] amdkfd: Add amdkfd skeleton driver

[Oded Gabbay]

This patch adds the amdkfd skeleton driver. The driver does nothing except
define a /dev/kfd device.

It returns -ENODEV on all amdkfd IOCTLs.

v3: Move bool field to the end of structure, removed the pmc ioctls and added
a meaningful error message for ioctl error.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/Kconfig  |   2 +
 drivers/gpu/drm/radeon/Makefile |   2 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig   |  10 ++
 drivers/gpu/drm/radeon/amdkfd/Makefile  |   9 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c | 187 
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c  | 129 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c  |  98 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h|  82 
 8 files changed, 519 insertions(+)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_device.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_module.c
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h

diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig
index 970f8e9..b697321 100644
--- a/drivers/gpu/drm/radeon/Kconfig
+++ b/drivers/gpu/drm/radeon/Kconfig
@@ -6,3 +6,5 @@ config DRM_RADEON_UMS

  Userspace modesetting is deprecated for quite some time now, so
  enable this only if you have ancient versions of the DDX drivers.
+
+source "drivers/gpu/drm/radeon/amdkfd/Kconfig"
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index bad6caa..9cbb8ea 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -112,4 +112,6 @@ radeon-$(CONFIG_ACPI) += radeon_acpi.o

 obj-$(CONFIG_DRM_RADEON)+= radeon.o

+obj-$(CONFIG_HSA_RADEON)+= amdkfd/
+
 CFLAGS_radeon_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/radeon/amdkfd/Kconfig 
b/drivers/gpu/drm/radeon/amdkfd/Kconfig
new file mode 100644
index 000..900bb34
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/Kconfig
@@ -0,0 +1,10 @@
+#
+# Heterogenous system architecture configuration
+#
+
+config HSA_RADEON
+   tristate "HSA kernel driver for AMD Radeon devices"
+   depends on DRM_RADEON && AMD_IOMMU_V2 && X86_64
+   default m
+   help
+ Enable this if you want to use HSA features on AMD radeon devices.
diff --git a/drivers/gpu/drm/radeon/amdkfd/Makefile 
b/drivers/gpu/drm/radeon/amdkfd/Makefile
new file mode 100644
index 000..9564e75
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for Heterogenous System Architecture support for AMD radeon devices
+#
+
+ccflags-y := -Iinclude/drm
+
+amdkfd-y   := kfd_module.o kfd_device.o kfd_chardev.o
+
+obj-$(CONFIG_HSA_RADEON)   += amdkfd.o
diff --git a/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
new file mode 100644
index 000..f198e5a
--- /dev/null
+++ b/drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c
@@ -0,0 +1,187 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "kfd_priv.h"
+
+static long kfd_ioctl(struct file *, unsigned int, unsigned long);
+static int kfd_open(struct inode *, struct file *);
+
+static const char kfd_dev_name[] = "kfd";
+
+static const struct file_operations kfd_fops = {
+   .owner = THIS_MODULE,
+   .unlocked_ioctl = kfd_ioctl,
+   .compat_ioctl = kfd_ioctl,
+   .open = kfd_open,
+};
+
+static int kfd_char_dev_major = -1;
+static struct class *kfd_class;
+struct device *kfd_device;
+
+int kfd_chardev_init(void)
+{
+   int err = 

[PATCH v4 07/23] amdkfd: Add IOCTL set definitions of amdkfd

[Oded Gabbay]

- KFD_IOC_GET_VERSION:
Retrieves the interface version of amdkfd

- KFD_IOC_CREATE_QUEUE:
Creates a usermode queue that runs on a specific GPU device

- KFD_IOC_DESTROY_QUEUE:
Destroys an existing usermode queue

- KFD_IOC_SET_MEMORY_POLICY:
Sets the memory policy of the default and alternate aperture of the
calling process

- KFD_IOC_GET_CLOCK_COUNTERS:
Retrieves counters (timestamps) of CPU and GPU

- KFD_IOC_GET_PROCESS_APERTURES:
Retrieves information about process apertures that were initialized
during the open() call of the amdkfd device

- KFD_IOC_UPDATE_QUEUE:
Updates configuration of an existing usermode queue

v3: Remove pragma pack and pmc ioctls. Added parameter for doorbell offset and
a comment on counters

Signed-off-by: Oded Gabbay 
---
 include/uapi/linux/kfd_ioctl.h | 123 +
 1 file changed, 123 insertions(+)
 create mode 100644 include/uapi/linux/kfd_ioctl.h

diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
new file mode 100644
index 000..a06e021
--- /dev/null
+++ b/include/uapi/linux/kfd_ioctl.h
@@ -0,0 +1,123 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef KFD_IOCTL_H_INCLUDED
+#define KFD_IOCTL_H_INCLUDED
+
+#include 
+#include 
+
+#define KFD_IOCTL_CURRENT_VERSION 1
+
+struct kfd_ioctl_get_version_args {
+   uint32_t min_supported_version; /* from KFD */
+   uint32_t max_supported_version; /* from KFD */
+};
+
+/* For kfd_ioctl_create_queue_args.queue_type. */
+#define KFD_IOC_QUEUE_TYPE_COMPUTE   0
+#define KFD_IOC_QUEUE_TYPE_SDMA  1
+
+struct kfd_ioctl_create_queue_args {
+   uint64_t ring_base_address; /* to KFD */
+   uint64_t write_pointer_address; /* from KFD */
+   uint64_t read_pointer_address;  /* from KFD */
+   uint64_t doorbell_offset;   /* from KFD */
+
+   uint32_t ring_size; /* to KFD */
+   uint32_t gpu_id;/* to KFD */
+   uint32_t queue_type;/* to KFD */
+   uint32_t queue_percentage;  /* to KFD */
+   uint32_t queue_priority;/* to KFD */
+   uint32_t queue_id;  /* from KFD */
+};
+
+struct kfd_ioctl_destroy_queue_args {
+   uint32_t queue_id;  /* to KFD */
+};
+
+struct kfd_ioctl_update_queue_args {
+   uint64_t ring_base_address; /* to KFD */
+
+   uint32_t queue_id;  /* to KFD */
+   uint32_t ring_size; /* to KFD */
+   uint32_t queue_percentage;  /* to KFD */
+   uint32_t queue_priority;/* to KFD */
+};
+
+/* For kfd_ioctl_set_memory_policy_args.default_policy and alternate_policy */
+#define KFD_IOC_CACHE_POLICY_COHERENT 0
+#define KFD_IOC_CACHE_POLICY_NONCOHERENT 1
+
+struct kfd_ioctl_set_memory_policy_args {
+   uint64_t alternate_aperture_base;   /* to KFD */
+   uint64_t alternate_aperture_size;   /* to KFD */
+
+   uint32_t gpu_id;/* to KFD */
+   uint32_t default_policy;/* to KFD */
+   uint32_t alternate_policy;  /* to KFD */
+};
+
+/*
+ * All counters are monotonic. They are used for profiling of compute jobs.
+ * The profiling is done by userspace.
+ *
+ * In case of GPU reset, the counter should not be affected.
+ */
+
+struct kfd_ioctl_get_clock_counters_args {
+   uint64_t gpu_clock_counter; /* from KFD */
+   uint64_t cpu_clock_counter; /* from KFD */
+   uint64_t system_clock_counter;  /* from KFD */
+   uint64_t system_clock_freq; /* from KFD */
+
+   uint32_t gpu_id;/* to KFD */
+};
+
+#define NUM_OF_SUPPORTED_GPUS 7
+
+struct kfd_process_device_apertures {
+   uint64_t lds_base;  /* from KFD */
+   uint64_t lds_limit; /* from KFD */
+   uint64_t 

[PATCH v4 06/23] Update MAINTAINERS and CREDITS files with amdkfd info

[Oded Gabbay]

Signed-off-by: Oded Gabbay 
---
 CREDITS |  7 +++
 MAINTAINERS | 10 ++
 2 files changed, 17 insertions(+)

diff --git a/CREDITS b/CREDITS
index bb62788..c56d8aa 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1197,6 +1197,13 @@ S: R. Tocantins, 89 - Cristo Rei
 S: 80050-430 - Curitiba - Paran?
 S: Brazil

+N: Oded Gabbay
+E: oded.gabbay at gmail.com
+D: AMD KFD maintainer
+S: 12 Shraga Raphaeli
+S: Petah-Tikva, 4906418
+S: Israel
+
 N: Kumar Gala
 E: galak at kernel.crashing.org
 D: Embedded PowerPC 6xx/7xx/74xx/82xx/83xx/85xx support
diff --git a/MAINTAINERS b/MAINTAINERS
index dd31933..437ff7d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -609,6 +609,16 @@ F: drivers/crypto/geode*
 F: drivers/video/fbdev/geode/
 F: arch/x86/include/asm/geode.h

+AMD KFD (radeon extension)
+M: Oded Gabbay 
+L: dri-devel at lists.freedesktop.org
+T: git git://people.freedesktop.org/~gabbayo/linux.git
+S: Supported
+F: drivers/gpu/drm/radeon/amdkfd/*
+F: drivers/gpu/drm/radeon/radeon_kfd.c
+F: drivers/gpu/drm/radeon/radeon_kfd.h
+F: include/linux/uapi/linux/kfd_ioctl.h
+
 AMD IOMMU (AMD-VI)
 M: Joerg Roedel 
 L: iommu at lists.linux-foundation.org
-- 
1.9.1

[PATCH v4 05/23] drm/radeon: Add radeon <--> amdkfd interface

[Oded Gabbay]

This patch adds the interface between the radeon driver and the amdkfd driver.
The interface implementation is contained in radeon_kfd.c and radeon_kfd.h.

The interface itself is represented by a pointer to struct
kfd_dev. The pointer is located inside radeon_device structure.

All the register accesses that amdkfd need are done using this interface. This
allows us to avoid direct register accesses in amdkfd proper,  while also
avoiding locking between amdkfd and radeon.

The single exception is the doorbells that are used in both of the drivers.
However, because they are located in separate pci bar pages, the danger of
sharing registers between the drivers is minimal.

Having said that, we are planning to move the doorbells as well to radeon.

v3:

Add interface for sa manager init and fini. The init function will allocate a
buffer on system memory and pin it to the GART address space via the radeon sa
manager.

All mappings of buffers to GART address space are done via the radeon sa
manager. The interface of allocate memory will use the radeon sa manager to sub
allocate from the single buffer that was allocated during the init function.

Change lower_32/upper_32 calls to use linux macros

Add documentation for the interface

v4:

Change ptr field type in kgd_mem from uint32_t* to void* to match to type that
is returned by radeon_sa_bo_cpu_addr

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/Makefile |   1 +
 drivers/gpu/drm/radeon/cik.c|   9 +
 drivers/gpu/drm/radeon/cik_reg.h|  65 +
 drivers/gpu/drm/radeon/cikd.h   |  51 +++-
 drivers/gpu/drm/radeon/radeon.h |   4 +
 drivers/gpu/drm/radeon/radeon_drv.c |   5 +
 drivers/gpu/drm/radeon/radeon_kfd.c | 538 
 drivers/gpu/drm/radeon/radeon_kfd.h | 177 
 drivers/gpu/drm/radeon/radeon_kms.c |   7 +
 9 files changed, 856 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.c
 create mode 100644 drivers/gpu/drm/radeon/radeon_kfd.h

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index d01b879..bad6caa 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -104,6 +104,7 @@ radeon-y += \
radeon_vce.o \
vce_v1_0.o \
vce_v2_0.o \
+   radeon_kfd.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 69b9027..27c983c 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -32,6 +32,7 @@
 #include "cik_blit_shaders.h"
 #include "radeon_ucode.h"
 #include "clearstate_ci.h"
+#include "radeon_kfd.h"

 MODULE_FIRMWARE("radeon/BONAIRE_pfp.bin");
 MODULE_FIRMWARE("radeon/BONAIRE_me.bin");
@@ -7792,6 +7793,9 @@ restart_ih:
while (rptr != wptr) {
/* wptr/rptr are in bytes! */
ring_index = rptr / 4;
+
+   radeon_kfd_interrupt(rdev, (const void *) 
>ih.ring[ring_index]);
+
src_id =  le32_to_cpu(rdev->ih.ring[ring_index]) & 0xff;
src_data = le32_to_cpu(rdev->ih.ring[ring_index + 1]) & 
0xfff;
ring_id = le32_to_cpu(rdev->ih.ring[ring_index + 2]) & 0xff;
@@ -8481,6 +8485,10 @@ static int cik_startup(struct radeon_device *rdev)
if (r)
return r;

+   r = radeon_kfd_resume(rdev);
+   if (r)
+   return r;
+
return 0;
 }

@@ -8529,6 +8537,7 @@ int cik_resume(struct radeon_device *rdev)
  */
 int cik_suspend(struct radeon_device *rdev)
 {
+   radeon_kfd_suspend(rdev);
radeon_pm_suspend(rdev);
dce6_audio_fini(rdev);
radeon_vm_manager_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/cik_reg.h b/drivers/gpu/drm/radeon/cik_reg.h
index ca1bb61..1ab3dbc 100644
--- a/drivers/gpu/drm/radeon/cik_reg.h
+++ b/drivers/gpu/drm/radeon/cik_reg.h
@@ -147,4 +147,69 @@

 #define CIK_LB_DESKTOP_HEIGHT 0x6b0c

+struct cik_hqd_registers {
+   u32 cp_mqd_base_addr;
+   u32 cp_mqd_base_addr_hi;
+   u32 cp_hqd_active;
+   u32 cp_hqd_vmid;
+   u32 cp_hqd_persistent_state;
+   u32 cp_hqd_pipe_priority;
+   u32 cp_hqd_queue_priority;
+   u32 cp_hqd_quantum;
+   u32 cp_hqd_pq_base;
+   u32 cp_hqd_pq_base_hi;
+   u32 cp_hqd_pq_rptr;
+   u32 cp_hqd_pq_rptr_report_addr;
+   u32 cp_hqd_pq_rptr_report_addr_hi;
+   u32 cp_hqd_pq_wptr_poll_addr;
+   u32 cp_hqd_pq_wptr_poll_addr_hi;
+   u32 cp_hqd_pq_doorbell_control;
+   u32 cp_hqd_pq_wptr;
+   u32 cp_hqd_pq_control;
+   u32 cp_hqd_ib_base_addr;
+   u32 cp_hqd_ib_base_addr_hi;
+   u32 cp_hqd_ib_rptr;
+   u32 cp_hqd_ib_control;
+   u32 cp_hqd_iq_timer;
+   u32 cp_hqd_iq_rptr;
+   u32 cp_hqd_dequeue_request;
+   u32 cp_hqd_dma_offload;
+   u32 cp_hqd_sema_cmd;
+   u32 cp_hqd_msg_type;
+   u32 

[PATCH v4 04/23] drm/radeon: adding synchronization for GRBM GFX

[Oded Gabbay]

Implementing a lock for selecting and accessing shader engines and arrays.
This lock will make sure that radeon and amdkfd are not colliding when
accessing shader engines and arrays with GRBM_GFX_INDEX register.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/cik.c   | 26 ++
 drivers/gpu/drm/radeon/radeon.h|  2 ++
 drivers/gpu/drm/radeon/radeon_device.c |  1 +
 3 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index e789988..69b9027 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -1563,6 +1563,8 @@ static const u32 godavari_golden_registers[] =

 static void cik_init_golden_registers(struct radeon_device *rdev)
 {
+   /* Some of the registers might be dependant on GRBM_GFX_INDEX */
+   mutex_lock(>grbm_idx_mutex);
switch (rdev->family) {
case CHIP_BONAIRE:
radeon_program_register_sequence(rdev,
@@ -1637,6 +1639,7 @@ static void cik_init_golden_registers(struct 
radeon_device *rdev)
default:
break;
}
+   mutex_unlock(>grbm_idx_mutex);
 }

 /**
@@ -3419,6 +3422,7 @@ static void cik_setup_rb(struct radeon_device *rdev,
u32 disabled_rbs = 0;
u32 enabled_rbs = 0;

+   mutex_lock(>grbm_idx_mutex);
for (i = 0; i < se_num; i++) {
for (j = 0; j < sh_per_se; j++) {
cik_select_se_sh(rdev, i, j);
@@ -3430,6 +3434,7 @@ static void cik_setup_rb(struct radeon_device *rdev,
}
}
cik_select_se_sh(rdev, 0x, 0x);
+   mutex_unlock(>grbm_idx_mutex);

mask = 1;
for (i = 0; i < max_rb_num_per_se * se_num; i++) {
@@ -3440,6 +3445,7 @@ static void cik_setup_rb(struct radeon_device *rdev,

rdev->config.cik.backend_enable_mask = enabled_rbs;

+   mutex_lock(>grbm_idx_mutex);
for (i = 0; i < se_num; i++) {
cik_select_se_sh(rdev, i, 0x);
data = 0;
@@ -3467,6 +3473,7 @@ static void cik_setup_rb(struct radeon_device *rdev,
WREG32(PA_SC_RASTER_CONFIG, data);
}
cik_select_se_sh(rdev, 0x, 0x);
+   mutex_unlock(>grbm_idx_mutex);
 }

 /**
@@ -3684,6 +3691,12 @@ static void cik_gpu_init(struct radeon_device *rdev)
/* set HW defaults for 3D engine */
WREG32(CP_MEQ_THRESHOLDS, MEQ1_START(0x30) | MEQ2_START(0x60));

+   mutex_lock(>grbm_idx_mutex);
+   /*
+* making sure that the following register writes will be broadcasted
+* to all the shaders
+*/
+   cik_select_se_sh(rdev, 0x, 0x);
WREG32(SX_DEBUG_1, 0x20);

WREG32(TA_CNTL_AUX, 0x0001);
@@ -3739,6 +3752,7 @@ static void cik_gpu_init(struct radeon_device *rdev)

WREG32(PA_CL_ENHANCE, CLIP_VTX_REORDER_ENA | NUM_CLIP_SEQ(3));
WREG32(PA_SC_ENHANCE, ENABLE_PA_SC_OUT_OF_ORDER);
+   mutex_unlock(>grbm_idx_mutex);

udelay(50);
 }
@@ -6062,6 +6076,7 @@ static void cik_wait_for_rlc_serdes(struct radeon_device 
*rdev)
u32 i, j, k;
u32 mask;

+   mutex_lock(>grbm_idx_mutex);
for (i = 0; i < rdev->config.cik.max_shader_engines; i++) {
for (j = 0; j < rdev->config.cik.max_sh_per_se; j++) {
cik_select_se_sh(rdev, i, j);
@@ -6073,6 +6088,7 @@ static void cik_wait_for_rlc_serdes(struct radeon_device 
*rdev)
}
}
cik_select_se_sh(rdev, 0x, 0x);
+   mutex_unlock(>grbm_idx_mutex);

mask = SE_MASTER_BUSY_MASK | GC_MASTER_BUSY | TC0_MASTER_BUSY | 
TC1_MASTER_BUSY;
for (k = 0; k < rdev->usec_timeout; k++) {
@@ -6207,10 +6223,12 @@ static int cik_rlc_resume(struct radeon_device *rdev)
WREG32(RLC_LB_CNTR_INIT, 0);
WREG32(RLC_LB_CNTR_MAX, 0x8000);

+   mutex_lock(>grbm_idx_mutex);
cik_select_se_sh(rdev, 0x, 0x);
WREG32(RLC_LB_INIT_CU_MASK, 0x);
WREG32(RLC_LB_PARAMS, 0x00600408);
WREG32(RLC_LB_CNTL, 0x8004);
+   mutex_unlock(>grbm_idx_mutex);

WREG32(RLC_MC_CNTL, 0);
WREG32(RLC_UCODE_CNTL, 0);
@@ -6277,11 +6295,13 @@ static void cik_enable_cgcg(struct radeon_device *rdev, 
bool enable)

tmp = cik_halt_rlc(rdev);

+   mutex_lock(>grbm_idx_mutex);
cik_select_se_sh(rdev, 0x, 0x);
WREG32(RLC_SERDES_WR_CU_MASTER_MASK, 0x);
WREG32(RLC_SERDES_WR_NONCU_MASTER_MASK, 0x);
tmp2 = BPM_ADDR_MASK | CGCG_OVERRIDE_0 | CGLS_ENABLE;
WREG32(RLC_SERDES_WR_CTRL, tmp2);
+   mutex_unlock(>grbm_idx_mutex);

cik_update_rlc(rdev, tmp);

@@ -6323,11 +6343,13 @@ static void cik_enable_mgcg(struct radeon_device *rdev, 
bool enable)

tmp = cik_halt_rlc(rdev);

+ 

[PATCH v4 03/23] drm/radeon: Report doorbell configuration to amdkfd

[Oded Gabbay]

radeon and amdkfd share the doorbell aperture.
radeon sets it up, takes the doorbells required for its own rings
and reports the setup to amdkfd.
radeon reserved doorbells are at the start of the doorbell aperture.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/radeon.h|  4 
 drivers/gpu/drm/radeon/radeon_device.c | 31 +++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index bb75e57..67d249a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -697,6 +697,10 @@ struct radeon_doorbell {

 int radeon_doorbell_get(struct radeon_device *rdev, u32 *page);
 void radeon_doorbell_free(struct radeon_device *rdev, u32 doorbell);
+void radeon_doorbell_get_kfd_info(struct radeon_device *rdev,
+ phys_addr_t *aperture_base,
+ size_t *aperture_size,
+ size_t *start_offset);

 /*
  * IRQS.
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index e84a76e..da3035f 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -373,6 +373,37 @@ void radeon_doorbell_free(struct radeon_device *rdev, u32 
doorbell)
__clear_bit(doorbell, rdev->doorbell.used);
 }

+/**
+ * radeon_doorbell_get_kfd_info - Report doorbell configuration required to
+ *setup KFD
+ *
+ * @rdev: radeon_device pointer
+ * @aperture_base: output returning doorbell aperture base physical address
+ * @aperture_size: output returning doorbell aperture size in bytes
+ * @start_offset: output returning # of doorbell bytes reserved for radeon.
+ *
+ * Radeon and the KFD share the doorbell aperture. Radeon sets it up,
+ * takes doorbells required for its own rings and reports the setup to KFD.
+ * Radeon reserved doorbells are at the start of the doorbell aperture.
+ */
+void radeon_doorbell_get_kfd_info(struct radeon_device *rdev,
+ phys_addr_t *aperture_base,
+ size_t *aperture_size,
+ size_t *start_offset)
+{
+   /* The first num_doorbells are used by radeon.
+* KFD takes whatever's left in the aperture. */
+   if (rdev->doorbell.size > rdev->doorbell.num_doorbells * sizeof(u32)) {
+   *aperture_base = rdev->doorbell.base;
+   *aperture_size = rdev->doorbell.size;
+   *start_offset = rdev->doorbell.num_doorbells * sizeof(u32);
+   } else {
+   *aperture_base = 0;
+   *aperture_size = 0;
+   *start_offset = 0;
+   }
+}
+
 /*
  * radeon_wb_*()
  * Writeback is the the method by which the the GPU updates special pages
-- 
1.9.1

[PATCH v4 02/23] drm/radeon/cik: Don't touch int of pipes 1-7

[Oded Gabbay]

amdkfd should set interrupts for pipes 1-7.

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/cik.c | 71 +---
 1 file changed, 1 insertion(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 1530e37..e789988 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7291,8 +7291,7 @@ static int cik_irq_init(struct radeon_device *rdev)
 int cik_irq_set(struct radeon_device *rdev)
 {
u32 cp_int_cntl;
-   u32 cp_m1p0, cp_m1p1, cp_m1p2, cp_m1p3;
-   u32 cp_m2p0, cp_m2p1, cp_m2p2, cp_m2p3;
+   u32 cp_m1p0;
u32 crtc1 = 0, crtc2 = 0, crtc3 = 0, crtc4 = 0, crtc5 = 0, crtc6 = 0;
u32 hpd1, hpd2, hpd3, hpd4, hpd5, hpd6;
u32 grbm_int_cntl = 0;
@@ -7326,13 +7325,6 @@ int cik_irq_set(struct radeon_device *rdev)
dma_cntl1 = RREG32(SDMA0_CNTL + SDMA1_REGISTER_OFFSET) & ~TRAP_ENABLE;

cp_m1p0 = RREG32(CP_ME1_PIPE0_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m1p1 = RREG32(CP_ME1_PIPE1_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m1p2 = RREG32(CP_ME1_PIPE2_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m1p3 = RREG32(CP_ME1_PIPE3_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m2p0 = RREG32(CP_ME2_PIPE0_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m2p1 = RREG32(CP_ME2_PIPE1_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m2p2 = RREG32(CP_ME2_PIPE2_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
-   cp_m2p3 = RREG32(CP_ME2_PIPE3_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;

if (rdev->flags & RADEON_IS_IGP)
thermal_int = RREG32_SMC(CG_THERMAL_INT_CTRL) &
@@ -7354,33 +7346,6 @@ int cik_irq_set(struct radeon_device *rdev)
case 0:
cp_m1p0 |= TIME_STAMP_INT_ENABLE;
break;
-   case 1:
-   cp_m1p1 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 2:
-   cp_m1p2 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 3:
-   cp_m1p2 |= TIME_STAMP_INT_ENABLE;
-   break;
-   default:
-   DRM_DEBUG("si_irq_set: sw int cp1 invalid pipe 
%d\n", ring->pipe);
-   break;
-   }
-   } else if (ring->me == 2) {
-   switch (ring->pipe) {
-   case 0:
-   cp_m2p0 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 1:
-   cp_m2p1 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 2:
-   cp_m2p2 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 3:
-   cp_m2p2 |= TIME_STAMP_INT_ENABLE;
-   break;
default:
DRM_DEBUG("si_irq_set: sw int cp1 invalid pipe 
%d\n", ring->pipe);
break;
@@ -7397,33 +7362,6 @@ int cik_irq_set(struct radeon_device *rdev)
case 0:
cp_m1p0 |= TIME_STAMP_INT_ENABLE;
break;
-   case 1:
-   cp_m1p1 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 2:
-   cp_m1p2 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 3:
-   cp_m1p2 |= TIME_STAMP_INT_ENABLE;
-   break;
-   default:
-   DRM_DEBUG("si_irq_set: sw int cp2 invalid pipe 
%d\n", ring->pipe);
-   break;
-   }
-   } else if (ring->me == 2) {
-   switch (ring->pipe) {
-   case 0:
-   cp_m2p0 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 1:
-   cp_m2p1 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 2:
-   cp_m2p2 |= TIME_STAMP_INT_ENABLE;
-   break;
-   case 3:
-   cp_m2p2 |= TIME_STAMP_INT_ENABLE;
-   break;
default:
DRM_DEBUG("si_irq_set: sw int cp2 invalid pipe 
%d\n", ring->pipe);
break;
@@ -7512,13 +7450,6 @@ int cik_irq_set(struct radeon_device *rdev)
WREG32(SDMA0_CNTL + 

[PATCH v4 01/23] drm/radeon: reduce number of free VMIDs and pipes in KV

[Oded Gabbay]

To support HSA on KV, we need to limit the number of vmids and pipes
that are available for radeon's use with KV.

This patch reserves VMIDs 8-15 for amdkfd (so radeon can only use VMIDs
0-7) and also makes radeon thinks that KV has only a single MEC with a single
pipe in it

v3: Use define for static vmid allocation in radeon

Signed-off-by: Oded Gabbay 
---
 drivers/gpu/drm/radeon/cik.c  | 48 +--
 drivers/gpu/drm/radeon/cikd.h |  2 ++
 2 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0d761f7..1530e37 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4678,12 +4678,11 @@ static int cik_mec_init(struct radeon_device *rdev)
/*
 * KV:2 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 64 Queues total
 * CI/KB: 1 MEC, 4 Pipes/MEC, 8 Queues/Pipe - 32 Queues total
+* Nonetheless, we assign only 1 pipe because all other pipes will
+* be handled by KFD
 */
-   if (rdev->family == CHIP_KAVERI)
-   rdev->mec.num_mec = 2;
-   else
-   rdev->mec.num_mec = 1;
-   rdev->mec.num_pipe = 4;
+   rdev->mec.num_mec = 1;
+   rdev->mec.num_pipe = 1;
rdev->mec.num_queue = rdev->mec.num_mec * rdev->mec.num_pipe * 8;

if (rdev->mec.hpd_eop_obj == NULL) {
@@ -4825,28 +4824,24 @@ static int cik_cp_compute_resume(struct radeon_device 
*rdev)

/* init the pipes */
mutex_lock(>srbm_mutex);
-   for (i = 0; i < (rdev->mec.num_pipe * rdev->mec.num_mec); i++) {
-   int me = (i < 4) ? 1 : 2;
-   int pipe = (i < 4) ? i : (i - 4);

-   eop_gpu_addr = rdev->mec.hpd_eop_gpu_addr + (i * MEC_HPD_SIZE * 
2);
+   eop_gpu_addr = rdev->mec.hpd_eop_gpu_addr;

-   cik_srbm_select(rdev, me, pipe, 0, 0);
+   cik_srbm_select(rdev, 0, 0, 0, 0);

-   /* write the EOP addr */
-   WREG32(CP_HPD_EOP_BASE_ADDR, eop_gpu_addr >> 8);
-   WREG32(CP_HPD_EOP_BASE_ADDR_HI, upper_32_bits(eop_gpu_addr) >> 
8);
+   /* write the EOP addr */
+   WREG32(CP_HPD_EOP_BASE_ADDR, eop_gpu_addr >> 8);
+   WREG32(CP_HPD_EOP_BASE_ADDR_HI, upper_32_bits(eop_gpu_addr) >> 8);

-   /* set the VMID assigned */
-   WREG32(CP_HPD_EOP_VMID, 0);
+   /* set the VMID assigned */
+   WREG32(CP_HPD_EOP_VMID, 0);
+
+   /* set the EOP size, register value is 2^(EOP_SIZE+1) dwords */
+   tmp = RREG32(CP_HPD_EOP_CONTROL);
+   tmp &= ~EOP_SIZE_MASK;
+   tmp |= order_base_2(MEC_HPD_SIZE / 8);
+   WREG32(CP_HPD_EOP_CONTROL, tmp);

-   /* set the EOP size, register value is 2^(EOP_SIZE+1) dwords */
-   tmp = RREG32(CP_HPD_EOP_CONTROL);
-   tmp &= ~EOP_SIZE_MASK;
-   tmp |= order_base_2(MEC_HPD_SIZE / 8);
-   WREG32(CP_HPD_EOP_CONTROL, tmp);
-   }
-   cik_srbm_select(rdev, 0, 0, 0, 0);
mutex_unlock(>srbm_mutex);

/* init the queues.  Just two for now. */
@@ -5900,8 +5895,13 @@ int cik_ib_parse(struct radeon_device *rdev, struct 
radeon_ib *ib)
  */
 int cik_vm_init(struct radeon_device *rdev)
 {
-   /* number of VMs */
-   rdev->vm_manager.nvm = 16;
+   /*
+* number of VMs
+* VMID 0 is reserved for System
+* radeon graphics/compute will use VMIDs 1-7
+* amdkfd will use VMIDs 8-15
+*/
+   rdev->vm_manager.nvm = RADEON_NUM_OF_VMIDS;
/* base offset of vram pages */
if (rdev->flags & RADEON_IS_IGP) {
u64 tmp = RREG32(MC_VM_FB_OFFSET);
diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
index 0c6e1b5..fae4d0c 100644
--- a/drivers/gpu/drm/radeon/cikd.h
+++ b/drivers/gpu/drm/radeon/cikd.h
@@ -30,6 +30,8 @@
 #define CIK_RB_BITMAP_WIDTH_PER_SH 2
 #define HAWAII_RB_BITMAP_WIDTH_PER_SH  4

+#define RADEON_NUM_OF_VMIDS8
+
 /* DIDT IND registers */
 #define DIDT_SQ_CTRL0 0x0
 #   define DIDT_CTRL_EN   (1 << 0)
-- 
1.9.1

[PATCH v4 00/23] AMDKFD Kernel Driver

[Oded Gabbay]

Hi,
Here is the v4 patch set of amdkfd.

This version mainly contains fixes to the code published in v3 and changes to 
commit messages to reflect the fixes. In addition, I have added the latest 
version of a patch-set prepared by Joerg Roedel that allows the mm sub-system 
to handle TLBs which are external to the CPU (i.e handled by the IOMMU). 

The patch-set is rebased over latest drm-next (3.17-rc5) and 
radeon's drm-next-3.18. Therefore, I removed some mm and IOMMU patches that 
were part of my tree in v3 as they are already merged into kernel 3.17

For people who like to review using git, the v4 patch set is located at:
http://cgit.freedesktop.org/~gabbayo/linux/?h=amdkfd-v4

Link to v3 cover letter: 
http://lwn.net/Articles/607730/

Link to v2 cover letter: 
http://lists.freedesktop.org/archives/dri-devel/2014-July/064011.html

Link to v1 cover letter: 
http://lwn.net/Articles/605153/

Any comment / review is appreciated.

- Oded

Alexey Skidanov (1):
  amdkfd: Implement the Get Process Aperture IOCTL

Andrew Lewycky (3):
  amdkfd: Add basic modules to amdkfd
  amdkfd: Add interrupt handling module
  amdkfd: Implement the Set Memory Policy IOCTL

Ben Goz (8):
  amdkfd: Add queue module
  amdkfd: Add mqd_manager module
  amdkfd: Add kernel queue module
  amdkfd: Add module parameter of scheduling policy
  amdkfd: Add packet manager module
  amdkfd: Add process queue manager module
  amdkfd: Add device queue manager module
  amdkfd: Implement the create/destroy/update queue IOCTLs

Evgeny Pinchuk (2):
  amdkfd: Add topology module to amdkfd
  amdkfd: Implement the Get Clock Counters IOCTL

Oded Gabbay (9):
  drm/radeon: reduce number of free VMIDs and pipes in KV
  drm/radeon/cik: Don't touch int of pipes 1-7
  drm/radeon: Report doorbell configuration to amdkfd
  drm/radeon: adding synchronization for GRBM GFX
  drm/radeon: Add radeon <--> amdkfd interface
  Update MAINTAINERS and CREDITS files with amdkfd info
  amdkfd: Add IOCTL set definitions of amdkfd
  amdkfd: Add amdkfd skeleton driver
  amdkfd: Add binding/unbinding calls to amd_iommu driver

 CREDITS|7 +
 MAINTAINERS|   10 +
 drivers/gpu/drm/radeon/Kconfig |2 +
 drivers/gpu/drm/radeon/Makefile|3 +
 drivers/gpu/drm/radeon/amdkfd/Kconfig  |   10 +
 drivers/gpu/drm/radeon/amdkfd/Makefile |   14 +
 drivers/gpu/drm/radeon/amdkfd/cik_regs.h   |  221 
 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c   |  350 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_chardev.c|  520 +
 drivers/gpu/drm/radeon/amdkfd/kfd_crat.h   |  294 +
 drivers/gpu/drm/radeon/amdkfd/kfd_device.c |  300 +
 .../drm/radeon/amdkfd/kfd_device_queue_manager.c   |  995 
 .../drm/radeon/amdkfd/kfd_device_queue_manager.h   |  144 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_doorbell.c   |  236 
 drivers/gpu/drm/radeon/amdkfd/kfd_interrupt.c  |  161 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.c   |  330 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_kernel_queue.h   |   66 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_module.c |  147 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.c|  312 +
 drivers/gpu/drm/radeon/amdkfd/kfd_mqd_manager.h|   88 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_packet_manager.c |  495 
 drivers/gpu/drm/radeon/amdkfd/kfd_pasid.c  |   95 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_headers.h|  682 +++
 drivers/gpu/drm/radeon/amdkfd/kfd_pm4_opcodes.h|  107 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_priv.h   |  560 +
 drivers/gpu/drm/radeon/amdkfd/kfd_process.c|  350 ++
 .../drm/radeon/amdkfd/kfd_process_queue_manager.c  |  353 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_queue.c  |   85 ++
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.c   | 1207 
 drivers/gpu/drm/radeon/amdkfd/kfd_topology.h   |  168 +++
 drivers/gpu/drm/radeon/cik.c   |  154 +--
 drivers/gpu/drm/radeon/cik_reg.h   |   65 ++
 drivers/gpu/drm/radeon/cikd.h  |   53 +-
 drivers/gpu/drm/radeon/radeon.h|   10 +
 drivers/gpu/drm/radeon/radeon_device.c |   32 +
 drivers/gpu/drm/radeon/radeon_drv.c|5 +
 drivers/gpu/drm/radeon/radeon_kfd.c|  525 +
 drivers/gpu/drm/radeon/radeon_kfd.h|  177 +++
 drivers/gpu/drm/radeon/radeon_kms.c|7 +
 include/uapi/linux/kfd_ioctl.h |  126 ++
 40 files changed, 9371 insertions(+), 95 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Kconfig
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/Makefile
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/cik_regs.h
 create mode 100644 drivers/gpu/drm/radeon/amdkfd/kfd_aperture.c
 create mode 100644 

[PATCH 12/12] ARM: shmobile: koelsch: Add DU HDMI output support

[Laurent Pinchart]

Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
and configure the DISP pin group that drives the HDMI transmitter DE
pin.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 50 ++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts 
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 9051e01..b7d0c41 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -209,6 +209,17 @@
states = <330 1
  180 0>;
};
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };

  {
@@ -217,6 +228,11 @@
status = "okay";

ports {
+   port at 0 {
+   endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
port at 1 {
lvds_connector: endpoint {
};
@@ -235,7 +251,7 @@
};

du_pins: du {
-   renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
+   renesas,groups = "du_rgb666", "du_sync", "du_disp", 
"du_clk_out_0";
renesas,function = "du";
};

@@ -439,6 +455,38 @@
};
};

+   hdmi at 39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+
eeprom at 50 {
compatible = "renesas,24c02";
reg = <0x50>;
-- 
1.8.5.5

[PATCH 11/12] drm: Add adv7511 encoder driver

[Laurent Pinchart]

From: Lars-Peter Clausen 

This patch adds a driver for the Analog Devices adv7511. The adv7511 is
a standalone HDMI transmitter chip. It features a HDMI output interface
on one end and video and audio input interfaces on the other.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Laurent Pinchart 

---

This commit incorporates the following commits.

DRM: adv7511: Sync to latest version
DRM: adv7511: Fix calculation and setting of CTS
DRM: adv7511: Write status word frequency and word len registers
adv7511: Remove some debug printks
Merge branch 'xcomm_zynq' into xcomm_zynq_3_5
Sync adv7511 and axi-hdmi driver to latest version
drm:adv7511: Re-add module information
DRM: adv7511: Don't use raw_edid to pass edid data
drm: adv7511: Ignore the csc scaling factor when the csc is disabled
drm: adv7511: Check if edid is NULL before duplicating it
drm: adv7511: Include the extension sections when duplicating the edid
DRM: adv7511: Work around off-by-one hardware bug
DRM: adv7511: Make embedded sync generator setup more robust
DRM: adv7511_audio: Fix typo
DRM: adv7511: Add powerdown gpio support
drm: adv7511: Fix use after free
DRM: adv7511: Properly initialize dpms_mode and status
DRM: adv7511: Avoid uneccessary disconnected events
drm: adv7511: Fix adv7511 encoder driver
drm: adv7511: Fix kernel-doc format
drm: adv7511: Fix adv7511_parse_dt()
drm: adv7511: Add the rgb format flag to adv7511_link_config
drm: adv7511: Configure CSC in adv7511_set_config()
drm: adv7511: Add adv7511_set_config_csc()
drm: adv7511: Configure the csc when getting modes
drm: adv7511: Add adv7511_encoder_mode_valid() function
drm: adv7511: Don't export adv7511_get_edid function
drm: adv7511: Mark the revision register as volatile
drm: adv7511: Initialize work queue before requesting IRQ
drm: adv7511: Remove trailing whitespaces
drm: adv7511: Remove audio support
drm: adv7511: Remove DRM slave encoder .set_config operation
drm: adv7511: Make the adv7511_packet_(enable|disable) functions static
drm: adv7511: Move Kconfig entry to drivers/gpu/drm/i2c/Kconfig
drm: adv7511: Update to the latest DRM API
drm: adv7511: Rename driver source file to adv7511.c
drm: adv7511: Add OF match table
drm: adv7511: Add ADV7513 support
drm: adv7511: Remove platform data support
drm: adv7511: Convert to the gpiod API
drm: adv7511: Remove packet and CEC I2C device support
drm: adv7511: Use the devm_ managed IRQ API
drm: adv7511: Remove unneeded local variable initialization
drm: adv7511: Pass the adv7511 pointer to adv7511_get_edid_block
drm: adv7511: Make loop counter unsigned
drm: adv7511: Pass adv7511 pointer to adv7511_set_config_csc function
drm: adv7511: Reorganize the code in sections
drm: adv7511: Simplify DT bindings
---
 drivers/gpu/drm/i2c/Kconfig   |6 +
 drivers/gpu/drm/i2c/Makefile  |2 +
 drivers/gpu/drm/i2c/adv7511.c | 1007 +
 drivers/gpu/drm/i2c/adv7511.h |  289 
 4 files changed, 1304 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/adv7511.c
 create mode 100644 drivers/gpu/drm/i2c/adv7511.h

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 4d341db..22c7ed6 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -1,6 +1,12 @@
 menu "I2C encoder or helper chips"
  depends on DRM && DRM_KMS_HELPER && I2C

+config DRM_I2C_ADV7511
+   tristate "AV7511 encoder"
+   select REGMAP_I2C
+   help
+ Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+
 config DRM_I2C_CH7006
tristate "Chrontel ch7006 TV encoder"
default m if DRM_NOUVEAU
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..2c72eb5 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,5 +1,7 @@
 ccflags-y := -Iinclude/drm

+obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
+
 ch7006-y := ch7006_drv.o ch7006_mode.o
 obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o

diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
new file mode 100644
index 000..0a61a17
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -0,0 +1,1007 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "adv7511.h"
+
+struct adv7511 {
+   struct i2c_client *i2c_main;
+   struct i2c_client *i2c_edid;
+
+   struct regmap *regmap;
+   struct regmap *packet_memory_regmap;
+   enum drm_connector_status status;
+   int dpms_mode;
+
+   unsigned int f_tmds;
+
+   unsigned int current_edid_segment;
+   uint8_t edid_buf[256];
+
+   wait_queue_head_t wq;
+   struct drm_encoder *encoder;
+
+   bool embedded_sync;
+   enum adv7511_sync_polarity vsync_polarity;
+ 

[PATCH 10/12] video: Add ADV751[13] DT bindings documentation

[Laurent Pinchart]

The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the
OF graph bindings and a list of custom properties pertaining to the
input video bus configuration.

Cc: devicetree at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 .../devicetree/bindings/video/adi,adv7511.txt  | 87 ++
 1 file changed, 87 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/adi,adv7511.txt

diff --git a/Documentation/devicetree/bindings/video/adi,adv7511.txt 
b/Documentation/devicetree/bindings/video/adi,adv7511.txt
new file mode 100644
index 000..aa41d9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/adi,adv7511.txt
@@ -0,0 +1,87 @@
+Analog Device ADV7511(W)/13 HDMI Encoders
+-
+
+The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
+compatible with HDMI 1.4 and DVI 1.0. They support color space conversion,
+S/PDIF, CEC and HDCP.
+
+Required properties:
+
+- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or "adi,adv7513"
+- reg: I2C slave address
+
+The ADV7511 supports a large number of input data formats that differ by their
+color depth, color format, clock mode, bit justification and random
+arrangement of components on the data bus. The combination of the following
+properties describe the input and map directly to the video input tables of the
+ADV7511 datasheet that document all the supported combinations.
+
+- adi,input-depth: Number of bits per color component at the input (8, 10 or
+  12).
+- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
+  "yuv444".
+- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
+  pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
+  data driven on both edges).
+
+The following input format properties are required except in "rgb 1x" and
+"yuv444 1x" modes, in which case they must not be specified.
+
+- adi,input-style: The input components arrangement variant (1, 2 or 3).
+- adi,input-justification: The input bit justification ("left", "evenly",
+  "right").
+
+Optional properties:
+
+- interrupts: Specifier for the ADV7511 interrupt
+- pd-gpios: Specifier for the GPIO connected to the power down signal
+
+- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
+  (-1200 ps .. 1600 ps). Defaults to no delay.
+- adi,embedded-sync: The input uses synchronization signals embedded in the
+  data stream (similar to BT.656). Defaults to separate H/V synchronization
+  signals.
+
+Required nodes:
+
+The ADV7511 has two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for the RGB or YUV input
+- Video port 1 for the HDMI output
+
+
+Example
+---
+
+   adv7511w: hdmi at 39 {
+   compatible = "adi,adv7511w";
+   reg = <39>;
+   interrupt-parent = <>;
+   interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   adv7511w_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+   };
-- 
1.8.5.5

[PATCH 09/12] drm: Decouple EDID parsing from I2C adapter

[Laurent Pinchart]

From: Lars-Peter Clausen 

The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.

Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_edid.c | 26 +-
 include/drm/drm_edid.h |  4 
 2 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1bdbfd0..c98958c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1125,9 +1125,9 @@ EXPORT_SYMBOL(drm_edid_is_valid);
  * Return: 0 on success or -1 on failure.
  */
 static int
-drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
- int block, int len)
+drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int block, size_t len)
 {
+   struct i2c_adapter *adapter = data;
unsigned char start = block * EDID_LENGTH;
unsigned char segment = block >> 1;
unsigned char xfers = segment ? 3 : 2;
@@ -1184,8 +1184,9 @@ static bool drm_edid_is_zero(u8 *in_edid, int length)
return true;
 }

-static u8 *
-drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
+struct edid *drm_do_get_edid(struct drm_connector *connector,
+   int (*get_edid_block)(void *, u8 *buf, unsigned int, size_t),
+   void *data)
 {
int i, j = 0, valid_extensions = 0;
u8 *block, *new;
@@ -1196,7 +1197,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)

/* base block fetch */
for (i = 0; i < 4; i++) {
-   if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH))
+   if (get_edid_block(data, block, 0, EDID_LENGTH))
goto out;
if (drm_edid_block_valid(block, 0, print_bad_edid))
break;
@@ -1210,7 +1211,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)

/* if there's no extensions, we're done */
if (block[0x7e] == 0)
-   return block;
+   return (struct edid *)block;

new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
@@ -1219,7 +1220,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)

for (j = 1; j <= block[0x7e]; j++) {
for (i = 0; i < 4; i++) {
-   if (drm_do_probe_ddc_edid(adapter,
+   if (get_edid_block(data,
  block + (valid_extensions + 1) * EDID_LENGTH,
  j, EDID_LENGTH))
goto out;
@@ -1247,7 +1248,7 @@ drm_do_get_edid(struct drm_connector *connector, struct 
i2c_adapter *adapter)
block = new;
}

-   return block;
+   return (struct edid *)block;

 carp:
if (print_bad_edid) {
@@ -1260,6 +1261,7 @@ out:
kfree(block);
return NULL;
 }
+EXPORT_SYMBOL_GPL(drm_do_get_edid);

 /**
  * drm_probe_ddc() - probe DDC presence
@@ -1289,12 +1291,10 @@ EXPORT_SYMBOL(drm_probe_ddc);
 struct edid *drm_get_edid(struct drm_connector *connector,
  struct i2c_adapter *adapter)
 {
-   struct edid *edid = NULL;
-
-   if (drm_probe_ddc(adapter))
-   edid = (struct edid *)drm_do_get_edid(connector, adapter);
+   if (!drm_probe_ddc(adapter))
+   return NULL;

-   return edid;
+   return drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
 }
 EXPORT_SYMBOL(drm_get_edid);

diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b96031d..bcf05ef 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -279,4 +279,8 @@ int
 drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);

+struct edid *drm_do_get_edid(struct drm_connector *connector,
+   int (*get_edid_block)(void *, u8 *buf, unsigned int, size_t),
+   void *data);
+
 #endif /* __DRM_EDID_H__ */
-- 
1.8.5.5

[PATCH 08/12] drm: rcar-du: Add HDMI encoder and connector support

[Laurent Pinchart]

SoCs that integrate the DU have no internal HDMI encoder, support
external encoders only.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/Kconfig   |  11 ++-
 drivers/gpu/drm/rcar-du/Makefile  |   2 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  30 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h |   3 +
 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 118 +++
 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h |  31 ++
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 151 ++
 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h |  35 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |   1 +
 9 files changed, 375 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index c96f608..2324a52 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,10 +11,17 @@ config DRM_RCAR_DU
  Choose this option if you have an R-Car chipset.
  If M is selected the module will be called rcar-du-drm.

+config DRM_RCAR_HDMI
+   bool "R-Car DU HDMI Encoder Support"
+   depends on DRM_RCAR_DU
+   depends on OF
+   help
+ Enable support for external HDMI encoders.
+
 config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
depends on ARCH_R8A7790 || ARCH_R8A7791 || COMPILE_TEST
help
- Enable support the R-Car Display Unit embedded LVDS encoders
- (currently only on R8A7790).
+ Enable support for the R-Car Display Unit embedded LVDS encoders
+ (currently only on R8A7790 and R8A7791).
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 12b8d44..05de1c4 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -7,6 +7,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
 rcar_du_plane.o \
 rcar_du_vgacon.o

+rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI)+= rcar_du_hdmicon.o \
+  rcar_du_hdmienc.o
 rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o

 obj-$(CONFIG_DRM_RCAR_DU)  += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index e88e63b..34a122a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -19,6 +19,8 @@

 #include "rcar_du_drv.h"
 #include "rcar_du_encoder.h"
+#include "rcar_du_hdmicon.h"
+#include "rcar_du_hdmienc.h"
 #include "rcar_du_kms.h"
 #include "rcar_du_lvdscon.h"
 #include "rcar_du_lvdsenc.h"
@@ -177,6 +179,9 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
case RCAR_DU_ENCODER_LVDS:
encoder_type = DRM_MODE_ENCODER_LVDS;
break;
+   case RCAR_DU_ENCODER_HDMI:
+   encoder_type = DRM_MODE_ENCODER_TMDS;
+   break;
case RCAR_DU_ENCODER_NONE:
default:
/* No external encoder, use the internal encoder type. */
@@ -184,12 +189,24 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}

-   ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
-  encoder_type);
-   if (ret < 0)
-   return ret;
+   if (type == RCAR_DU_ENCODER_HDMI) {
+   if (renc->lvds) {
+   dev_err(rcdu->dev,
+   "Chaining LVDS and HDMI encoders not 
supported\n");
+   return -EINVAL;
+   }

-   drm_encoder_helper_add(encoder, _helper_funcs);
+   ret = rcar_du_hdmienc_init(rcdu, renc, enc_node);
+   if (ret < 0)
+   return ret;
+   } else {
+   ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
+  encoder_type);
+   if (ret < 0)
+   return ret;
+
+   drm_encoder_helper_add(encoder, _helper_funcs);
+   }

switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
@@ -198,6 +215,9 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
case DRM_MODE_ENCODER_DAC:
return rcar_du_vga_connector_init(rcdu, renc);

+   case DRM_MODE_ENCODER_TMDS:
+   return rcar_du_hdmi_connector_init(rcdu, renc);
+
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c4dccdb..719b6f2a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ 

[PATCH 07/12] drm: rcar-du: Replace drm_encoder with drm_slave_encoder

[Laurent Pinchart]

DRM slave encoders require their associated struct drm_encoder instance
to be embedded in a struct drm_slave_encoder. This makes processing
encoders regardless of their types needlessly and painfully complex in
drivers that use a mix of slave encoders and custom encoders. Such a
driver will need to either create drm_slave_encoder instances that fake
their embedded encoder instance, or to turn all drm_encoder instances
into drm_slave_encoder instances.

Between the two evils, one must choose the lesser. Use drm_slave_encoder
everywhere.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c6334b4..c4dccdb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -15,6 +15,7 @@
 #define __RCAR_DU_ENCODER_H__

 #include 
+#include 

 struct rcar_du_device;
 struct rcar_du_lvdsenc;
@@ -27,15 +28,15 @@ enum rcar_du_encoder_type {
 };

 struct rcar_du_encoder {
-   struct drm_encoder encoder;
+   struct drm_encoder_slave slave;
enum rcar_du_output output;
struct rcar_du_lvdsenc *lvds;
 };

 #define to_rcar_encoder(e) \
-   container_of(e, struct rcar_du_encoder, encoder)
+   container_of(e, struct rcar_du_encoder, slave.base)

-#define rcar_encoder_to_drm_encoder(e) (&(e)->encoder)
+#define rcar_encoder_to_drm_encoder(e) (&(e)->slave.base)

 struct rcar_du_connector {
struct drm_connector connector;
-- 
1.8.5.5

[PATCH 06/12] drm: rcar-du: Replace direct DRM encoder access with cast macro

[Laurent Pinchart]

Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder
pointer and use it. This prepares for the replacement of the
rcar_drm_encoder encoder field with a drm_slave_encoder.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 8 +---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 ++
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 5 +++--
 drivers/gpu/drm/rcar-du/rcar_du_vgacon.c  | 5 +++--
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index c699100..e88e63b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -33,7 +33,7 @@ rcar_du_connector_best_encoder(struct drm_connector 
*connector)
 {
struct rcar_du_connector *rcon = to_rcar_connector(connector);

-   return >encoder->encoder;
+   return rcar_encoder_to_drm_encoder(rcon->encoder);
 }

 /* 
-
@@ -146,6 +146,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 struct device_node *con_node)
 {
struct rcar_du_encoder *renc;
+   struct drm_encoder *encoder;
unsigned int encoder_type;
int ret;

@@ -154,6 +155,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
return -ENOMEM;

renc->output = output;
+   encoder = rcar_encoder_to_drm_encoder(renc);

switch (output) {
case RCAR_DU_OUTPUT_LVDS0:
@@ -182,12 +184,12 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}

-   ret = drm_encoder_init(rcdu->ddev, >encoder, _funcs,
+   ret = drm_encoder_init(rcdu->ddev, encoder, _funcs,
   encoder_type);
if (ret < 0)
return ret;

-   drm_encoder_helper_add(>encoder, _helper_funcs);
+   drm_encoder_helper_add(encoder, _helper_funcs);

switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index 4b906b9..c6334b4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -35,6 +35,8 @@ struct rcar_du_encoder {
 #define to_rcar_encoder(e) \
container_of(e, struct rcar_du_encoder, encoder)

+#define rcar_encoder_to_drm_encoder(e) (&(e)->encoder)
+
 struct rcar_du_connector {
struct drm_connector connector;
struct rcar_du_encoder *encoder;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
index 80dc021..6d9811c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
@@ -84,6 +84,7 @@ int rcar_du_lvds_connector_init(struct rcar_du_device *rcdu,
struct rcar_du_encoder *renc,
/* TODO const */ struct device_node *np)
 {
+   struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(renc);
struct rcar_du_lvds_connector *lvdscon;
struct drm_connector *connector;
struct display_timing timing;
@@ -120,11 +121,11 @@ int rcar_du_lvds_connector_init(struct rcar_du_device 
*rcdu,
drm_object_property_set_value(>base,
rcdu->ddev->mode_config.dpms_property, DRM_MODE_DPMS_OFF);

-   ret = drm_mode_connector_attach_encoder(connector, >encoder);
+   ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0)
return ret;

-   connector->encoder = >encoder;
+   connector->encoder = encoder;
lvdscon->connector.encoder = renc;

return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
index 7807bb2..316108e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
@@ -52,6 +52,7 @@ static const struct drm_connector_funcs connector_funcs = {
 int rcar_du_vga_connector_init(struct rcar_du_device *rcdu,
   struct rcar_du_encoder *renc)
 {
+   struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(renc);
struct rcar_du_connector *rcon;
struct drm_connector *connector;
int ret;
@@ -78,11 +79,11 @@ int rcar_du_vga_connector_init(struct rcar_du_device *rcdu,
drm_object_property_set_value(>base,
rcdu->ddev->mode_config.dpms_property, DRM_MODE_DPMS_OFF);

-   ret = drm_mode_connector_attach_encoder(connector, >encoder);
+   ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0)
return ret;

-   connector->encoder = >encoder;
+   connector->encoder = encoder;
rcon->encoder = renc;

return 0;
-- 
1.8.5.5

[PATCH 05/12] drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()

[Laurent Pinchart]

The encoder DT node will be needed to register an external HDMI encoder.
Pass it to the rcar_du_encoder_init() function to prepare for HDMI
support.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +++--
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 3 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 89ed4a9..c699100 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -142,7 +142,8 @@ static const struct drm_encoder_funcs encoder_funcs = {
 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 enum rcar_du_encoder_type type,
 enum rcar_du_output output,
-struct device_node *np)
+struct device_node *enc_node,
+struct device_node *con_node)
 {
struct rcar_du_encoder *renc;
unsigned int encoder_type;
@@ -190,7 +191,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,

switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
-   return rcar_du_lvds_connector_init(rcdu, renc, np);
+   return rcar_du_lvds_connector_init(rcdu, renc, con_node);

case DRM_MODE_ENCODER_DAC:
return rcar_du_vga_connector_init(rcdu, renc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c37ed94..4b906b9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -49,6 +49,7 @@ rcar_du_connector_best_encoder(struct drm_connector 
*connector);
 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 enum rcar_du_encoder_type type,
 enum rcar_du_output output,
-struct device_node *np);
+struct device_node *enc_node,
+struct device_node *con_node);

 #endif /* __RCAR_DU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 6575681..a798294 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -289,7 +289,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
connector = entity;
}

-   ret = rcar_du_encoder_init(rcdu, enc_type, output, connector);
+   ret = rcar_du_encoder_init(rcdu, enc_type, output, encoder, connector);
of_node_put(encoder);
of_node_put(connector);

-- 
1.8.5.5

[PATCH 04/12] drm: rcar-du: Use for_each_endpoint_of_node()

[Laurent Pinchart]

Replace the manual loop implementation with the macro to simplify the
code.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index c6a7fd6..6575681 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -299,27 +299,19 @@ static int rcar_du_encoders_init_one(struct 
rcar_du_device *rcdu,
 static int rcar_du_encoders_init(struct rcar_du_device *rcdu)
 {
struct device_node *np = rcdu->dev->of_node;
-   struct device_node *prev = NULL;
unsigned int num_encoders = 0;
+   struct device_node *ep_node;

/*
 * Iterate over the endpoints and create one encoder for each output
 * pipeline.
 */
-   while (1) {
-   struct device_node *ep_node;
+   for_each_endpoint_of_node(np, ep_node) {
enum rcar_du_output output;
struct of_endpoint ep;
unsigned int i;
int ret;

-   ep_node = of_graph_get_next_endpoint(np, prev);
-   of_node_put(prev);
-   prev = ep_node;
-
-   if (ep_node == NULL)
-   break;
-
ret = of_graph_parse_endpoint(ep_node, );
if (ret < 0) {
of_node_put(ep_node);
-- 
1.8.5.5

[PATCH 03/12] drm: rcar-du: Remove platform data support

[Laurent Pinchart]

All platforms now instantiate the DU through DT, platform data support
isn't needed anymore.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 10 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  4 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  2 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c |  8 +---
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 10 +++--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 52 +++---
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 26 +--
 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |  2 -
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |  1 -
 include/linux/platform_data/rcar-du.h | 74 ---
 10 files changed, 38 insertions(+), 151 deletions(-)
 delete mode 100644 include/linux/platform_data/rcar-du.h

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index e97ae50..984e608 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,7 +15,6 @@
 #define __RCAR_DU_CRTC_H__

 #include 
-#include 

 #include 
 #include 
@@ -41,6 +40,15 @@ struct rcar_du_crtc {

 #define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, crtc)

+enum rcar_du_output {
+   RCAR_DU_OUTPUT_DPAD0,
+   RCAR_DU_OUTPUT_DPAD1,
+   RCAR_DU_OUTPUT_LVDS0,
+   RCAR_DU_OUTPUT_LVDS1,
+   RCAR_DU_OUTPUT_TCON,
+   RCAR_DU_OUTPUT_MAX,
+};
+
 int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index);
 void rcar_du_crtc_enable_vblank(struct rcar_du_crtc *rcrtc, bool enable);
 void rcar_du_crtc_cancel_page_flip(struct rcar_du_crtc *rcrtc,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index d212efa..967ae8f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -146,12 +146,11 @@ static int rcar_du_load(struct drm_device *dev, unsigned 
long flags)
 {
struct platform_device *pdev = dev->platformdev;
struct device_node *np = pdev->dev.of_node;
-   struct rcar_du_platform_data *pdata = pdev->dev.platform_data;
struct rcar_du_device *rcdu;
struct resource *mem;
int ret;

-   if (pdata == NULL && np == NULL) {
+   if (np == NULL) {
dev_err(dev->dev, "no platform data\n");
return -ENODEV;
}
@@ -163,7 +162,6 @@ static int rcar_du_load(struct drm_device *dev, unsigned 
long flags)
}

rcdu->dev = >dev;
-   rcdu->pdata = pdata;
rcdu->info = np ? of_match_device(rcar_du_of_table, rcdu->dev)->data
   : (void *)platform_get_device_id(pdev)->driver_data;
rcdu->ddev = dev;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 8e49463..0a72466 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -15,7 +15,6 @@
 #define __RCAR_DU_DRV_H__

 #include 
-#include 

 #include "rcar_du_crtc.h"
 #include "rcar_du_group.h"
@@ -67,7 +66,6 @@ struct rcar_du_device_info {

 struct rcar_du_device {
struct device *dev;
-   const struct rcar_du_platform_data *pdata;
const struct rcar_du_device_info *info;

void __iomem *mmio;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 7c0ec95..89ed4a9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -142,7 +142,6 @@ static const struct drm_encoder_funcs encoder_funcs = {
 int rcar_du_encoder_init(struct rcar_du_device *rcdu,
 enum rcar_du_encoder_type type,
 enum rcar_du_output output,
-const struct rcar_du_encoder_data *data,
 struct device_node *np)
 {
struct rcar_du_encoder *renc;
@@ -190,11 +189,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
drm_encoder_helper_add(>encoder, _helper_funcs);

switch (encoder_type) {
-   case DRM_MODE_ENCODER_LVDS: {
-   const struct rcar_du_panel_data *pdata =
-   data ? >connector.lvds.panel : NULL;
-   return rcar_du_lvds_connector_init(rcdu, renc, pdata, np);
-   }
+   case DRM_MODE_ENCODER_LVDS:
+   return rcar_du_lvds_connector_init(rcdu, renc, np);

case DRM_MODE_ENCODER_DAC:
return rcar_du_vga_connector_init(rcdu, renc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index bd62413..c37ed94 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -14,13 +14,18 @@
 #ifndef __RCAR_DU_ENCODER_H__
 #define __RCAR_DU_ENCODER_H__

-#include 
-
 #include 

 struct rcar_du_device;
 struct rcar_du_lvdsenc;

+enum rcar_du_encoder_type {
+   

[PATCH 02/12] of: Add for_each_endpoint_of_node helper macro

[Laurent Pinchart]

From: Philipp Zabel 

Note that while of_graph_get_next_endpoint decrements the reference count
of the child node passed to it, of_node_put(child) still has to be called
manually when breaking out of the loop.

Signed-off-by: Philipp Zabel 
Acked-by: Laurent Pinchart 
---
 include/linux/of_graph.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
index befef42..e43442e 100644
--- a/include/linux/of_graph.h
+++ b/include/linux/of_graph.h
@@ -26,6 +26,17 @@ struct of_endpoint {
const struct device_node *local_node;
 };

+/**
+ * for_each_endpoint_of_node - iterate over every endpoint in a device node
+ * @parent: parent device node containing ports and endpoints
+ * @child: loop variable pointing to the current endpoint node
+ *
+ * When breaking out of the loop, of_node_put(child) has to be called manually.
+ */
+#define for_each_endpoint_of_node(parent, child) \
+   for (child = of_graph_get_next_endpoint(parent, NULL); child != NULL; \
+child = of_graph_get_next_endpoint(parent, child))
+
 #ifdef CONFIG_OF
 int of_graph_parse_endpoint(const struct device_node *node,
struct of_endpoint *endpoint);
-- 
1.8.5.5