date:20140710

[PATCH 00/83] AMD HSA kernel driver

2014-07-10 Thread Gabbay, Oded

On Thu, 2014-07-10 at 18:24 -0400, Jerome Glisse wrote:
> On Fri, Jul 11, 2014 at 12:45:27AM +0300, Oded Gabbay wrote:
> >  This patch set implements a Heterogeneous System Architecture 
> > (HSA) driver
> >  for radeon-family GPUs.
>  
> This is just quick comments on few things. Given size of this, people
> will need to have time to review things.
>  
> >  HSA allows different processor types (CPUs, DSPs, GPUs, etc..) to 
> > share
> >  system resources more effectively via HW features including 
> > shared pageable
> >  memory, userspace-accessible work queues, and platform-level 
> > atomics. In
> >  addition to the memory protection mechanisms in GPUVM and 
> > IOMMUv2, the Sea
> >  Islands family of GPUs also performs HW-level validation of 
> > commands passed
> >  in through the queues (aka rings).
> >  The code in this patch set is intended to serve both as a sample 
> > driver for
> >  other HSA-compatible hardware devices and as a production driver 
> > for
> >  radeon-family processors. The code is architected to support 
> > multiple CPUs
> >  each with connected GPUs, although the current implementation 
> > focuses on a
> >  single Kaveri/Berlin APU, and works alongside the existing radeon 
> > kernel
> >  graphics driver (kgd).
> >  AMD GPUs designed for use with HSA (Sea Islands and up) share 
> > some hardware
> >  functionality between HSA compute and regular gfx/compute (memory,
> >  interrupts, registers), while other functionality has been added
> >  specifically for HSA compute  (hw scheduler for virtualized 
> > compute rings).
> >  All shared hardware is owned by the radeon graphics driver, and 
> > an interface
> >  between kfd and kgd allows the kfd to make use of those shared 
> > resources,
> >  while HSA-specific functionality is managed directly by kfd by 
> > submitting
> >  packets into an HSA-specific command queue (the "HIQ").
> >  During kfd module initialization a char device node (/dev/kfd) is 
> > created
> >  (surviving until module exit), with ioctls for queue creation & 
> > management,
> >  and data structures are initialized for managing HSA device 
> > topology.
> >  The rest of the initialization is driven by calls from the radeon 
> > kgd at
> >  the following points :
> >  - radeon_init (kfd_init)
> >  - radeon_exit (kfd_fini)
> >  - radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
> >  - radeon_driver_unload_kms (kfd_device_fini)
> >  During the probe and init processing per-device data structures 
> > are
> >  established which connect to the associated graphics kernel 
> > driver. This
> >  information is exposed to userspace via sysfs, along with a 
> > version number
> >  allowing userspace to determine if a topology change has occurred 
> > while it
> >  was reading from sysfs.
> >  The interface between kfd and kgd also allows the kfd to request 
> > buffer
> >  management services from kgd, and allows kgd to route interrupt 
> > requests to
> >  kfd code since the interrupt block is shared between regular
> >  graphics/compute and HSA compute subsystems in the GPU.
> >  The kfd code works with an open source usermode library 
> > ("libhsakmt") which
> >  is in the final stages of IP review and should be published in a 
> > separate
> >  repo over the next few days.
> >  The code operates in one of three modes, selectable via the 
> > sched_policy
> >  module parameter :
> >  - sched_policy=0 uses a hardware scheduler running in the MEC 
> > block within
> >  CP, and allows oversubscription (more queues than HW slots)
> >  - sched_policy=1 also uses HW scheduling but does not allow
> >  oversubscription, so create_queue requests fail when we run out 
> > of HW slots
> >  - sched_policy=2 does not use HW scheduling, so the driver 
> > manually assigns
> >  queues to HW slots by programming registers
> >  The "no HW scheduling" option is for debug & new hardware bringup 
> > only, so
> >  has less test coverage than the other options. Default in the 
> > current code
> >  is "HW scheduling without oversubscription" since that is where 
> > we have the
> >  most test coverage but we expect to change the default to "HW 
> > scheduling
> >  with oversubscription" after further testing. This effectively 
> > removes the
> >  HW limit on the number of work queues available to applications.
> >  Programs running on the GPU are associated with an address space 
> > through the
> >  VMID field, which is translated to a unique PASID at access time 
> > via a set
> >  of 16 VMID-to-PASID mapping registers. The available VMIDs 
> > (currently 16)
> >  are partitioned (under control of the radeon kgd) between current
> >  gfx/compute and HSA compute, with each getting 8 in the current 
> > code. The
> >  VMID-to-PASID mapping registers are updated by the HW scheduler 
> > when used,
> >  and by driver code if HW scheduling is not being used.
> >  The Sea Islands compute queues use a new "doorbell" mechanism 
> > instead of the
> >  earlier kernel-managed

[PATCH RFA] drm: add of_graph endpoint helper to find possible CRTCs

2014-07-10 Thread Rob Clark

On Thu, Jul 10, 2014 at 2:01 PM, Russell King
 wrote:
> Add a helper to allow encoders to find their possible CRTCs from the
> OF graph without having to re-implement this functionality.  We add a
> device_node to drm_crtc which corresponds with the port node in the
> DT description of the CRTC device.
>
> We can then scan the DRM device list for CRTCs to find their index,
> matching the appropriate CRTC using the port device_node, thus building
> up the possible CRTC mask.
>
> Signed-off-by: Russell King 
> ---
>
> RFA = request for acks
>
> - Updated commentry in the drm_of_find_possible_crtcs() comment block to
> point at the description of the of_graph bindings.
> - Not updated for drm kerneldoc as I'm unable to build the documentation.

hmm, I wonder if kbuild robot builds docs?

Anyways, no worries.. I can add the entries in drm.tmpl once this
lands.. if I forget, someone remind me ;-)


Reviewed-by: Rob Clark 


>
>  drivers/gpu/drm/Makefile |  1 +
>  drivers/gpu/drm/drm_of.c | 67 
> 
>  include/drm/drm_crtc.h   |  2 ++
>  include/drm/drm_of.h | 18 +
>  4 files changed, 88 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_of.c
>  create mode 100644 include/drm/drm_of.h
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index dd2ba4269740..533d011eab3e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -20,6 +20,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
>  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> +drm-$(CONFIG_OF) += drm_of.o
>
>  drm-usb-y   := drm_usb.o
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> new file mode 100644
> index ..16150a00c237
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -0,0 +1,67 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
> + * @dev: DRM device
> + * @port: port OF node
> + *
> + * Given a port OF node, return the possible mask of the corresponding
> + * CRTC within a device's list of CRTCs.  Returns zero if not found.
> + */
> +static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> +  struct device_node *port)
> +{
> +   unsigned int index = 0;
> +   struct drm_crtc *tmp;
> +
> +   list_for_each_entry(tmp, >mode_config.crtc_list, head) {
> +   if (tmp->port == port)
> +   return 1 << index;
> +
> +   index++;
> +   }
> +
> +   return 0;
> +}
> +
> +/**
> + * drm_of_find_possible_crtcs - find the possible CRTCs for an encoder port
> + * @dev: DRM device
> + * @port: encoder port to scan for endpoints
> + *
> + * Scan all endpoints attached to a port, locate their attached CRTCs,
> + * and generate the DRM mask of CRTCs which may be attached to this
> + * encoder.
> + *
> + * See Documentation/devicetree/bindings/graph.txt for the bindings.
> + */
> +uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> +   struct device_node *port)
> +{
> +   struct device_node *remote_port, *ep = NULL;
> +   uint32_t possible_crtcs = 0;
> +
> +   do {
> +   ep = of_graph_get_next_endpoint(port, ep);
> +   if (!ep)
> +   break;
> +
> +   remote_port = of_graph_get_remote_port(ep);
> +   if (!remote_port) {
> +   of_node_put(ep);
> +   return 0;
> +   }
> +
> +   possible_crtcs |= drm_crtc_port_mask(dev, remote_port);
> +
> +   of_node_put(remote_port);
> +   } while (1);
> +
> +   return possible_crtcs;
> +}
> +EXPORT_SYMBOL(drm_of_find_possible_crtcs);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 251b75e6bf7a..6a94909f1ca9 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -41,6 +41,7 @@ struct drm_framebuffer;
>  struct drm_object_properties;
>  struct drm_file;
>  struct drm_clip_rect;
> +struct device_node;
>
>  #define DRM_MODE_OBJECT_CRTC 0x
>  #define DRM_MODE_OBJECT_CONNECTOR 0xc0c0c0c0
> @@ -314,6 +315,7 @@ struct drm_crtc_funcs {
>   */
>  struct drm_crtc {
> struct drm_device *dev;
> +   struct device_node *port;
> struct list_head head;
>
> /**
> diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
> new file mode 100644
> index ..2441f7112074
> --- /dev/null
> +++ b/include/drm/drm_of.h
> @@ -0,0 +1,18 @@
> +#ifndef __DRM_OF_H__
> +#define __DRM_OF_H__
> +
> +struct drm_device;
> +struct device_node;
> +
> +#ifdef CONFIG_OF
> +extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> +  struct

[PATCH] modesetting: Support native primary plane rotation

2014-07-10 Thread Mark Kettenis

> From: Chris Wilson 
> Date: Wed,  9 Jul 2014 12:14:41 +0100
> 
> With the advent of universal drm planes and the introduction of generic
> plane properties for rotations, we can query and program the hardware
> for native rotation support.
> 
> NOTE: this depends upon the next release of libdrm to remove one
> opencoded define.
> 
> v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
> Use libobj for replacement ffs(), suggested by walter harms
> v3: Support combinations of rotations and reflections
> Eliminate use of ffs() and so remove need for libobj

Surely that means...
>  
> +#ifndef HAVE_FFS
> +extern int ffs(unsigned int value);
> +#endif

This bit should be removed ad well?

[PATCH] modesetting: Support native primary plane rotation

2014-07-10 Thread Pekka Paalanen

On Wed, 9 Jul 2014 11:02:59 +0100
Chris Wilson  wrote:

> On Wed, Jul 09, 2014 at 12:57:12PM +0300, Pekka Paalanen wrote:
> > On Wed,  9 Jul 2014 09:19:08 +0100
> > Chris Wilson  wrote:
> > 
> > > With the advent of universal drm planes and the introduction of generic
> > > plane properties for rotations, we can query and program the hardware
> > > for native rotation support.
> > > 
> > > NOTE: this depends upon the next release of libdrm to remove one
> > > opencoded define.
> > > 
> > > v2: Use enum to determine primary plane, suggested by Pekka Paalanen.
> > > Use libobj for replacement ffs(), suggested by walter harms
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Pekka Paalanen 
> > > Cc: walter harms 
> > 
> > My concerns have been addressed. On a second read, I found another
> > suspicious thing below.
> > 
> > > + if (strcmp(prop->name, "rotation") == 0) {
> > > + drmmode_crtc->rotation_prop_id = 
> > > proplist->props[j];
> > > + drmmode_crtc->current_rotation = 
> > > proplist->prop_values[j];
> > > + for (k = 0; k < prop->count_enums; k++) 
> > > {
> > > + int rr = -1;
> > > + if (strcmp(prop->enums[k].name, 
> > > "rotate-0") == 0)
> > > + rr = RR_Rotate_0;
> > > + else if 
> > > (strcmp(prop->enums[k].name, "rotate-90") == 0)
> > > + rr = RR_Rotate_90;
> > > + else if 
> > > (strcmp(prop->enums[k].name, "rotate-180") == 0)
> > > + rr = RR_Rotate_180;
> > > + else if 
> > > (strcmp(prop->enums[k].name, "rotate-270") == 0)
> > > + rr = RR_Rotate_270;
> > > + else if 
> > > (strcmp(prop->enums[k].name, "reflect-x") == 0)
> > > + rr = RR_Reflect_X;
> > > + else if 
> > > (strcmp(prop->enums[k].name, "reflect-y") == 0)
> > > + rr = RR_Reflect_Y;
> > > + if (rr != -1) {
> > > + 
> > > drmmode_crtc->map_rotations[rotation_index(rr)] = 1 << 
> > > prop->enums[k].value;
> > > + 
> > > drmmode_crtc->supported_rotations |= rr;
> > 
> > Comparing the above assignments to...
> > 
> > > +static Bool
> > > +rotation_set(xf86CrtcPtr crtc, unsigned rotation)
> > > +{
> > > + drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
> > > + drmmode_ptr drmmode = drmmode_crtc->drmmode;
> > > +
> > > + if (drmmode_crtc->current_rotation == rotation)
> > > + return TRUE;
> > > +
> > > + if ((drmmode_crtc->supported_rotations & rotation) == 0)
> > > + return FALSE;
> > > +
> > > + if (drmModeObjectSetProperty(drmmode->fd,
> > > +  drmmode_crtc->primary_plane_id,
> > > +  DRM_MODE_OBJECT_PLANE,
> > > +  drmmode_crtc->rotation_prop_id,
> > > +  
> > > drmmode_crtc->map_rotations[rotation_index(rotation)]))
> > 
> > ...the use here, it does not look like you are passing
> > prop->enums[k].value here. It is like you are missing ffs() here or
> > having a 1<< too much in the assignment.
> 
> It doesn't take the enum.value but 1 << enum.value.

Aah, it is not an 'enum', it is a 'bitmask'! Okay, I see it now, I
think.


Thanks,
pq

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

2014-07-10 Thread Tian, Kevin

> From: Daniel Vetter
> Sent: Monday, July 07, 2014 11:40 AM
> 
> On Mon, Jul 07, 2014 at 07:58:30PM +0200, Paolo Bonzini wrote:
> > Il 07/07/2014 19:54, Daniel Vetter ha scritto:
> > >On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote:
> > >>Il 07/07/2014 16:49, Daniel Vetter ha scritto:
> > >>>So the correct fix to forward intel gpus to guests is indeed to somehow
> > >>>fake the pch pci ids since the driver really needs them. Gross design, 
> > >>>but
> > >>>that's how the hardware works.
> > >>
> > >>A way that could work for virtualization is this: if you find the card 
> > >>has a
> > >>magic subsystem vendor id, fetch the subsystem device id and use _that_
> as
> > >>the PCH device id.
> > >>
> > >>Would that work for you?
> > >
> > >I guess for quemu it also depends upon what windows does since we can't
> > >change that. If we care about that part. Another consideration is
> > >supporting older kernels, if that's possible at all.
> >
> > Yes, but right now it's more important to get something that's not too gross
> > for the future, for both Linux and Windows.  Hacks for existing guests can
> > be done separately, especially since they might differ between Linux (check
> > ISA bridge) and Windows (check 1f.0).
> 
> Well old Linux also checked 1f.0, so kinda the same really. As long as
> 1f.0 is an isa bridge. Wrt Windows I don't really expect them to change
> this (they're probably more focuesed on the windows hypervisor or whatever).

discussion is also on-going with Windows driver folks. Add Allen here.

> 
> In the end if the approach is ok for quemu and isn't much worse than what
> we currently have I don't mind at all about the i915.ko code. I just want
> to avoid flip-flopping around on the hack du jour like we seem to do just
> now.
> -Daniel

actually I'm curious whether it's still necessary to __detect__ PCH. Could
we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
code the knowledge:

  } else if (IS_BROADWELL(dev)) {
  dev_priv->pch_type = PCH_LPT;
  dev_priv->pch_id =
  INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
  DRM_DEBUG_KMS("This is Broadwell, assuming "
"LynxPoint LP PCH\n");

Or if there is real usage on non-fixed mapping (not majority), could it be a 
better option to have fixed mapping as a fallback instead of leaving as 
PCH_NONE? Then even when Qemu doesn't provide a special tweaked PCH,
the majority case just works.

Thanks
Kevin

[Bug 81192] Garbled screen with VDPAU playback and h264

2014-07-10 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Simon Gebler  ---
Oh, also.. nothing about that can be found in the Xorg logfile.
And I'll try to gather some output from mplayer from when the screen freezes,
if there will be anything, when I got some spare time later and feel like
crashing my xorg again

-- 
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/20140710/1fdd2aca/attachment-0001.html>

[Bug 81192] Garbled screen with VDPAU playback and h264

2014-07-10 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Simon Gebler  ---
Created attachment 102580
  --> https://bugs.freedesktop.org/attachment.cgi?id=102580=edit
crash log 2

-- 
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/20140710/06501dc4/attachment.html>

[Bug 81192] Garbled screen with VDPAU playback and h264

2014-07-10 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Simon Gebler  ---
Created attachment 102579
  --> https://bugs.freedesktop.org/attachment.cgi?id=102579=edit
crash log

-- 
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/20140710/5716d70b/attachment.html>

[Bug 81192] Garbled screen with VDPAU playback and h264

2014-07-10 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Simon Gebler  ---
Created attachment 102578
  --> https://bugs.freedesktop.org/attachment.cgi?id=102578=edit
vdpauinfo output

-- 
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/20140710/e57ceb37/attachment.html>

[Bug 81192] New: Garbled screen with VDPAU playback and h264

2014-07-10 Thread bugzilla-dae...@freedesktop.org

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

Priority: medium
Bug ID: 81192
Assignee: dri-devel at lists.freedesktop.org
Summary: Garbled screen with VDPAU playback and h264
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: sige at stripeyc.at
Hardware: x86-64 (AMD64)
Status: NEW
Version: unspecified
Component: Drivers/Gallium/r600
Product: Mesa

Created attachment 102577
--> https://bugs.freedesktop.org/attachment.cgi?id=102577=edit
dmesg output

Whenever I try playing a h264 encoded movie, the system/X11 locks up completely
with 3 different symptoms.
X freezes, I might be able to move the mousecursor (which doesn't change), was
able to log in to the machine remotely and reboot it.
X freezes first, full screen is garbled just a few seconds later.
Additionally I might be able to move some square, which is likely the
"cursor".. garbled as well. I must be honest I didn't try logging in remotely
there yet, if the machine itself is still alive.

Machie is running:
Linux 3.15.4 from the repo and tried on a 3.16rc4 today (Installed that to test
against a kernel bug)
Xorg is 1.15.2
mesa is 10.2.3
mplayer is SVN-r37224

I tried a mpeg2 video and played it just fine
( mplayer -vo vdpau -vc ffmpeg12vdpau )
I also got two h264 files and it freezes/garbles every time there

http://samples.mplayerhq.hu/V-codecs/h264/PAFF/Grey.ts
http://samples.mplayerhq.hu/V-codecs/h264/nature_704x576_25Hz_1500kbits.h264
mplayer -vo vdpau -vc ffh264vdpau

It reliably just freezes the screen, with the mouse working for a while or
completely garbles it.
I also had an occurrence of the screen going garbled and then black, back to
the garbled screen. Three times or something. Maybe he tried resetting the GPU
or something; I don't know. Not sure if I can find any logs from that one.

Also: Haven't tried any other codecs yet, that might be supported.

--
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/20140710/c161ec08/attachment.html>

80 matches

Mail list logo