[RFC 3/4] drm: add generic blob properties for image enhancement
On 8 March 2014 06:16, Matt Roper wrote:
> On Fri, Mar 07, 2014 at 03:50:54PM +0530, Rahul Sharma wrote:
>> Hi Daniel,
>>
>> On 7 March 2014 14:06, Daniel Vetter wrote:
>> > On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
>> >> Add generic KMS blob properties to core drm framework. These
>> >> are writable blob properties which can be used to set Image
>> >> Enhancement parameters. The properties which are added here
>> >> are meant for color reproduction, color saturation and edge
>> >> enhancement.
>> >>
>> >> Signed-off-by: Rahul Sharma
> ...
>> > Tbh I don't really understand why we can't use normal properties for this.
>> > We might want to add a new RBG type of property (or YUV fwiw, both with
>> > and without alpha) to make this standardized (maybe with some fixed point
>> > value for non-normalizes).
>>
>> I dropped Normal properties (the ones which accepts 64 bit data)
>> because there will be too many of them. As you can see the
>> count is going upto 24 parameters, means 24 such properties, as
>> each can carry one parameter. This is too much of overhead.
>> Please correct me if you mean something different.
>>
>> I am not sure what are RGB type properties? I know only about 64-bit
>> normal properties which are too compact to carry above structures. Are
>> you talking about set_gamma type of ioctls. Each "set_gamma" type
>> ioctl needs a addition in callbacks till down the layer which looks bit
>> unnecessary, while writable blob properties are using same set_property
>> and get_property infrastructure.
>>
>> >
>> > If the only reason you group them is to atomically commit them, then the
>> > only thing we need is the atomic ioctl, which can shovel entire groups of
>> > properties over the wire at once.
>>
>> Atomic commit is not an explicit requirement. But splitting them to
>> many small pieces (in case of normal properties) are resulting into
>> many user-kernel switching overhead, which seems avoidable.
>
> The idea with atomic modeset / nuclear pageflip is that you collect a
> whole bunch of individual property updates into a "property set"
> container in userspace (libdrm). When you're done setting all the
> values you want and "commit" the property set, all of the values that
> you collected get passed to the kernel in one go via a new ioctl (and
> are then updated in an atomic manner by the DRM driver). So performing
> your 24 different property updates via the upcoming atomic API's
> shouldn't be a problem and shouldn't add any unnecessary overhead.
>
> The kernel-side of atomic modeset / nuclear pageflip is still a WIP, so
> it isn't upstream yet, but you can see the userspace-facing API in Rob
> Clark's repo here:
>
> https://github.com/robclark/libdrm/blob/atomic/xf86drmMode.h
>
> Note the drmModePropertySet{Alloc,Add,Commit,Free}() functions near the
> bottom.
>
Thanks Matt,
I went through the share link. Got the idea of atomic
modeset. It is a good solution for setting 24 properties
in one go. But another issue is still unaddressed. I
mean still need to declare 24 properties which are not
"Really 24 different properties".
These are sub-parameters to 3 properties (color
reproduction, color saturation and edge enhancement).
Splitting them to 24 pieces, just because we don't have a
a provision in KMS, is a work around to get things
working. And, properties like "saturation_hue_gain_red",
"saturation_hue_gain_green" ... will be undoubtedly ugly.
In Rob Clark's tree, I noticed
extern int drmModePropertySetAddBlob(drmModePropertySetPtr set,
uint32_t object_id,
uint32_t property_id,
uint64_t length,
void *blob);
Seems, already some implementation of writable blobs is
there. I am not able to see the kernel though.
I request experts, to review this solution again. I found it
quite useful and hold good with the idea of Atomic modeset.
Regards,
Rahul Sharma
>
> Matt
>
> --
> Matt Roper
> Graphics Software Engineer
> ISG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
[RFC 3/4] drm: add generic blob properties for image enhancement
On Mon, Mar 10, 2014 at 09:50:14AM +0530, Rahul Sharma wrote:
> On 8 March 2014 06:16, Matt Roper wrote:
> > On Fri, Mar 07, 2014 at 03:50:54PM +0530, Rahul Sharma wrote:
> >> Hi Daniel,
> >>
> >> On 7 March 2014 14:06, Daniel Vetter wrote:
> >> > On Thu, Mar 06, 2014 at 11:42:13AM +0530, Rahul Sharma wrote:
> >> >> Add generic KMS blob properties to core drm framework. These
> >> >> are writable blob properties which can be used to set Image
> >> >> Enhancement parameters. The properties which are added here
> >> >> are meant for color reproduction, color saturation and edge
> >> >> enhancement.
> >> >>
> >> >> Signed-off-by: Rahul Sharma
> > ...
> >> > Tbh I don't really understand why we can't use normal properties for
> >> > this.
> >> > We might want to add a new RBG type of property (or YUV fwiw, both with
> >> > and without alpha) to make this standardized (maybe with some fixed point
> >> > value for non-normalizes).
> >>
> >> I dropped Normal properties (the ones which accepts 64 bit data)
> >> because there will be too many of them. As you can see the
> >> count is going upto 24 parameters, means 24 such properties, as
> >> each can carry one parameter. This is too much of overhead.
> >> Please correct me if you mean something different.
> >>
> >> I am not sure what are RGB type properties? I know only about 64-bit
> >> normal properties which are too compact to carry above structures. Are
> >> you talking about set_gamma type of ioctls. Each "set_gamma" type
> >> ioctl needs a addition in callbacks till down the layer which looks bit
> >> unnecessary, while writable blob properties are using same set_property
> >> and get_property infrastructure.
> >>
> >> >
> >> > If the only reason you group them is to atomically commit them, then the
> >> > only thing we need is the atomic ioctl, which can shovel entire groups of
> >> > properties over the wire at once.
> >>
> >> Atomic commit is not an explicit requirement. But splitting them to
> >> many small pieces (in case of normal properties) are resulting into
> >> many user-kernel switching overhead, which seems avoidable.
> >
> > The idea with atomic modeset / nuclear pageflip is that you collect a
> > whole bunch of individual property updates into a "property set"
> > container in userspace (libdrm). When you're done setting all the
> > values you want and "commit" the property set, all of the values that
> > you collected get passed to the kernel in one go via a new ioctl (and
> > are then updated in an atomic manner by the DRM driver). So performing
> > your 24 different property updates via the upcoming atomic API's
> > shouldn't be a problem and shouldn't add any unnecessary overhead.
> >
> > The kernel-side of atomic modeset / nuclear pageflip is still a WIP, so
> > it isn't upstream yet, but you can see the userspace-facing API in Rob
> > Clark's repo here:
> >
> > https://github.com/robclark/libdrm/blob/atomic/xf86drmMode.h
> >
> > Note the drmModePropertySet{Alloc,Add,Commit,Free}() functions near the
> > bottom.
> >
>
> Thanks Matt,
>
> I went through the share link. Got the idea of atomic
> modeset. It is a good solution for setting 24 properties
> in one go. But another issue is still unaddressed. I
> mean still need to declare 24 properties which are not
> "Really 24 different properties".
>
> These are sub-parameters to 3 properties (color
> reproduction, color saturation and edge enhancement).
> Splitting them to 24 pieces, just because we don't have a
> a provision in KMS, is a work around to get things
> working. And, properties like "saturation_hue_gain_red",
> "saturation_hue_gain_green" ... will be undoubtedly ugly.
>
> In Rob Clark's tree, I noticed
>
> extern int drmModePropertySetAddBlob(drmModePropertySetPtr set,
> uint32_t object_id,
> uint32_t property_id,
> uint64_t length,
> void *blob);
>
> Seems, already some implementation of writable blobs is
> there. I am not able to see the kernel though.
>
> I request experts, to review this solution again. I found it
> quite useful and hold good with the idea of Atomic modeset.
Like I've said I think creating a standard property for RBG and RBGA
values makes sense, to group this stuff a bit. But I don't think we need
to group things further.
Some clear definitions of these properties is needed though - Sagar from
our display group is working on that a bit.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 Michel D?nzer changed: What|Removed |Added Attachment #95412|application/x-trash |text/plain mime type|| -- 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/20140310/49dd9dbe/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #201 from Michel D?nzer --- *** Bug 74420 has been marked as a duplicate of this bug. *** -- 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/20140310/3f6f5a01/attachment.html>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 Michel D?nzer changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |DUPLICATE --- Comment #21 from Michel D?nzer --- (In reply to comment #19) > I am getting more detailed logs in the recent version. I hope those can help > to solve the issue. Unfortunately not, the backtraces in the log file just show where the driver hangs due to the hanging GPU, they don't say anything about what caused the GPU to hang. Unless you can reproduce this problem with DPM disabled, please follow up on bug 66963 instead of reopening this one. *** This bug has been marked as a duplicate of bug 66963 *** -- 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/20140310/eb0a5882/attachment-0001.html>
[Bug 64475] Slow work and no brightness adjustment in Euro Track Simulator II game with r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=64475 Michel D?nzer changed: What|Removed |Added Attachment #95340|text/plain |image/png mime type|| -- 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/20140310/47386b43/attachment.html>
[Bug 64475] Euro Track Simulator II game slow in cabin with r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=64475 Michel D?nzer changed: What|Removed |Added Summary|Slow work and no brightness |Euro Track Simulator II |adjustment in Euro Track|game slow in cabin with |Simulator II game with |r600g and radeonsi |r600g and radeonsi | -- 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/20140310/d852feed/attachment.html>
[Bug 75491] Radeon HD7750 no Monitors connected
https://bugs.freedesktop.org/show_bug.cgi?id=75491 Eric Gr?ttefien changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Eric Gr?ttefien --- With DP: aux(p/n) connected to HDMI:DD(C/D) it works as it should be. Sorry for the noise and thank you for the helping hints. -- 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/20140310/c7c22a33/attachment.html>
[Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Sun, Mar 09, 2014 at 12:37:49AM +0530, Sagar Arun Kamble wrote: > On Sun, 2014-03-09 at 00:34 +0530, Sagar Arun Kamble wrote: > > On Sat, 2014-03-08 at 13:51 -0500, Alex Deucher wrote: > > > On Sat, Mar 8, 2014 at 1:49 PM, wrote: > > > > From: Sagar Kamble > > > > > > > > With this patch we allow larger cursor planes of sizes 128x128 > > > > and 256x256. > > > > > > > > v2: Added more precise check on size while setting cursor plane. > > > > > > > > v3: Changes related to restructuring cursor size restrictions > > > > and DRM_DEBUG usage. > > > > > > > > > > I'm not sure how useful it is since you appear to be able to > > > selectively adjust the cursor size, but I recently added support for > > > exposing the cursor size as a drm cap: > > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8716ed4e7bed4e4c7e3f37940e950ddc0362f450 > > > > > > Alex > > Thanks Alex. This is useful for cursor test to enumerate sub-tests based > > on these caps. > Realized after sending mail that we just get to know current cursor > width and height. Can we have capability that exposes all supported > cursor sizes? The cap exposes the max cursor size. Knowing our hardware we can infer that pot sizes from 64 to max are supported, but it would be better if we did expose that information through the cap as well. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 1/2] drm: Make control nodes master-less
On 03/05/2014 03:32 PM, David Herrmann wrote:
> Hi
>
> On Wed, Feb 19, 2014 at 2:40 PM, Thomas Hellstrom
> wrote:
>> Like for render-nodes, there is no point in maintaining the master concept
>> for control nodes, so set the struct drm_file::master pointer to NULL.
>>
>> At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always
>> allowed when called through the control node. Previously the caller also
>> needed to be master.
>>
>> Signed-off-by: Thomas Hellstrom
>> ---
>> drivers/gpu/drm/drm_drv.c |5 +++--
>> drivers/gpu/drm/drm_fops.c |5 +++--
>> include/drm/drmP.h |5 +
>> 3 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 345be03..42af8bd 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -355,8 +355,9 @@ long drm_ioctl(struct file *filp,
>> retcode = -EINVAL;
>> } else if (((ioctl->flags & DRM_ROOT_ONLY) &&
>> !capable(CAP_SYS_ADMIN)) ||
>>((ioctl->flags & DRM_AUTH) &&
>> !drm_is_render_client(file_priv) && !file_priv->authenticated) ||
>> - ((ioctl->flags & DRM_MASTER) && !file_priv->is_master) ||
>> - (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
>> (file_priv->minor->type == DRM_MINOR_CONTROL)) ||
>> + (((ioctl->flags & DRM_MASTER) && !file_priv->is_master) &&
>> + !(drm_is_control(file_priv) && (ioctl->flags &
>> DRM_CONTROL_ALLOW))) ||
>> + (!(ioctl->flags & DRM_CONTROL_ALLOW) &&
>> drm_is_control(file_priv)) ||
>>(!(ioctl->flags & DRM_RENDER_ALLOW) &&
>> drm_is_render_client(file_priv))) {
>> retcode = -EACCES;
>> } else {
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 7f2af9a..08a3196 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -259,7 +259,8 @@ static int drm_open_helper(struct inode *inode, struct
>> file *filp,
>> /* if there is no current master make this fd it, but do not create
>> * any master object for render clients */
>> mutex_lock(&dev->struct_mutex);
>> - if (!priv->minor->master && !drm_is_render_client(priv)) {
>> + if (!priv->minor->master && !drm_is_render_client(priv) &&
>> + !drm_is_control(priv)) {
>> /* create a new master */
>> priv->minor->master = drm_master_create(priv->minor);
>> if (!priv->minor->master) {
>> @@ -297,7 +298,7 @@ static int drm_open_helper(struct inode *inode, struct
>> file *filp,
>> goto out_close;
>> }
>> }
>> - } else if (!drm_is_render_client(priv)) {
>> + } else if (!drm_is_render_client(priv) && !drm_is_control(priv)) {
>> /* get a reference to the master */
>> priv->master = drm_master_get(priv->minor->master);
> Maybe I missed some other patches, but how is this going to work?
> drm_crtc.c expects priv->master to be non-NULL (eg.,
> drm_mode_getresources()). This is fine for render-nodes as they don't
> allow any of those ioctls, but the control-node does allow them.
>
> Thanks
> David
>
>
Hi!
You didn't miss any patches. It was I who missed the usage in drm_crtc.c.
I guess this, and Daniel's reply prompts a discussion about control
nodes and the master concept.
First I'd like to give some background about the use-case: I'd like to
use the control node for a daemon that tells the vmwgfx driver about the
host GUI layout of the screen: What connectors are enabled, the
preferred mode of each output and some driver private information. The
daemon will run as root and only a single instance per device. Trying to
do this as-is will cause the vmwgfx driver to BUG() because it currently
assumes one active master per device. Not one active master per minor
(although that could be changed if needed).
Looking at
http://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/
it doesn't really make sense to keep the master concept on the control
node, but it perhaps makes sense to keep it on future modesetting nodes
to allow multiple modesetters to open the same device node?
In that case all master access in drm_crtc.c would be changed for now to
be conditioned on file_priv->minor->type == DRM_MINOR_LEGACY
/Thomas
[Bug 75719] mplayer -vo gl consume more CPU on r200
https://bugs.freedesktop.org/show_bug.cgi?id=75719 --- Comment #15 from Thomas Hellstr?m --- (In reply to comment #14) > (In reply to comment #8) > > So if CPU usage is drastically increased by this commit (or rather this > > merge), IMHO that points to a bug somewhere else, but triggered by this > > merge; possibly in radeon / TTM caching setup or in the x86 PAT memory > > region tracking code. > > > > Seems like that is the case... VM_PFNMAP usage instead of VM_MIXEDMAP > triggers that i now need 'nopat' boot option it is also workaround... > > So only 'nopat' option work here good with VM_PFNMAP or like before > VM_MIXEDMAP is good with PAT... VM_PFNMAP with PAT here is really unusable > for gl videos :). Interesting, although it's not the first time x86 pat/caching has busted graphics performance-wise, which might appear a bit strange considering graphics is a major user. In any case, I'll put together a patch to revert the VM_PFNMAP usage until I've figured out what's really happening (it's only there to boost performance anyway). Meanwhile, the fact that this is visible also points to an area of potential improvement in the radeon driver. Apparently video playback causes a lot of buffer maps / unmaps. Could the maps somehow be cached in the driver? Thanks, Thomas -- 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/20140310/60a58ca9/attachment-0001.html>
[Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Mon, Mar 10, 2014 at 10:29 AM, Chris Wilson wrote: >> Realized after sending mail that we just get to know current cursor >> width and height. Can we have capability that exposes all supported >> cursor sizes? > > The cap exposes the max cursor size. Knowing our hardware we can infer > that pot sizes from 64 to max are supported, but it would be better if > we did expose that information through the cap as well. I think the right approach here is to expose this through the cursor-as-real-plane interface, which kinda has this already. On top of that we can then add a few fourcc enumerations of the fixed rgba cursor layouts like 64x64, 128x128, ... This helps if the plane is a general one with very high limits, but also with special support for cursor formats. If anyone wants to go crazy we could then also add new fourccs for all the other cursor layouts - atm only rgba with fixed dimensions can be support with the current cursor ioctl. So reviewing the overall situation I actually _don't_ want a new cap/ioctl/prop here just for now. As long as we need to go with intel specific hacks userspace might as well probe things manually and act upon the -EINVAL. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Mon, Mar 10, 2014 at 10:55:40AM +0100, Daniel Vetter wrote: > On Mon, Mar 10, 2014 at 10:29 AM, Chris Wilson > wrote: > >> Realized after sending mail that we just get to know current cursor > >> width and height. Can we have capability that exposes all supported > >> cursor sizes? > > > > The cap exposes the max cursor size. Knowing our hardware we can infer > > that pot sizes from 64 to max are supported, but it would be better if > > we did expose that information through the cap as well. > > I think the right approach here is to expose this through the > cursor-as-real-plane interface, which kinda has this already. On top > of that we can then add a few fourcc enumerations of the fixed rgba > cursor layouts like 64x64, 128x128, ... This helps if the plane is a > general one with very high limits, but also with special support for > cursor formats. > > If anyone wants to go crazy we could then also add new fourccs for all > the other cursor layouts - atm only rgba with fixed dimensions can be > support with the current cursor ioctl. > > So reviewing the overall situation I actually _don't_ want a new > cap/ioctl/prop here just for now. As long as we need to go with intel > specific hacks userspace might as well probe things manually and act > upon the -EINVAL. Adding the cap allows existing userspace to dtrt... -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Sun, Mar 09, 2014 at 12:19:06AM +0530, sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> With this patch we allow larger cursor planes of sizes 128x128
> and 256x256.
>
> v2: Added more precise check on size while setting cursor plane.
>
> v3: Changes related to restructuring cursor size restrictions
> and DRM_DEBUG usage.
>
> Testcase: igt/kms_cursor_crc
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: G, Pallavi
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_display.c | 36
> +++-
> 2 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 146609a..aee8258 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3551,7 +3551,11 @@ enum punit_power_well {
> /* New style CUR*CNTR flags */
> #define CURSOR_MODE0x27
> #define CURSOR_MODE_DISABLE 0x00
> +#define CURSOR_MODE_128_32B_AX 0x02
> +#define CURSOR_MODE_256_32B_AX 0x03
> #define CURSOR_MODE_64_32B_AX 0x07
> +#define CURSOR_MODE_128_ARGB_AX ((1 << 5) | CURSOR_MODE_128_32B_AX)
> +#define CURSOR_MODE_256_ARGB_AX ((1 << 5) | CURSOR_MODE_256_32B_AX)
> #define CURSOR_MODE_64_ARGB_AX ((1 << 5) | CURSOR_MODE_64_32B_AX)
> #define MCURSOR_PIPE_SELECT(1 << 28)
> #define MCURSOR_PIPE_A 0x00
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0868afb..e59e8fd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7440,10 +7440,22 @@ static void i9xx_update_cursor(struct drm_crtc *crtc,
> u32 base)
> bool visible = base != 0;
>
> if (intel_crtc->cursor_visible != visible) {
> + int16_t width = intel_crtc->cursor_width;
> uint32_t cntl = I915_READ(CURCNTR(pipe));
> if (base) {
> cntl &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT);
> - cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
> +
> + switch (width) {
> + case 64:
> + cntl |= CURSOR_MODE_64_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + break;
We don't needlessly indent case 64: and the following code. Even with that
this indents a bit too far, so I suggest you extract the width->flags
computation into a little helper and use it in both places. Also please
extract the GAMMA flag, it's something else. Finally please add a default:
case and put a WARN_ON(1) in there, to make sure our code doesn't let
invalid cases slip through.
-Daniel
> + case 128:
> + cntl |= CURSOR_MODE_128_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + break;
> + case 256:
> + cntl |= CURSOR_MODE_256_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + break;
> + }
> cntl |= pipe << 28; /* Connect to correct pipe */
> } else {
> cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
> @@ -7468,10 +7480,22 @@ static void ivb_update_cursor(struct drm_crtc *crtc,
> u32 base)
> bool visible = base != 0;
>
> if (intel_crtc->cursor_visible != visible) {
> + int16_t width = intel_crtc->cursor_width;
> uint32_t cntl = I915_READ(CURCNTR_IVB(pipe));
> if (base) {
> cntl &= ~CURSOR_MODE;
> - cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
> +
> + switch (width) {
> + case 64:
> + cntl |= CURSOR_MODE_64_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + break;
> + case 128:
> + cntl |= CURSOR_MODE_128_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + break;
> + case 256:
> + cntl |= CURSOR_MODE_256_ARGB_AX |
> MCURSOR_GAMMA_ENABLE;
> + break;
> + }
> } else {
> cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
> cntl |= CURSOR_MODE_DISABLE;
> @@ -7567,9 +7591,11 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
> goto finish;
> }
>
> - /* Currently we only support 64x64 cursors */
> - if (width != 64 || height != 64) {
> - DRM_ERROR("we currently only support 64x64 cursors\n");
> + /* Ch
[Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson wrote: >> > The cap exposes the max cursor size. Knowing our hardware we can infer >> > that pot sizes from 64 to max are supported, but it would be better if >> > we did expose that information through the cap as well. >> >> I think the right approach here is to expose this through the >> cursor-as-real-plane interface, which kinda has this already. On top >> of that we can then add a few fourcc enumerations of the fixed rgba >> cursor layouts like 64x64, 128x128, ... This helps if the plane is a >> general one with very high limits, but also with special support for >> cursor formats. >> >> If anyone wants to go crazy we could then also add new fourccs for all >> the other cursor layouts - atm only rgba with fixed dimensions can be >> support with the current cursor ioctl. >> >> So reviewing the overall situation I actually _don't_ want a new >> cap/ioctl/prop here just for now. As long as we need to go with intel >> specific hacks userspace might as well probe things manually and act >> upon the -EINVAL. > > Adding the cap allows existing userspace to dtrt... 1. Move cursor off-screen. 2. Check desired cursor layout with set_cursor. 3. Pick real cursor, set it. Or 1. Use set_cursor on disabled crtc. Both aren't pretty, but that ugly should help to move cursors-as-real-planes forward ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 75900] [r600g-evergreen] GPU lockup or app segfault in several games (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=75900 --- Comment #14 from Wojciech Pyczak --- (In reply to comment #8) > (In reply to comment #6) > > I'm experiencing the same problems on my HD6850, currently upgrading to > > master to see if it helps, however unlike Benjamin case my card hanged when > > I watched some movie (vpdu backend), the other time I was viewing some web > > page - there was a (old, via wine) game running in the backround though. > > > > The crashes seemed completely random, no indication what might have caused > > it. I'll attach log file containing first hang (I had to do a hard reset, > > sysrq didn't work, on the second occasion sysrq did work but there was no > > info in the log file but I think I've waited long enough, strange). > > Please let me know after you test Mesa master. Thanks. With current master I'm no longer experiencing any hangs, I can't however guarantee it's the same problem, because I've no idea how to reproduce it. All I know is that the problem was introduced somewhere between 4-7.03, I guess I could cherry pick or "revert the revert" and see what happens but if I'm going to do that I might as well collect some additional information, just let me know what you're interesed in. -- 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/20140310/b234195d/attachment.html>
[Intel-gfx] [PATCH v3 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
On Mon, Mar 10, 2014 at 11:07 AM, Daniel Vetter wrote: > On Mon, Mar 10, 2014 at 11:04 AM, Chris Wilson > wrote: >>> > The cap exposes the max cursor size. Knowing our hardware we can infer >>> > that pot sizes from 64 to max are supported, but it would be better if >>> > we did expose that information through the cap as well. >>> >>> I think the right approach here is to expose this through the >>> cursor-as-real-plane interface, which kinda has this already. On top >>> of that we can then add a few fourcc enumerations of the fixed rgba >>> cursor layouts like 64x64, 128x128, ... This helps if the plane is a >>> general one with very high limits, but also with special support for >>> cursor formats. >>> >>> If anyone wants to go crazy we could then also add new fourccs for all >>> the other cursor layouts - atm only rgba with fixed dimensions can be >>> support with the current cursor ioctl. >>> >>> So reviewing the overall situation I actually _don't_ want a new >>> cap/ioctl/prop here just for now. As long as we need to go with intel >>> specific hacks userspace might as well probe things manually and act >>> upon the -EINVAL. >> >> Adding the cap allows existing userspace to dtrt... > > 1. Move cursor off-screen. > 2. Check desired cursor layout with set_cursor. > 3. Pick real cursor, set it. > > Or > > 1. Use set_cursor on disabled crtc. > > Both aren't pretty, but that ugly should help to move > cursors-as-real-planes forward ;-) I stand corrected, there's now a cursor size cap in the drm-next branch (which is included in -nightly), so we need support this and also make sure it works correctly in the igt. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v4 1/1] drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support
From: Sagar Kamble
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.
v4: Indentation related changes for setting cursor control and
implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT
Testcase: igt/kms_cursor_crc
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-kernel at vger.kernel.org
Signed-off-by: G, Pallavi
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_reg.h | 4 +++
drivers/gpu/drm/i915/intel_display.c | 53
drivers/gpu/drm/i915/intel_drv.h | 7 +
3 files changed, 59 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 146609a..aee8258 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3551,7 +3551,11 @@ enum punit_power_well {
/* New style CUR*CNTR flags */
#define CURSOR_MODE 0x27
#define CURSOR_MODE_DISABLE 0x00
+#define CURSOR_MODE_128_32B_AX 0x02
+#define CURSOR_MODE_256_32B_AX 0x03
#define CURSOR_MODE_64_32B_AX 0x07
+#define CURSOR_MODE_128_ARGB_AX ((1 << 5) | CURSOR_MODE_128_32B_AX)
+#define CURSOR_MODE_256_ARGB_AX ((1 << 5) | CURSOR_MODE_256_32B_AX)
#define CURSOR_MODE_64_ARGB_AX ((1 << 5) | CURSOR_MODE_64_32B_AX)
#define MCURSOR_PIPE_SELECT (1 << 28)
#define MCURSOR_PIPE_A 0x00
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0868afb..ec6a073 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7440,10 +7440,26 @@ static void i9xx_update_cursor(struct drm_crtc *crtc,
u32 base)
bool visible = base != 0;
if (intel_crtc->cursor_visible != visible) {
+ int16_t width = intel_crtc->cursor_width;
uint32_t cntl = I915_READ(CURCNTR(pipe));
if (base) {
cntl &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT);
- cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+ cntl |= MCURSOR_GAMMA_ENABLE;
+
+ switch (width) {
+ case 64:
+ cntl |= CURSOR_MODE_64_ARGB_AX;
+ break;
+ case 128:
+ cntl |= CURSOR_MODE_128_ARGB_AX;
+ break;
+ case 256:
+ cntl |= CURSOR_MODE_256_ARGB_AX;
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
cntl |= pipe << 28; /* Connect to correct pipe */
} else {
cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
@@ -7468,10 +7484,25 @@ static void ivb_update_cursor(struct drm_crtc *crtc,
u32 base)
bool visible = base != 0;
if (intel_crtc->cursor_visible != visible) {
+ int16_t width = intel_crtc->cursor_width;
uint32_t cntl = I915_READ(CURCNTR_IVB(pipe));
if (base) {
cntl &= ~CURSOR_MODE;
- cntl |= CURSOR_MODE_64_ARGB_AX | MCURSOR_GAMMA_ENABLE;
+ cntl |= MCURSOR_GAMMA_ENABLE;
+ switch (width) {
+ case 64:
+ cntl |= CURSOR_MODE_64_ARGB_AX;
+ break;
+ case 128:
+ cntl |= CURSOR_MODE_128_ARGB_AX;
+ break;
+ case 256:
+ cntl |= CURSOR_MODE_256_ARGB_AX;
+ break;
+ default:
+ WARN_ON(1);
+ return;
+ }
} else {
cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE);
cntl |= CURSOR_MODE_DISABLE;
@@ -7567,9 +7598,11 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
goto finish;
}
- /* Currently we only support 64x64 cursors */
- if (width != 64 || height != 64) {
- DRM_ERROR("we currently only support 64x64 cursors\n");
+ /* Check for which cursor types we support */
+ if (!((width == 64 && height == 64) ||
+ (width == 128 && height == 128 && !IS_GEN2(dev)) ||
+ (width == 256 && height == 256 && !IS_GEN2(dev {
+ DRM_DEBUG("Cursor dimension not supported\n");
return -EINVAL;
}
@@ -10331,6 +10364,16 @@ static void intel
[Bug 75900] [r600g-evergreen] GPU lockup or app segfault in several games (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=75900 --- Comment #15 from Marek Ol??k --- (In reply to comment #14) > With current master I'm no longer experiencing any hangs, I can't however > guarantee it's the same problem, because I've no idea how to reproduce it. > > All I know is that the problem was introduced somewhere between 4-7.03, I > guess I could cherry pick or "revert the revert" and see what happens but if > I'm going to do that I might as well collect some additional information, > just let me know what you're interesed in. I just wanted to know if you were still seeing any hangs, and you weren't, which is great. -- 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/20140310/01735823/attachment.html>
[RFC PATCH] drm/dp: let drivers specify the name of the I2C-over-AUX adapter
On Wed, Mar 05, 2014 at 01:50:27PM +0200, Jani Nikula wrote:
[...]
> I am not entirely happy with adding an extra name field, but I also
> didn't like the caller having to set up aux.ddc.name in advance. Ideas
> welcome.
What you propose is a whole lot better than having to modify the
internals of struct i2c_adapter in advance, and I can't think of
a better alternative either. I have two small comments below.
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 35251af3b14e..17832d048147 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -726,7 +726,8 @@ int drm_dp_aux_register_i2c_bus(struct drm_dp_aux *aux)
> aux->ddc.dev.parent = aux->dev;
> aux->ddc.dev.of_node = aux->dev->of_node;
>
> - strncpy(aux->ddc.name, dev_name(aux->dev), sizeof(aux->ddc.name));
> + strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
> + sizeof(aux->ddc.name));
I don't see why the change from strncpy() to strlcpy() would be
necessary.
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
[...]
> @@ -438,6 +438,9 @@ struct drm_dp_aux_msg {
> * The .dev field should be set to a pointer to the device that implements
> * the AUX channel.
> *
> + * The .name field may be used to specify the name of the I2C adapter. If
> set to
> + * NULL, dev_name() of .dev will be used.
> + *
Nit: That new paragraph sticks out because it's wider than the rest,
even though it still fits into 80 characters.
I don't feel all that strongly about either of the above, so:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140310/5efd4c66/attachment.pgp>
[RFC PATCH] drm/dp: let drivers specify the name of the I2C-over-AUX adapter
On Mon, 10 Mar 2014, Thierry Reding wrote:
> On Wed, Mar 05, 2014 at 01:50:27PM +0200, Jani Nikula wrote:
> [...]
>> I am not entirely happy with adding an extra name field, but I also
>> didn't like the caller having to set up aux.ddc.name in advance. Ideas
>> welcome.
>
> What you propose is a whole lot better than having to modify the
> internals of struct i2c_adapter in advance, and I can't think of
> a better alternative either. I have two small comments below.
>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 35251af3b14e..17832d048147 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -726,7 +726,8 @@ int drm_dp_aux_register_i2c_bus(struct drm_dp_aux *aux)
>> aux->ddc.dev.parent = aux->dev;
>> aux->ddc.dev.of_node = aux->dev->of_node;
>>
>> -strncpy(aux->ddc.name, dev_name(aux->dev), sizeof(aux->ddc.name));
>> +strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
>> +sizeof(aux->ddc.name));
>
> I don't see why the change from strncpy() to strlcpy() would be
> necessary.
To always null terminate aux->ddc.name.
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> [...]
>> @@ -438,6 +438,9 @@ struct drm_dp_aux_msg {
>> * The .dev field should be set to a pointer to the device that implements
>> * the AUX channel.
>> *
>> + * The .name field may be used to specify the name of the I2C adapter. If
>> set to
>> + * NULL, dev_name() of .dev will be used.
>> + *
>
> Nit: That new paragraph sticks out because it's wider than the rest,
> even though it still fits into 80 characters.
It seems emacs isn't (yet!) clever enough to reflow with the same
fill-column as the neighbouring paragraphs. ;)
> I don't feel all that strongly about either of the above, so:
>
> Reviewed-by: Thierry Reding
Thanks for the review,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v5 1/1] Documentation: drm: describing drm properties exposed by various drivers
Hi Sagar,
Thank you for the patch, it's really appreciated.
On Saturday 08 March 2014 12:58:43 sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> Started documenting drm properties for drm drivers. This patch provides
> information about properties in drm, i915, psb and cdv/gma-500. Information
> about other properties can be added on top of these.
>
> v2: Added description of drm properties in armada, exynos, i2c/ch7006,
> noveau, omap, qxl, radeon, rcar-du
>
> v3: Removed "Property Object" column since it is implementation related.
> Property type column refined.[Ville's review comments]
>
> v4: Removed whitespace warnings and minor nits.
>
> v5: Restructured output for ENUM properties
Some of my concerns have already been addressed. I just have two more small
comments, please see below.
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Herrmann
> Cc: Alex Deucher
> Cc: "Ville Syrj?l?"
> Cc: Sagar Kamble
> Cc: "Purushothaman, Vijay A"
> Cc: linux-doc at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
>
> Signed-off-by: Sagar Kamble
> ---
> Documentation/DocBook/drm.tmpl | 846 ++
> 1 file changed, 846 insertions(+)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index ed1d6d2..5650d13 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2317,6 +2317,852 @@ void intel_crt_init(struct drm_device *dev)
>pointer to the target object, a pointer to the previously created
> property and an initial instance value.
>
I would put the following in a to make it more readable.
> +
> + The following table gives description of drm properties exposed by
> various
> + modules/drivers.
> +
> +
Any particular reason for the space before the '>' ?
> +
> +
> +Owner Module/Drivers
> +Group
> +Property Name
> +Type
> +Property Values
> +Object attached
> +Description/Restrictions
> +
> +
> +DRM
> +Generic
> +?EDID?
> +BLOB | IMMUTABLE
> +0
> +Connector
> +Contains id of edid blob ptr object.
> +
> +
> +?DPMS?
> +ENUM
> +{ ?On?, ?Standby?, ?Suspend?, ?Off? }
> +Connector
> +Contains DPMS operation mode value.
> +
> +
> +DVI-I
> +?subconnector?
> +ENUM
> +{ ?Unknown?, ?DVI-D?, ?DVI-A? }
> +Connector
> +TBD
> +
> +
> +?select subconnector?
> +ENUM
> +{ ?Automatic?, ?DVI-D?, ?DVI-A? }
> +Connector
> +TBD
> +
> +
> +TV
> +?subconnector?
> +ENUM
> +{ "Unknown", "Composite", "SVIDEO", "Component", "SCART"
> } +Connector
> +TBD
> +
> +
> +?select subconnector?
> +ENUM
> +{ "Automatic", "Composite", "SVIDEO", "Component",
> "SCART" } +Connector
> +TBD
> +
> +
> +?mode?
> +ENUM
> +{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.
> +Connector
> +TBD
> +
> +
> +?left margin?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?right margin?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?top margin?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?bottom margin?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?brightness?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?contrast?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?flicker reduction?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?overscan?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?saturation?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +?hue?
> +RANGE
> +Min=0, Max=100
> +Connector
> +TBD
> +
> +
> +Optional
> +?scaling mode?
> +ENUM
> +{ "None", "Full", "Center", "Full aspect" }
> +Connector
> +TBD
> +
> +
> +?dirty?
> +ENUM | IMMUTABLE
> +{ "Off", "On", "Annotate" }
> +Connector
> +TBD
> +
> +
> +i915
> +Generic
> +"Broadcast RGB"
> +ENUM
> +{ "Automatic", "Full", "Limited 16:235" }
> +Connector
> +TBD
> +
> +
> +?audio?
> +ENUM
> +{ "force-dvi", "off", "auto", "on" }
> +Connector
> +TBD
> +
> +
> +Standard name as in DRM
> +Standard type as in DRM
> +Standard value as in DRM
> +Standard Object as in DRM
> +TBD
> +
> +
> +SDVO-TV
> +?mode?
> +ENUM
> +{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.
> +Connector
> +TBD
> +
> +
> +"left_margin"
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +"right_margin"
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +"top_margin"
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +"bottom_margin"
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?hpos?
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?vpos?
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?contrast?
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?saturation?
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?hue?
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?sharpness?
> +RANGE
> +Min=0, Max= SDVO dependent
> +Connector
> +TBD
> +
> +
> +?flicker_filter?
> +RANGE
>
[PATCH 4/4] Documentation: drm: describing plane alpha and color blending property
Hi Sagar,
Thank you for the patch.
On Saturday 08 March 2014 13:51:19 sagar.a.kamble at intel.com wrote:
> From: Sagar Kamble
>
> Cc: Rob Landley
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Laurent Pinchart
> Cc: David Herrmann
> Cc: Alex Deucher
> Cc: "Ville Syrj?l?"
> Cc: Sagar Kamble
> Cc: "Purushothaman, Vijay A"
> Cc: linux-doc at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Sagar Kamble
> ---
> Documentation/DocBook/drm.tmpl | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 5650d13..ba260e8 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -2334,7 +2334,7 @@ void intel_crt_init(struct drm_device *dev)
>
>
> DRM
> -Generic
> +Generic
> ?EDID?
> BLOB | IMMUTABLE
> 0
> @@ -2349,6 +2349,17 @@ void intel_crt_init(struct drm_device *dev)
> Contains DPMS operation mode value.
>
>
> +?blend?
> +BITMASK
> +{ {0, "none"}, {1, "zero"}, {2, "one"}, {3, "src-color"},
> {4, "one-minus-src-color"} +, {5, "dst-color"}, {6, "one-minus-dst-color"},
> {7, "src-alpha"}, {8, "one-minus-src-alpha"}, {9, "dst-alpha"} +, {10,
> "one-minus-dst-alpha"}, {11, "constant-color"}, {12,
> "one-minus-constant-color"}, {13, "constant-alpha"} +, {14,
> "one-minus-constant-alpha"}, {15, "alpha-saturate"}, {16, "src1-color"},
> {17, "one-minus-src1-color"} +, {18, "src1-alpha"}, {19,
> "one-minus-src1-alpha"}, {20, "pre-multiplied-alpha"} } + valign="top" >Plane
> +Contains plane alpha/color blending operation value.
I believe this calls for a description of each property value. From patches
1/4 and 4/4 it's not entirely clear to me what all values mean.
> +
> +
> DVI-I
> ?subconnector?
> ENUM
--
Regards,
Laurent Pinchart
[RFCv2 06/10] drm: Specify primary plane at CRTC initialization
On Sun, Mar 09, 2014 at 05:12:31PM -0400, Rob Clark wrote:
> On Fri, Mar 7, 2014 at 7:03 PM, Matt Roper
> wrote:
> > Add primary plane as a parameter to drm_crtc_init() and update all
> > existing DRM drivers to use a helper-provided primary plane.
> >
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/armada/armada_crtc.c | 4 +++-
> > drivers/gpu/drm/ast/ast_mode.c | 4 +++-
> > drivers/gpu/drm/bochs/bochs_kms.c | 4 +++-
> > drivers/gpu/drm/cirrus/cirrus_mode.c | 4 +++-
> > drivers/gpu/drm/drm_crtc.c | 8 +++-
> > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
> > drivers/gpu/drm/gma500/psb_intel_display.c | 4 +++-
> > drivers/gpu/drm/i915/intel_display.c | 4 +++-
> > drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +++-
> > drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 4 +++-
> > drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 4 +++-
> > drivers/gpu/drm/nouveau/dispnv04/crtc.c| 4 +++-
> > drivers/gpu/drm/nouveau/nv50_display.c | 4 +++-
> > drivers/gpu/drm/omapdrm/omap_crtc.c| 4 +++-
> > drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
> > drivers/gpu/drm/radeon/radeon_display.c| 4 +++-
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 +++-
> > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 ++-
> > drivers/gpu/drm/tegra/dc.c | 4 +++-
> > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++-
> > drivers/gpu/drm/udl/udl_modeset.c | 4 +++-
> > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 4 +++-
> > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +++-
> > drivers/staging/imx-drm/imx-drm-core.c | 4 +++-
> > include/drm/drm_crtc.h | 4
> > 25 files changed, 79 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> > b/drivers/gpu/drm/armada/armada_crtc.c
> > index d8e3982..0a14d24 100644
> > --- a/drivers/gpu/drm/armada/armada_crtc.c
> > +++ b/drivers/gpu/drm/armada/armada_crtc.c
> > @@ -1030,6 +1030,7 @@ int armada_drm_crtc_create(struct drm_device *dev,
> > unsigned num,
> > {
> > struct armada_private *priv = dev->dev_private;
> > struct armada_crtc *dcrtc;
> > + struct drm_plane *primary;
> > void __iomem *base;
> > int ret;
> >
> > @@ -1086,7 +1087,8 @@ int armada_drm_crtc_create(struct drm_device *dev,
> > unsigned num,
> >
> > priv->dcrtc[dcrtc->num] = dcrtc;
> >
> > - drm_crtc_init(dev, &dcrtc->crtc, &armada_crtc_funcs);
> > + primary = drm_primary_helper_create_plane(dev);
> > + drm_crtc_init(dev, &dcrtc->crtc, primary, &armada_crtc_funcs);
> > drm_crtc_helper_add(&dcrtc->crtc, &armada_crtc_helper_funcs);
> >
> > drm_object_attach_property(&dcrtc->crtc.base, priv->csc_yuv_prop,
> > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> > index cca063b..44f0d32 100644
> > --- a/drivers/gpu/drm/ast/ast_mode.c
> > +++ b/drivers/gpu/drm/ast/ast_mode.c
> > @@ -626,13 +626,15 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
> > static int ast_crtc_init(struct drm_device *dev)
> > {
> > struct ast_crtc *crtc;
> > + struct drm_plane *primary;
> > int i;
> >
> > crtc = kzalloc(sizeof(struct ast_crtc), GFP_KERNEL);
> > if (!crtc)
> > return -ENOMEM;
> >
> > - drm_crtc_init(dev, &crtc->base, &ast_crtc_funcs);
> > + primary = drm_primary_helper_create_plane(dev);
> > + drm_crtc_init(dev, &crtc->base, primary, &ast_crtc_funcs);
> > drm_mode_crtc_set_gamma_size(&crtc->base, 256);
> > drm_crtc_helper_add(&crtc->base, &ast_crtc_helper_funcs);
> >
> > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> > b/drivers/gpu/drm/bochs/bochs_kms.c
> > index 62ec7d4..182f5c9 100644
> > --- a/drivers/gpu/drm/bochs/bochs_kms.c
> > +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> > @@ -129,8 +129,10 @@ static void bochs_crtc_init(struct drm_device *dev)
> > {
> > struct bochs_device *bochs = dev->dev_private;
> > struct drm_crtc *crtc = &bochs->crtc;
> > + struct drm_plane *primary;
> >
> > - drm_crtc_init(dev, crtc, &bochs_crtc_funcs);
> > + primary = drm_primary_helper_create_plane(dev);
> > + drm_crtc_init(dev, crtc, primary, &bochs_crtc_funcs);
> > drm_mode_crtc_set_gamma_size(crtc, 256);
> > drm_crtc_helper_add(crtc, &bochs_helper_funcs);
> > }
> > diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
> > b/drivers/gpu/drm/cirrus/cirrus_mode.c
> > index 530f78f..449246f 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> > @@ -381,6 +381,7 @@ static void cirrus_crtc_init(struct drm_device *dev)
> > {
> > struct cirrus_device *cdev = dev->dev_private;
> > struct cirrus_crtc *cirrus_crtc;
> > + struct drm_plane *primary;
> > int i;
> >
> > cirrus_crtc = kzalloc(sizeof(struct cirrus_crtc) +
> >
[RFCv2 06/10] drm: Specify primary plane at CRTC initialization
On Mon, Mar 10, 2014 at 10:54 AM, Matt Roper
wrote:
> On Sun, Mar 09, 2014 at 05:12:31PM -0400, Rob Clark wrote:
>> On Fri, Mar 7, 2014 at 7:03 PM, Matt Roper
>> wrote:
>> > Add primary plane as a parameter to drm_crtc_init() and update all
>> > existing DRM drivers to use a helper-provided primary plane.
>> >
>> > Signed-off-by: Matt Roper
>> > ---
[snip]
>> > diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > index 84c5b13..372670e 100644
>> > --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > @@ -753,6 +753,7 @@ struct drm_crtc *mdp4_crtc_init(struct drm_device *dev,
>> > enum mdp4_dma dma_id)
>> > {
>> > struct drm_crtc *crtc = NULL;
>> > + struct drm_plane *primary;
>> > struct mdp4_crtc *mdp4_crtc;
>> > int ret;
>> >
>> > @@ -791,7 +792,8 @@ struct drm_crtc *mdp4_crtc_init(struct drm_device *dev,
>> >
>> > INIT_FENCE_CB(&mdp4_crtc->pageflip_cb, pageflip_cb);
>> >
>> > - drm_crtc_init(dev, crtc, &mdp4_crtc_funcs);
>> > + primary = drm_primary_helper_create_plane(dev);
>> > + drm_crtc_init(dev, crtc, primary, &mdp4_crtc_funcs);
>>
>> note that msm, omap, and iirc exynos (and maybe even some others)
>> already have their own private (now primary) planes. I suspect they
>> should be using their existing plane, rather than creating a helper
>> plane.
>>
>> BR,
>> -R
>
> Yep, agreed. This is one of the items I called out as a TODO in the
> patch set cover letter. I just haven't had enough time to look at those
> drivers in detail yet to figure out how they work. Right now I believe
> they all register the same set of plane handler functions at
> drm_plane_init() that they do for their other overlay planes; I need to
> figure out whether those handler functions will actually operate
> properly on the private/primary planes, or whether the drivers were
> previously just assuming that the handlers would never get called on
> private planes and something different is needed.
>
ahh, I should have paid more attention to your cover letter. Well,
omapdrm and msm are safe to convert (same set of plane handler fxns).
I'll update and test msm when I rebase atomic, so their will be a
patch that you can squash back in for that one.
BR,
-R
>
> Matt
>
[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #25 from Johan Brannlund --- The bug is still there with kernel 3.14-rc6 - the display doesn't get enabled on resume. But now the logs (attached) don't contain any obvious failures. -- 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/20140310/fa9e073a/attachment.html>
[Bug 42162] [r600g][kms] Display not enabled on resume (HP DV6)
https://bugs.freedesktop.org/show_bug.cgi?id=42162 --- Comment #26 from Johan Brannlund --- Created attachment 95513 --> https://bugs.freedesktop.org/attachment.cgi?id=95513&action=edit 3.14-rc6 suspend/resume 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/20140310/b393ac3d/attachment.html>
[BUG] 3.14-rc6 problems with an R7 260X
On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > Hi, > > I recently added a R7 260X to my system. While the card works with 3.13 its > supposed work much better with 14-rc. > This is not the case. My system is unstable without radeon.dpm=0 which was > the default in .13. Here are some extracts > from the logs of the latest fun with dpm enabled: > > with 3.14-rc6 (with an up to date arch, stable X and mesa-git (10.2) mesa > 10.1 and 10.0 also show very similar problems. > > Mar 10 10:45:04 localhost kernel: [0.00] Command line: > BOOT_IMAGE=/vmlinuz-linux-mainline root=/dev/sda3 ro console=tty0 verbose > > Mar 10 10:45:04 localhost kernel: [3.258402] [drm] radeon kernel > modesetting enabled. > Mar 10 10:45:04 localhost kernel: [3.258421] checking generic (e000 > 30) vs hw (e000 1000) > Mar 10 10:45:04 localhost kernel: [3.258422] fb: conflicting fb hw usage > radeondrmfb vs VESA VGA - removing generic driver > Mar 10 10:45:04 localhost kernel: [3.270529] Console: switching to colour > dummy device 80x25 > Mar 10 10:45:04 localhost kernel: [3.270757] [drm] initializing kernel > modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253). > Mar 10 10:45:04 localhost kernel: [3.270781] [drm] register mmio base: > 0xF080 > Mar 10 10:45:04 localhost kernel: [3.270782] [drm] register mmio size: > 262144 > Mar 10 10:45:04 localhost kernel: [3.270785] [drm] doorbell mmio base: > 0xF000 > Mar 10 10:45:04 localhost kernel: [3.270786] [drm] doorbell mmio size: > 8388608 > Mar 10 10:45:04 localhost kernel: [3.270837] ATOM BIOS: Bonaire > Mar 10 10:45:04 localhost kernel: [3.270884] radeon :01:00.0: VRAM: > 2048M 0x - 0x7FFF (2048M used) > Mar 10 10:45:04 localhost kernel: [3.270884] radeon :01:00.0: GTT: > 1024M 0x8000 - 0xBFFF > Mar 10 10:45:04 localhost kernel: [3.270885] [drm] Detected VRAM > RAM=2048M, BAR=256M > Mar 10 10:45:04 localhost kernel: [3.270886] [drm] RAM width 128bits DDR > Mar 10 10:45:04 localhost kernel: [3.270925] [TTM] Zone kernel: > Available graphics memory: 8145248 kiB > Mar 10 10:45:04 localhost kernel: [3.270926] [TTM] Zone dma32: > Available graphics memory: 2097152 kiB > Mar 10 10:45:04 localhost kernel: [3.270927] [TTM] Initializing pool > allocator > Mar 10 10:45:04 localhost kernel: [3.270929] [TTM] Initializing DMA pool > allocator > Mar 10 10:45:04 localhost kernel: [3.270940] [drm] radeon: 2048M of VRAM > memory ready > Mar 10 10:45:04 localhost kernel: [3.270940] [drm] radeon: 1024M of GTT > memory ready. > Mar 10 10:45:04 localhost kernel: [3.270948] [drm] Loading BONAIRE > Microcode > Mar 10 10:45:04 localhost kernel: [3.276841] nct6775: Found NCT6776D/F or > compatible chip at 0x2e:0x290 > Mar 10 10:45:04 localhost kernel: [3.280263] [drm] Internal thermal > controller with fan control > Mar 10 10:45:04 localhost kernel: [3.280294] [drm] probing gen 2 caps for > device 8086:c01 = 261ad03/e > Mar 10 10:45:04 localhost kernel: [3.286710] [drm] radeon: dpm initialized > Mar 10 10:45:04 localhost kernel: [3.288706] [drm] GART: num cpu pages > 262144, num gpu pages 262144 > Mar 10 10:45:04 localhost kernel: [3.289112] [drm] probing gen 2 caps for > device 8086:c01 = 261ad03/e > Mar 10 10:45:04 localhost kernel: [3.289114] [drm] PCIE gen 3 link speeds > already enabled > Mar 10 10:45:04 localhost kernel: [3.299762] [drm] PCIE GART of 1024M > enabled (table at 0x00277000). > > from xorg's log > > [55.320] (II) RADEON(0): Creating default Display subsection in Screen > section > "Default Screen Section" for depth/fbbpp 24/32 > [55.320] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 > [55.320] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp > pixmaps) > [55.320] (==) RADEON(0): Default visual is TrueColor > [55.320] (==) RADEON(0): RGB weight 888 > [55.320] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) > [55.320] (--) RADEON(0): Chipset: "BONAIRE" (ChipID = 0x6658) > [55.320] (II) Loading sub module "dri2" > [55.320] (II) LoadModule: "dri2" > [55.320] (II) Module "dri2" already built-in > [55.320] (II) Loading sub module "glamoregl" > [55.320] (II) LoadModule: "glamoregl" > [55.320] (II) Loading /usr/lib/xorg/modules/libglamoregl.so > [55.320] (II) Module glamoregl: vendor="X.Org Foundation" > [55.320]compiled for 1.15.0, module version = 0.6.0 > [55.320]ABI class: X.Org ANSI C Emulation, version 0.4 > [55.320] (II) glamor: OpenGL accelerated X.org driver based. > [55.832] (II) glamor: EGL version 1.4 (DRI2): > [55.845] (II) RADEON(0): glamor detected, initialising EGL layer. > [55.845] (II) RADEON(0): KMS Color Tiling: disabled > [55.845] (II) RADEON(0): KMS Color Tiling 2D: disabled > [55.845] (II) RADEON(0): KMS Pa
[PATCH 0/7] drm/msm: what's in store for 3.15
An early look at what I have lined up for 3.15. Main highlights are: * HDMI audio support (sans interface to ALSA which needs to be invented) * Basic GPU power management * Add chip-id param, so userspace can know the GPU patch revision level (which gallium driver needs in a couple places) * Convert over to use new componentised device support and get rid of global pdev ptrs Rob Clark (7): drm/msm: hdmi audio support drm/msm: add hang_debug module param drm/msm: spin helper drm/msm: crank down gpu when inactive drm/msm: add chip-id param drm/msm: use componentised device support drm/msm: validate flags, etc drivers/gpu/drm/msm/Makefile| 1 + drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 104 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 65 +--- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 16 +- drivers/gpu/drm/msm/hdmi/hdmi.c | 49 -- drivers/gpu/drm/msm/hdmi/hdmi.h | 25 +++ drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 273 drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 26 ++- drivers/gpu/drm/msm/msm_drv.c | 160 ++- drivers/gpu/drm/msm/msm_drv.h | 4 + drivers/gpu/drm/msm/msm_gem_submit.c| 15 +- drivers/gpu/drm/msm/msm_gpu.c | 85 +- drivers/gpu/drm/msm/msm_gpu.h | 16 +- include/uapi/drm/msm_drm.h | 12 ++ 14 files changed, 759 insertions(+), 92 deletions(-) create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_audio.c -- 1.8.5.3
[PATCH 1/7] drm/msm: hdmi audio support
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 8 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 25 +++
drivers/gpu/drm/msm/hdmi/hdmi_audio.c | 273 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 26 ++--
5 files changed, 317 insertions(+), 16 deletions(-)
create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_audio.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 4f977a5..5e1e6b0 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -7,6 +7,7 @@ msm-y := \
adreno/adreno_gpu.o \
adreno/a3xx_gpu.o \
hdmi/hdmi.o \
+ hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
hdmi/hdmi_connector.o \
hdmi/hdmi_i2c.o \
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 6f1588a..6048b6b 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -67,6 +67,8 @@ void hdmi_destroy(struct kref *kref)
if (hdmi->i2c)
hdmi_i2c_destroy(hdmi->i2c);
+ platform_set_drvdata(hdmi->pdev, NULL);
+
put_device(&hdmi->pdev->dev);
}
@@ -102,6 +104,8 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct
drm_encoder *encoder)
hdmi->config = config;
hdmi->encoder = encoder;
+ hdmi_audio_infoframe_init(&hdmi->audio.infoframe);
+
/* not sure about which phy maps to which msm.. probably I miss some */
if (config->phy_init)
hdmi->phy = config->phy_init(hdmi);
@@ -228,6 +232,8 @@ struct hdmi *hdmi_init(struct drm_device *dev, struct
drm_encoder *encoder)
priv->bridges[priv->num_bridges++] = hdmi->bridge;
priv->connectors[priv->num_connectors++] = hdmi->connector;
+ platform_set_drvdata(pdev, hdmi);
+
return hdmi;
fail:
@@ -305,7 +311,7 @@ static int hdmi_dev_probe(struct platform_device *pdev)
config.ddc_data_gpio = 71;
config.hpd_gpio = 72;
config.mux_en_gpio = -1;
- config.mux_sel_gpio = 13 + NR_GPIO_IRQS;
+ config.mux_sel_gpio = -1;
} else if (cpu_is_msm8960() || cpu_is_msm8960ab()) {
static const char *hpd_reg_names[] = {"8921_hdmi_mvs"};
config.phy_init = hdmi_phy_8960_init;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
index 41b29ad..9fafee6 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.h
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.h
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "msm_drv.h"
#include "hdmi.xml.h"
@@ -30,6 +31,12 @@
struct hdmi_phy;
struct hdmi_platform_config;
+struct hdmi_audio {
+ bool enabled;
+ struct hdmi_audio_infoframe infoframe;
+ int rate;
+};
+
struct hdmi {
struct kref refcount;
@@ -38,6 +45,13 @@ struct hdmi {
const struct hdmi_platform_config *config;
+ /* audio state: */
+ struct hdmi_audio audio;
+
+ /* video state: */
+ bool power_on;
+ unsigned long int pixclock;
+
void __iomem *mmio;
struct regulator *hpd_regs[2];
@@ -132,6 +146,17 @@ struct hdmi_phy *hdmi_phy_8x60_init(struct hdmi *hdmi);
struct hdmi_phy *hdmi_phy_8x74_init(struct hdmi *hdmi);
/*
+ * audio:
+ */
+
+int hdmi_audio_update(struct hdmi *hdmi);
+int hdmi_audio_info_setup(struct hdmi *hdmi, bool enabled,
+ uint32_t num_of_channels, uint32_t channel_allocation,
+ uint32_t level_shift, bool down_mix);
+void hdmi_audio_set_sample_rate(struct hdmi *hdmi, int rate);
+
+
+/*
* hdmi bridge:
*/
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
new file mode 100644
index 000..872485f
--- /dev/null
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_audio.c
@@ -0,0 +1,273 @@
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see
[PATCH 2/7] drm/msm: add hang_debug module param
msm.hang_debug=y will dump out current register values if the gpu locks
up, for easier debugging.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 34 -
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 1 +
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 461df93..8b6fb84 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -35,6 +35,12 @@
A3XX_INT0_CP_AHB_ERROR_HALT | \
A3XX_INT0_UCHE_OOB_ACCESS)
+
+static bool hang_debug = false;
+MODULE_PARM_DESC(hang_debug, "Dump registers when hang is detected (can be
slow!)");
+module_param_named(hang_debug, hang_debug, bool, 0600);
+static void a3xx_dump(struct msm_gpu *gpu);
+
static struct platform_device *a3xx_pdev;
static void a3xx_me_init(struct msm_gpu *gpu)
@@ -291,6 +297,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
static void a3xx_recover(struct msm_gpu *gpu)
{
+ /* dump registers before resetting gpu, if enabled: */
+ if (hang_debug)
+ a3xx_dump(gpu);
gpu_write(gpu, REG_A3XX_RBBM_SW_RESET_CMD, 1);
gpu_read(gpu, REG_A3XX_RBBM_SW_RESET_CMD);
gpu_write(gpu, REG_A3XX_RBBM_SW_RESET_CMD, 0);
@@ -352,7 +361,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
return IRQ_HANDLED;
}
-#ifdef CONFIG_DEBUG_FS
static const unsigned int a3xx_registers[] = {
0x, 0x0002, 0x0010, 0x0012, 0x0018, 0x0018, 0x0020, 0x0027,
0x0029, 0x002b, 0x002e, 0x0033, 0x0040, 0x0042, 0x0050, 0x005c,
@@ -392,6 +400,7 @@ static const unsigned int a3xx_registers[] = {
0x303c, 0x303c, 0x305e, 0x305f,
};
+#ifdef CONFIG_DEBUG_FS
static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
{
int i;
@@ -415,6 +424,29 @@ static void a3xx_show(struct msm_gpu *gpu, struct seq_file
*m)
}
#endif
+/* would be nice to not have to duplicate the _show() stuff with printk(): */
+static void a3xx_dump(struct msm_gpu *gpu)
+{
+ int i;
+
+ adreno_dump(gpu);
+ printk("status: %08x\n",
+ gpu_read(gpu, REG_A3XX_RBBM_STATUS));
+
+ /* dump these out in a form that can be parsed by demsm: */
+ printk("IO:region %s 0002\n", gpu->name);
+ for (i = 0; i < ARRAY_SIZE(a3xx_registers); i += 2) {
+ uint32_t start = a3xx_registers[i];
+ uint32_t end = a3xx_registers[i+1];
+ uint32_t addr;
+
+ for (addr = start; addr <= end; addr++) {
+ uint32_t val = gpu_read(gpu, addr);
+ printk("IO:R %08x %08x\n", addr<<2, val);
+ }
+ }
+}
+
static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index d321099..cf6eb97 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -260,6 +260,24 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
}
#endif
+/* would be nice to not have to duplicate the _show() stuff with printk(): */
+void adreno_dump(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+
+ printk("revision: %d (%d.%d.%d.%d)\n",
+ adreno_gpu->info->revn, adreno_gpu->rev.core,
+ adreno_gpu->rev.major, adreno_gpu->rev.minor,
+ adreno_gpu->rev.patchid);
+
+ printk("fence:%d/%d\n", adreno_gpu->memptrs->fence,
+ gpu->submitted_fence);
+ printk("rptr: %d\n", adreno_gpu->memptrs->rptr);
+ printk("wptr: %d\n", adreno_gpu->memptrs->wptr);
+ printk("rb wptr: %d\n", get_wptr(gpu->rb));
+
+}
+
void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index ca11ea4..e16200d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -114,6 +114,7 @@ void adreno_idle(struct msm_gpu *gpu);
#ifdef CONFIG_DEBUG_FS
void adreno_show(struct msm_gpu *gpu, struct seq_file *m);
#endif
+void adreno_dump(struct msm_gpu *gpu);
void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords);
int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
--
1.8.5.3
[PATCH 3/7] drm/msm: spin helper
Helper macro to simplify places where we need to poll with timeout
waiting for gpu.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 14 +++
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 15 +++-
3 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 8b6fb84..59ed762 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -326,21 +326,13 @@ static void a3xx_destroy(struct msm_gpu *gpu)
static void a3xx_idle(struct msm_gpu *gpu)
{
- unsigned long t;
-
/* wait for ringbuffer to drain: */
adreno_idle(gpu);
- t = jiffies + ADRENO_IDLE_TIMEOUT;
-
/* then wait for GPU to finish: */
- do {
- uint32_t rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
- if (!(rbbm_status & A3XX_RBBM_STATUS_GPU_BUSY))
- return;
- } while(time_before(jiffies, t));
-
- DRM_ERROR("timeout waiting for %s to idle!\n", gpu->name);
+ if (spin_until(!(gpu_read(gpu, REG_A3XX_RBBM_STATUS) &
+ A3XX_RBBM_STATUS_GPU_BUSY)))
+ DRM_ERROR("%s: timeout waiting for GPU to idle!\n", gpu->name);
/* TODO maybe we need to reset GPU here to recover from hang? */
}
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index cf6eb97..7a11563 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -225,19 +225,11 @@ void adreno_flush(struct msm_gpu *gpu)
void adreno_idle(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- uint32_t rptr, wptr = get_wptr(gpu->rb);
- unsigned long t;
-
- t = jiffies + ADRENO_IDLE_TIMEOUT;
-
- /* then wait for CP to drain ringbuffer: */
- do {
- rptr = adreno_gpu->memptrs->rptr;
- if (rptr == wptr)
- return;
- } while(time_before(jiffies, t));
+ uint32_t wptr = get_wptr(gpu->rb);
- DRM_ERROR("%s: timeout waiting to drain ringbuffer!\n", gpu->name);
+ /* wait for CP to drain ringbuffer: */
+ if (spin_until(adreno_gpu->memptrs->rptr == wptr))
+ DRM_ERROR("%s: timeout waiting to drain ringbuffer!\n",
gpu->name);
/* TODO maybe we need to reset GPU here to recover from hang? */
}
@@ -278,22 +270,19 @@ void adreno_dump(struct msm_gpu *gpu)
}
-void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords)
+static uint32_t ring_freewords(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- uint32_t freedwords;
- unsigned long t = jiffies + ADRENO_IDLE_TIMEOUT;
- do {
- uint32_t size = gpu->rb->size / 4;
- uint32_t wptr = get_wptr(gpu->rb);
- uint32_t rptr = adreno_gpu->memptrs->rptr;
- freedwords = (rptr + (size - 1) - wptr) % size;
-
- if (time_after(jiffies, t)) {
- DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
gpu->name);
- break;
- }
- } while(freedwords < ndwords);
+ uint32_t size = gpu->rb->size / 4;
+ uint32_t wptr = get_wptr(gpu->rb);
+ uint32_t rptr = adreno_gpu->memptrs->rptr;
+ return (rptr + (size - 1) - wptr) % size;
+}
+
+void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords)
+{
+ if (spin_until(ring_freewords(gpu) >= ndwords))
+ DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
gpu->name);
}
static const char *iommu_ports[] = {
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index e16200d..63c36ce 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -76,7 +76,20 @@ struct adreno_platform_config {
#endif
};
-#define ADRENO_IDLE_TIMEOUT (20 * 1000)
+#define ADRENO_IDLE_TIMEOUT msecs_to_jiffies(1000)
+
+#define spin_until(X) ({ \
+ int __ret = -ETIMEDOUT;\
+ unsigned long __t = jiffies + ADRENO_IDLE_TIMEOUT; \
+ do { \
+ if (X) { \
+ __ret = 0; \
+ break; \
+ } \
+ } while (time_before(jiffies, __t)); \
+ __ret; \
+})
+
static inline bool adreno_is_a3xx(struct adreno_gpu *gpu)
{
--
1.8.5.3
[PATCH 4/7] drm/msm: crank down gpu when inactive
Shut down the clks when the gpu has nothing to do. A short inactivity
timer is used to provide a low pass filter for power transitions.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 +
drivers/gpu/drm/msm/msm_drv.c | 7 ++-
drivers/gpu/drm/msm/msm_gpu.c | 85 +--
drivers/gpu/drm/msm/msm_gpu.h | 16 ++-
4 files changed, 113 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 59ed762..e6cb2bc 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -395,9 +395,15 @@ static const unsigned int a3xx_registers[] = {
#ifdef CONFIG_DEBUG_FS
static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
{
+ struct drm_device *dev = gpu->dev;
int i;
adreno_show(gpu, m);
+
+ mutex_lock(&dev->struct_mutex);
+
+ gpu->funcs->pm_resume(gpu);
+
seq_printf(m, "status: %08x\n",
gpu_read(gpu, REG_A3XX_RBBM_STATUS));
@@ -413,6 +419,10 @@ static void a3xx_show(struct msm_gpu *gpu, struct seq_file
*m)
seq_printf(m, "IO:R %08x %08x\n", addr<<2, val);
}
}
+
+ gpu->funcs->pm_suspend(gpu);
+
+ mutex_unlock(&dev->struct_mutex);
}
#endif
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index e6adafc..e913efa 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -311,7 +311,6 @@ static void load_gpu(struct drm_device *dev)
gpu = NULL;
/* not fatal */
}
- mutex_unlock(&dev->struct_mutex);
if (gpu) {
int ret;
@@ -321,10 +320,16 @@ static void load_gpu(struct drm_device *dev)
dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
gpu->funcs->destroy(gpu);
gpu = NULL;
+ } else {
+ /* give inactive pm a chance to kick in: */
+ msm_gpu_retire(gpu);
}
+
}
priv->gpu = gpu;
+
+ mutex_unlock(&dev->struct_mutex);
}
static int msm_open(struct drm_device *dev, struct drm_file *file)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 0cfe3f4..3e667ca 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -154,9 +154,18 @@ static int disable_axi(struct msm_gpu *gpu)
int msm_gpu_pm_resume(struct msm_gpu *gpu)
{
+ struct drm_device *dev = gpu->dev;
int ret;
- DBG("%s", gpu->name);
+ DBG("%s: active_cnt=%d", gpu->name, gpu->active_cnt);
+
+ WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+
+ if (gpu->active_cnt++ > 0)
+ return 0;
+
+ if (WARN_ON(gpu->active_cnt <= 0))
+ return -EINVAL;
ret = enable_pwrrail(gpu);
if (ret)
@@ -175,9 +184,18 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
int msm_gpu_pm_suspend(struct msm_gpu *gpu)
{
+ struct drm_device *dev = gpu->dev;
int ret;
- DBG("%s", gpu->name);
+ DBG("%s: active_cnt=%d", gpu->name, gpu->active_cnt);
+
+ WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+
+ if (--gpu->active_cnt > 0)
+ return 0;
+
+ if (WARN_ON(gpu->active_cnt < 0))
+ return -EINVAL;
ret = disable_axi(gpu);
if (ret)
@@ -195,6 +213,55 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
}
/*
+ * Inactivity detection (for suspend):
+ */
+
+static void inactive_worker(struct work_struct *work)
+{
+ struct msm_gpu *gpu = container_of(work, struct msm_gpu, inactive_work);
+ struct drm_device *dev = gpu->dev;
+
+ if (gpu->inactive)
+ return;
+
+ DBG("%s: inactive!\n", gpu->name);
+ mutex_lock(&dev->struct_mutex);
+ if (!(msm_gpu_active(gpu) || gpu->inactive)) {
+ disable_axi(gpu);
+ disable_clk(gpu);
+ gpu->inactive = true;
+ }
+ mutex_unlock(&dev->struct_mutex);
+}
+
+static void inactive_handler(unsigned long data)
+{
+ struct msm_gpu *gpu = (struct msm_gpu *)data;
+ struct msm_drm_private *priv = gpu->dev->dev_private;
+
+ queue_work(priv->wq, &gpu->inactive_work);
+}
+
+/* cancel inactive timer and make sure we are awake: */
+static void inactive_cancel(struct msm_gpu *gpu)
+{
+ DBG("%s", gpu->name);
+ del_timer(&gpu->inactive_timer);
+ if (gpu->inactive) {
+ enable_clk(gpu);
+ enable_axi(gpu);
+ gpu->inactive = false;
+ }
+}
+
+static void inactive_start(struct msm_gpu *gpu)
+{
+ DBG("%s", gpu->name);
+ mod_timer(&gpu->inactive_timer,
+ round_jiffies_up(jiffies + DRM_MSM_INACTIVE_JIFFIES));
+}
+
+/*
* Hangcheck detection for locked gpu:
*/
@@ -206,7
[PATCH 6/7] drm/msm: use componentised device support
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 48
drivers/gpu/drm/msm/hdmi/hdmi.c | 43 +++
drivers/gpu/drm/msm/msm_drv.c | 133 +-
drivers/gpu/drm/msm/msm_drv.h | 4 +
4 files changed, 197 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index e6cb2bc..913cf8a 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -41,8 +41,6 @@ MODULE_PARM_DESC(hang_debug, "Dump registers when hang is
detected (can be slow!
module_param_named(hang_debug, hang_debug, bool, 0600);
static void a3xx_dump(struct msm_gpu *gpu);
-static struct platform_device *a3xx_pdev;
-
static void a3xx_me_init(struct msm_gpu *gpu)
{
struct msm_ringbuffer *ring = gpu->rb;
@@ -320,7 +318,6 @@ static void a3xx_destroy(struct msm_gpu *gpu)
ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
#endif
- put_device(&a3xx_gpu->pdev->dev);
kfree(a3xx_gpu);
}
@@ -473,7 +470,8 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct a3xx_gpu *a3xx_gpu = NULL;
struct adreno_gpu *adreno_gpu;
struct msm_gpu *gpu;
- struct platform_device *pdev = a3xx_pdev;
+ struct msm_drm_private *priv = dev->dev_private;
+ struct platform_device *pdev = priv->gpu_pdev;
struct adreno_platform_config *config;
int ret;
@@ -494,7 +492,6 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
adreno_gpu = &a3xx_gpu->base;
gpu = &adreno_gpu->base;
- get_device(&pdev->dev);
a3xx_gpu->pdev = pdev;
gpu->fast_rate = config->fast_rate;
@@ -556,17 +553,24 @@ fail:
# include
#endif
-static int a3xx_probe(struct platform_device *pdev)
+static void set_gpu_pdev(struct drm_device *dev,
+ struct platform_device *pdev)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+ priv->gpu_pdev = pdev;
+}
+
+static int a3xx_bind(struct device *dev, struct device *master, void *data)
{
static struct adreno_platform_config config = {};
#ifdef CONFIG_OF
- struct device_node *child, *node = pdev->dev.of_node;
+ struct device_node *child, *node = dev->of_node;
u32 val;
int ret;
ret = of_property_read_u32(node, "qcom,chipid", &val);
if (ret) {
- dev_err(&pdev->dev, "could not find chipid: %d\n", ret);
+ dev_err(dev, "could not find chipid: %d\n", ret);
return ret;
}
@@ -582,7 +586,7 @@ static int a3xx_probe(struct platform_device *pdev)
for_each_child_of_node(child, pwrlvl) {
ret = of_property_read_u32(pwrlvl,
"qcom,gpu-freq", &val);
if (ret) {
- dev_err(&pdev->dev, "could not find
gpu-freq: %d\n", ret);
+ dev_err(dev, "could not find gpu-freq:
%d\n", ret);
return ret;
}
config.fast_rate = max(config.fast_rate, val);
@@ -592,12 +596,12 @@ static int a3xx_probe(struct platform_device *pdev)
}
if (!config.fast_rate) {
- dev_err(&pdev->dev, "could not find clk rates\n");
+ dev_err(dev, "could not find clk rates\n");
return -ENXIO;
}
#else
- struct kgsl_device_platform_data *pdata = pdev->dev.platform_data;
+ struct kgsl_device_platform_data *pdata = dev->platform_data;
uint32_t version = socinfo_get_version();
if (cpu_is_apq8064ab()) {
config.fast_rate = 45000;
@@ -643,14 +647,30 @@ static int a3xx_probe(struct platform_device *pdev)
config.bus_scale_table = pdata->bus_scale_table;
# endif
#endif
- pdev->dev.platform_data = &config;
- a3xx_pdev = pdev;
+ dev->platform_data = &config;
+ set_gpu_pdev(dev_get_drvdata(master), to_platform_device(dev));
return 0;
}
+static void a3xx_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ set_gpu_pdev(dev_get_drvdata(master), NULL);
+}
+
+static const struct component_ops a3xx_ops = {
+ .bind = a3xx_bind,
+ .unbind = a3xx_unbind,
+};
+
+static int a3xx_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &a3xx_ops);
+}
+
static int a3xx_remove(struct platform_device *pdev)
{
- a3xx_pdev = NULL;
+ component_del(&pdev->dev, &a3xx_ops);
return 0;
}
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 6048b6b..d855bcf 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -17,8 +17,6 @@
#include "hdmi.h"
-static struct platform_device *hdmi_pdev;
-
void hd
[PATCH 5/7] drm/msm: add chip-id param
Some of the w/a or different behavior of userspace blob driver seem to
be keyed to gpu patch revision, rather than gpu-id. So expose the full
chip-id to userspace so it can DTRT.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++
include/uapi/drm/msm_drm.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 7a11563..28ca8cd 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -73,6 +73,12 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
uint64_t *value)
case MSM_PARAM_GMEM_SIZE:
*value = adreno_gpu->gmem;
return 0;
+ case MSM_PARAM_CHIP_ID:
+ *value = adreno_gpu->rev.patchid |
+ (adreno_gpu->rev.minor << 8) |
+ (adreno_gpu->rev.major << 16) |
+ (adreno_gpu->rev.core << 24);
+ return 0;
default:
DBG("%s: invalid param: %u", gpu->name, param);
return -EINVAL;
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index d3c6207..bf91a78 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -50,6 +50,7 @@ struct drm_msm_timespec {
#define MSM_PARAM_GPU_ID 0x01
#define MSM_PARAM_GMEM_SIZE 0x02
+#define MSM_PARAM_CHIP_ID0x03
struct drm_msm_param {
uint32_t pipe; /* in, MSM_PIPE_x */
--
1.8.5.3
[PATCH 7/7] drm/msm: validate flags, etc
After reading a nice article on LWN[1], I went back and double checked
my handling of invalid-input checking. Turns out there were a couple
places I had missed.
Since the driver is fairly young, and the devices it supports are really
only just barely usable for basic stuff (serial console) with an
upstream kernel, I think we should fix this now and revert specific
parts of this patch later in the unlikely event that a regression is
reported.
[1] https://lwn.net/Articles/588444/
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c| 20 +++-
drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
include/uapi/drm/msm_drm.h | 11 +++
3 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9ffc275..eee8d37 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -664,6 +664,12 @@ static int msm_ioctl_gem_new(struct drm_device *dev, void
*data,
struct drm_file *file)
{
struct drm_msm_gem_new *args = data;
+
+ if (args->flags & ~MSM_BO_FLAGS) {
+ DRM_ERROR("invalid flags: %08x\n", args->flags);
+ return -EINVAL;
+ }
+
return msm_gem_new_handle(dev, file, args->size,
args->flags, &args->handle);
}
@@ -677,6 +683,11 @@ static int msm_ioctl_gem_cpu_prep(struct drm_device *dev,
void *data,
struct drm_gem_object *obj;
int ret;
+ if (args->op & ~MSM_PREP_FLAGS) {
+ DRM_ERROR("invalid op: %08x\n", args->op);
+ return -EINVAL;
+ }
+
obj = drm_gem_object_lookup(dev, file, args->handle);
if (!obj)
return -ENOENT;
@@ -731,7 +742,14 @@ static int msm_ioctl_wait_fence(struct drm_device *dev,
void *data,
struct drm_file *file)
{
struct drm_msm_wait_fence *args = data;
- return msm_wait_fence_interruptable(dev, args->fence,
&TS(args->timeout));
+
+ if (args->pad) {
+ DRM_ERROR("invalid pad: %08x\n", args->pad);
+ return -EINVAL;
+ }
+
+ return msm_wait_fence_interruptable(dev, args->fence,
+ &TS(args->timeout));
}
static const struct drm_ioctl_desc msm_ioctls[] = {
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 5423e91..1f1f4cf 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -23,7 +23,6 @@
* Cmdstream submission:
*/
-#define BO_INVALID_FLAGS ~(MSM_SUBMIT_BO_READ | MSM_SUBMIT_BO_WRITE)
/* make sure these don't conflict w/ MSM_SUBMIT_BO_x */
#define BO_VALID0x8000
#define BO_LOCKED 0x4000
@@ -77,7 +76,7 @@ static int submit_lookup_objects(struct msm_gem_submit
*submit,
goto out_unlock;
}
- if (submit_bo.flags & BO_INVALID_FLAGS) {
+ if (submit_bo.flags & ~MSM_SUBMIT_BO_FLAGS) {
DRM_ERROR("invalid flags: %x\n", submit_bo.flags);
ret = -EINVAL;
goto out_unlock;
@@ -369,6 +368,18 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
*data,
goto out;
}
+ /* validate input from userspace: */
+ switch (submit_cmd.type) {
+ case MSM_SUBMIT_CMD_BUF:
+ case MSM_SUBMIT_CMD_IB_TARGET_BUF:
+ case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
+ break;
+ default:
+ DRM_ERROR("invalid type: %08x\n", submit_cmd.type);
+ ret = -EINVAL;
+ goto out;
+ }
+
ret = submit_bo(submit, submit_cmd.submit_idx,
&msm_obj, &iova, NULL);
if (ret)
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index bf91a78..0664c31 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -70,6 +70,12 @@ struct drm_msm_param {
#define MSM_BO_WC0x0002
#define MSM_BO_UNCACHED 0x0004
+#define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
+ MSM_BO_GPU_READONLY | \
+ MSM_BO_CACHED | \
+ MSM_BO_WC | \
+ MSM_BO_UNCACHED)
+
struct drm_msm_gem_new {
uint64_t size; /* in */
uint32_t flags; /* in, mask of MSM_BO_x */
@@ -86,6 +92,8 @@ struct drm_msm_gem_info {
#define MSM_PREP_WRITE 0x02
#define MSM_PREP_NOSYNC 0x04
+#define MSM_PREP_FLAGS (MSM_PREP_READ | MSM_PREP_WRITE | MSM_PREP_NOSYNC)
+
struct drm_msm_gem_cpu_prep {
uint32_t handle; /* in */
uint32_t op; /* in, mask of MSM_PREP_x */
@@ -153,6 +161,9 @@ struct drm_msm_gem_submit_cmd {
*/
#define MS
[Bug 75992] New: Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 Priority: medium Bug ID: 75992 Assignee: dri-devel at lists.freedesktop.org Summary: Display freezes & corruption with an r7 260x on 3.14-rc6 Severity: major Classification: Unclassified OS: Linux (All) Reporter: edt at aei.ca Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 95520 --> https://bugs.freedesktop.org/attachment.cgi?id=95520&action=edit log of boot I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. linux 3.14-rc6 (with an up to date arch, stable X and mesa-git (10.2) mesa 10.1 and 10.0 also show very similar problems. When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. -- 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/20140310/0a326545/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #1 from Ed Tomlinson --- Created attachment 95521 --> https://bugs.freedesktop.org/attachment.cgi?id=95521&action=edit xorg log of bug -- 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/20140310/96dbd6d7/attachment.html>
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 --- Comment #2 from Ed Tomlinson --- Created attachment 95523 --> https://bugs.freedesktop.org/attachment.cgi?id=95523&action=edit simple example of corruption (there can be many more rectangles) -- 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/20140310/e0a9a943/attachment.html>
[Bug 75433] xserver crashes after suspend with radeonsi and glamor, poor 2d performance
https://bugs.freedesktop.org/show_bug.cgi?id=75433 --- Comment #5 from blaze --- Created attachment 95527 --> https://bugs.freedesktop.org/attachment.cgi?id=95527&action=edit dmesg after the crash -- 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/20140310/735d57f1/attachment.html>
[PATCH 4/7] drm/msm: crank down gpu when inactive
On 03/10/2014 10:47 AM, Rob Clark wrote:
> Shut down the clks when the gpu has nothing to do. A short inactivity
> timer is used to provide a low pass filter for power transitions.
Good luck. Power management will take years off your life.
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 +
> drivers/gpu/drm/msm/msm_drv.c | 7 ++-
> drivers/gpu/drm/msm/msm_gpu.c | 85
> +--
> drivers/gpu/drm/msm/msm_gpu.h | 16 ++-
> 4 files changed, 113 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 59ed762..e6cb2bc 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -395,9 +395,15 @@ static const unsigned int a3xx_registers[] = {
> #ifdef CONFIG_DEBUG_FS
> static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
> {
> + struct drm_device *dev = gpu->dev;
> int i;
>
> adreno_show(gpu, m);
> +
> + mutex_lock(&dev->struct_mutex);
> +
> + gpu->funcs->pm_resume(gpu);
> +
> seq_printf(m, "status: %08x\n",
> gpu_read(gpu, REG_A3XX_RBBM_STATUS));
>
> @@ -413,6 +419,10 @@ static void a3xx_show(struct msm_gpu *gpu, struct
> seq_file *m)
> seq_printf(m, "IO:R %08x %08x\n", addr<<2, val);
> }
> }
> +
> + gpu->funcs->pm_suspend(gpu);
> +
> + mutex_unlock(&dev->struct_mutex);
> }
> #endif
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index e6adafc..e913efa 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -311,7 +311,6 @@ static void load_gpu(struct drm_device *dev)
> gpu = NULL;
> /* not fatal */
> }
> - mutex_unlock(&dev->struct_mutex);
>
> if (gpu) {
> int ret;
> @@ -321,10 +320,16 @@ static void load_gpu(struct drm_device *dev)
> dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
> gpu->funcs->destroy(gpu);
> gpu = NULL;
> + } else {
> + /* give inactive pm a chance to kick in: */
> + msm_gpu_retire(gpu);
> }
> +
> }
>
> priv->gpu = gpu;
> +
> + mutex_unlock(&dev->struct_mutex);
> }
>
> static int msm_open(struct drm_device *dev, struct drm_file *file)
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 0cfe3f4..3e667ca 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -154,9 +154,18 @@ static int disable_axi(struct msm_gpu *gpu)
>
> int msm_gpu_pm_resume(struct msm_gpu *gpu)
> {
> + struct drm_device *dev = gpu->dev;
> int ret;
>
> - DBG("%s", gpu->name);
> + DBG("%s: active_cnt=%d", gpu->name, gpu->active_cnt);
> +
> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> +
> + if (gpu->active_cnt++ > 0)
> + return 0;
> +
> + if (WARN_ON(gpu->active_cnt <= 0))
> + return -EINVAL;
>
> ret = enable_pwrrail(gpu);
> if (ret)
> @@ -175,9 +184,18 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
>
> int msm_gpu_pm_suspend(struct msm_gpu *gpu)
> {
> + struct drm_device *dev = gpu->dev;
> int ret;
>
> - DBG("%s", gpu->name);
> + DBG("%s: active_cnt=%d", gpu->name, gpu->active_cnt);
> +
> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> +
> + if (--gpu->active_cnt > 0)
> + return 0;
> +
> + if (WARN_ON(gpu->active_cnt < 0))
> + return -EINVAL;
>
> ret = disable_axi(gpu);
> if (ret)
> @@ -195,6 +213,55 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
> }
>
> /*
> + * Inactivity detection (for suspend):
> + */
> +
> +static void inactive_worker(struct work_struct *work)
> +{
> + struct msm_gpu *gpu = container_of(work, struct msm_gpu, inactive_work);
> + struct drm_device *dev = gpu->dev;
> +
> + if (gpu->inactive)
> + return;
> +
> + DBG("%s: inactive!\n", gpu->name);
> + mutex_lock(&dev->struct_mutex);
> + if (!(msm_gpu_active(gpu) || gpu->inactive)) {
> + disable_axi(gpu);
> + disable_clk(gpu);
> + gpu->inactive = true;
> + }
> + mutex_unlock(&dev->struct_mutex);
> +}
> +
> +static void inactive_handler(unsigned long data)
> +{
> + struct msm_gpu *gpu = (struct msm_gpu *)data;
> + struct msm_drm_private *priv = gpu->dev->dev_private;
> +
> + queue_work(priv->wq, &gpu->inactive_work);
> +}
> +
> +/* cancel inactive timer and make sure we are awake: */
> +static void inactive_cancel(struct msm_gpu *gpu)
> +{
> + DBG("%s", gpu->name);
> + del_timer(&gpu->inactive_timer);
> + if (gpu->inactive) {
> + enable_clk(gpu);
> + enable_axi(gpu);
> +
[PATCH 2/7] drm/msm: add hang_debug module param
On 03/10/2014 10:47 AM, Rob Clark wrote:
> msm.hang_debug=y will dump out current register values if the gpu locks
> up, for easier debugging.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 34
> -
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 +
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 1 +
> 3 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 461df93..8b6fb84 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -35,6 +35,12 @@
>A3XX_INT0_CP_AHB_ERROR_HALT | \
>A3XX_INT0_UCHE_OOB_ACCESS)
>
> +
> +static bool hang_debug = false;
> +MODULE_PARM_DESC(hang_debug, "Dump registers when hang is detected (can be
> slow!)");
> +module_param_named(hang_debug, hang_debug, bool, 0600);
> +static void a3xx_dump(struct msm_gpu *gpu);
> +
> static struct platform_device *a3xx_pdev;
>
> static void a3xx_me_init(struct msm_gpu *gpu)
> @@ -291,6 +297,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
>
> static void a3xx_recover(struct msm_gpu *gpu)
> {
> + /* dump registers before resetting gpu, if enabled: */
> + if (hang_debug)
> + a3xx_dump(gpu);
You will need to be careful here - not all the registers are suitable for
reading back.
On some flavors of A330 in particular some HLSQ registers reads will bring the
system
down. You can see the gory details in the KGSL driver. If this works for you
for now
great but fair warning that some cores might have different experiences.
> gpu_write(gpu, REG_A3XX_RBBM_SW_RESET_CMD, 1);
> gpu_read(gpu, REG_A3XX_RBBM_SW_RESET_CMD);
> gpu_write(gpu, REG_A3XX_RBBM_SW_RESET_CMD, 0);
> @@ -352,7 +361,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
> return IRQ_HANDLED;
> }
>
> -#ifdef CONFIG_DEBUG_FS
> static const unsigned int a3xx_registers[] = {
> 0x, 0x0002, 0x0010, 0x0012, 0x0018, 0x0018, 0x0020, 0x0027,
> 0x0029, 0x002b, 0x002e, 0x0033, 0x0040, 0x0042, 0x0050, 0x005c,
> @@ -392,6 +400,7 @@ static const unsigned int a3xx_registers[] = {
> 0x303c, 0x303c, 0x305e, 0x305f,
> };
>
> +#ifdef CONFIG_DEBUG_FS
> static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
> {
> int i;
> @@ -415,6 +424,29 @@ static void a3xx_show(struct msm_gpu *gpu, struct
> seq_file *m)
> }
> #endif
>
> +/* would be nice to not have to duplicate the _show() stuff with printk(): */
> +static void a3xx_dump(struct msm_gpu *gpu)
> +{
> + int i;
> +
> + adreno_dump(gpu);
> + printk("status: %08x\n",
> + gpu_read(gpu, REG_A3XX_RBBM_STATUS));
> +
> + /* dump these out in a form that can be parsed by demsm: */
> + printk("IO:region %s 0002\n", gpu->name);
> + for (i = 0; i < ARRAY_SIZE(a3xx_registers); i += 2) {
> + uint32_t start = a3xx_registers[i];
> + uint32_t end = a3xx_registers[i+1];
> + uint32_t addr;
> +
> + for (addr = start; addr <= end; addr++) {
> + uint32_t val = gpu_read(gpu, addr);
> + printk("IO:R %08x %08x\n", addr<<2, val);
> + }
> + }
> +}
> +
> static const struct adreno_gpu_funcs funcs = {
> .base = {
> .get_param = adreno_get_param,
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index d321099..cf6eb97 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -260,6 +260,24 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
> }
> #endif
>
> +/* would be nice to not have to duplicate the _show() stuff with printk(): */
> +void adreno_dump(struct msm_gpu *gpu)
> +{
> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> +
> + printk("revision: %d (%d.%d.%d.%d)\n",
> + adreno_gpu->info->revn, adreno_gpu->rev.core,
> + adreno_gpu->rev.major, adreno_gpu->rev.minor,
> + adreno_gpu->rev.patchid);
> +
> + printk("fence:%d/%d\n", adreno_gpu->memptrs->fence,
> + gpu->submitted_fence);
> + printk("rptr: %d\n", adreno_gpu->memptrs->rptr);
> + printk("wptr: %d\n", adreno_gpu->memptrs->wptr);
> + printk("rb wptr: %d\n", get_wptr(gpu->rb));
> +
> +}
> +
We should introduce you to the gooey wonderfulness of the snapshot :) All in
due time.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 5/7] drm/msm: add chip-id param
On 03/10/2014 10:47 AM, Rob Clark wrote:
> Some of the w/a or different behavior of userspace blob driver seem to
> be keyed to gpu patch revision, rather than gpu-id. So expose the full
> chip-id to userspace so it can DTRT.
It is all chip-id all the time in the blob - we used to try to be clever
with unique GPU IDs and such with it but we discovered over time that there
is just too much drama.
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 ++
> include/uapi/drm/msm_drm.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 7a11563..28ca8cd 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -73,6 +73,12 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param,
> uint64_t *value)
> case MSM_PARAM_GMEM_SIZE:
> *value = adreno_gpu->gmem;
> return 0;
> + case MSM_PARAM_CHIP_ID:
> + *value = adreno_gpu->rev.patchid |
> + (adreno_gpu->rev.minor << 8) |
> + (adreno_gpu->rev.major << 16) |
> + (adreno_gpu->rev.core << 24);
> + return 0;
> default:
> DBG("%s: invalid param: %u", gpu->name, param);
> return -EINVAL;
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index d3c6207..bf91a78 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -50,6 +50,7 @@ struct drm_msm_timespec {
>
> #define MSM_PARAM_GPU_ID 0x01
> #define MSM_PARAM_GMEM_SIZE 0x02
> +#define MSM_PARAM_CHIP_ID0x03
>
> struct drm_msm_param {
> uint32_t pipe; /* in, MSM_PIPE_x */
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 2/7] drm/msm: add hang_debug module param
On Mon, Mar 10, 2014 at 4:17 PM, Jordan Crouse
wrote:
> On 03/10/2014 10:47 AM, Rob Clark wrote:
>>
>> msm.hang_debug=y will dump out current register values if the gpu locks
>> up, for easier debugging.
>>
>> Signed-off-by: Rob Clark
>> ---
>> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 34
>> -
>> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 18 +
>> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 1 +
>> 3 files changed, 52 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> index 461df93..8b6fb84 100644
>> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> @@ -35,6 +35,12 @@
>> A3XX_INT0_CP_AHB_ERROR_HALT | \
>> A3XX_INT0_UCHE_OOB_ACCESS)
>>
>> +
>> +static bool hang_debug = false;
>> +MODULE_PARM_DESC(hang_debug, "Dump registers when hang is detected (can
>> be slow!)");
>> +module_param_named(hang_debug, hang_debug, bool, 0600);
>> +static void a3xx_dump(struct msm_gpu *gpu);
>> +
>> static struct platform_device *a3xx_pdev;
>>
>> static void a3xx_me_init(struct msm_gpu *gpu)
>> @@ -291,6 +297,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
>>
>> static void a3xx_recover(struct msm_gpu *gpu)
>> {
>> + /* dump registers before resetting gpu, if enabled: */
>> + if (hang_debug)
>> + a3xx_dump(gpu);
>
>
> You will need to be careful here - not all the registers are suitable for
> reading back.
> On some flavors of A330 in particular some HLSQ registers reads will bring
> the system
> down. You can see the gory details in the KGSL driver. If this works for
> you for now
> great but fair warning that some cores might have different experiences.
>From what I've seen, certain types of GPU lockup (for example shader
const overrun), even on a320, leave things such that reading HLSQ
registers does bad things, which is why I don't enable the bootarg by
default.
If there is a way to *detect* when HLSQ is in a bad state and skip
those registers, that would be awesome. I guess I should have another
look at latest kgsl to see if there is some trick I missed.
Or otherwise I should probably make the bootarg a bitmask so you can
choose to enable/disable certain groups of registers.
>
>> gpu_write(gpu, REG_A3XX_RBBM_SW_RESET_CMD, 1);
>> gpu_read(gpu, REG_A3XX_RBBM_SW_RESET_CMD);
>> gpu_write(gpu, REG_A3XX_RBBM_SW_RESET_CMD, 0);
>> @@ -352,7 +361,6 @@ static irqreturn_t a3xx_irq(struct msm_gpu *gpu)
>> return IRQ_HANDLED;
>> }
>>
>> -#ifdef CONFIG_DEBUG_FS
>> static const unsigned int a3xx_registers[] = {
>> 0x, 0x0002, 0x0010, 0x0012, 0x0018, 0x0018, 0x0020, 0x0027,
>> 0x0029, 0x002b, 0x002e, 0x0033, 0x0040, 0x0042, 0x0050, 0x005c,
>> @@ -392,6 +400,7 @@ static const unsigned int a3xx_registers[] = {
>> 0x303c, 0x303c, 0x305e, 0x305f,
>> };
>>
>> +#ifdef CONFIG_DEBUG_FS
>> static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
>> {
>> int i;
>> @@ -415,6 +424,29 @@ static void a3xx_show(struct msm_gpu *gpu, struct
>> seq_file *m)
>> }
>> #endif
>>
>> +/* would be nice to not have to duplicate the _show() stuff with
>> printk(): */
>> +static void a3xx_dump(struct msm_gpu *gpu)
>> +{
>> + int i;
>> +
>> + adreno_dump(gpu);
>> + printk("status: %08x\n",
>> + gpu_read(gpu, REG_A3XX_RBBM_STATUS));
>> +
>> + /* dump these out in a form that can be parsed by demsm: */
>> + printk("IO:region %s 0002\n", gpu->name);
>> + for (i = 0; i < ARRAY_SIZE(a3xx_registers); i += 2) {
>> + uint32_t start = a3xx_registers[i];
>> + uint32_t end = a3xx_registers[i+1];
>> + uint32_t addr;
>> +
>> + for (addr = start; addr <= end; addr++) {
>> + uint32_t val = gpu_read(gpu, addr);
>> + printk("IO:R %08x %08x\n", addr<<2, val);
>> + }
>> + }
>> +}
>> +
>> static const struct adreno_gpu_funcs funcs = {
>> .base = {
>> .get_param = adreno_get_param,
>> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> index d321099..cf6eb97 100644
>> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
>> @@ -260,6 +260,24 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file
>> *m)
>> }
>> #endif
>>
>> +/* would be nice to not have to duplicate the _show() stuff with
>> printk(): */
>> +void adreno_dump(struct msm_gpu *gpu)
>> +{
>> + struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
>> +
>> + printk("revision: %d (%d.%d.%d.%d)\n",
>> + adreno_gpu->info->revn, adreno_gpu->rev.core,
>> + adreno_gpu->rev.major, adreno_gpu->rev.minor,
>> + adreno_gpu->re
[PATCH 3/7] drm/msm: spin helper
On 03/10/2014 10:47 AM, Rob Clark wrote:
> Helper macro to simplify places where we need to poll with timeout
> waiting for gpu.
>
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 14 +++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 41
> -
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 15 +++-
> 3 files changed, 32 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> index 8b6fb84..59ed762 100644
> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
> @@ -326,21 +326,13 @@ static void a3xx_destroy(struct msm_gpu *gpu)
>
> static void a3xx_idle(struct msm_gpu *gpu)
> {
> - unsigned long t;
> -
> /* wait for ringbuffer to drain: */
> adreno_idle(gpu);
>
> - t = jiffies + ADRENO_IDLE_TIMEOUT;
> -
> /* then wait for GPU to finish: */
> - do {
> - uint32_t rbbm_status = gpu_read(gpu, REG_A3XX_RBBM_STATUS);
> - if (!(rbbm_status & A3XX_RBBM_STATUS_GPU_BUSY))
> - return;
> - } while(time_before(jiffies, t));
> -
> - DRM_ERROR("timeout waiting for %s to idle!\n", gpu->name);
> + if (spin_until(!(gpu_read(gpu, REG_A3XX_RBBM_STATUS) &
> + A3XX_RBBM_STATUS_GPU_BUSY)))
> + DRM_ERROR("%s: timeout waiting for GPU to idle!\n", gpu->name);
>
> /* TODO maybe we need to reset GPU here to recover from hang? */
> }
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index cf6eb97..7a11563 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -225,19 +225,11 @@ void adreno_flush(struct msm_gpu *gpu)
> void adreno_idle(struct msm_gpu *gpu)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> - uint32_t rptr, wptr = get_wptr(gpu->rb);
> - unsigned long t;
> -
> - t = jiffies + ADRENO_IDLE_TIMEOUT;
> -
> - /* then wait for CP to drain ringbuffer: */
> - do {
> - rptr = adreno_gpu->memptrs->rptr;
> - if (rptr == wptr)
> - return;
> - } while(time_before(jiffies, t));
> + uint32_t wptr = get_wptr(gpu->rb);
>
> - DRM_ERROR("%s: timeout waiting to drain ringbuffer!\n", gpu->name);
> + /* wait for CP to drain ringbuffer: */
> + if (spin_until(adreno_gpu->memptrs->rptr == wptr))
> + DRM_ERROR("%s: timeout waiting to drain ringbuffer!\n",
> gpu->name);
>
> /* TODO maybe we need to reset GPU here to recover from hang? */
> }
> @@ -278,22 +270,19 @@ void adreno_dump(struct msm_gpu *gpu)
>
> }
>
> -void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords)
> +static uint32_t ring_freewords(struct msm_gpu *gpu)
> {
> struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
> - uint32_t freedwords;
> - unsigned long t = jiffies + ADRENO_IDLE_TIMEOUT;
> - do {
> - uint32_t size = gpu->rb->size / 4;
> - uint32_t wptr = get_wptr(gpu->rb);
> - uint32_t rptr = adreno_gpu->memptrs->rptr;
> - freedwords = (rptr + (size - 1) - wptr) % size;
> -
> - if (time_after(jiffies, t)) {
> - DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
> gpu->name);
> - break;
> - }
> - } while(freedwords < ndwords);
> + uint32_t size = gpu->rb->size / 4;
> + uint32_t wptr = get_wptr(gpu->rb);
> + uint32_t rptr = adreno_gpu->memptrs->rptr;
> + return (rptr + (size - 1) - wptr) % size;
> +}
> +
> +void adreno_wait_ring(struct msm_gpu *gpu, uint32_t ndwords)
> +{
> + if (spin_until(ring_freewords(gpu) >= ndwords))
> + DRM_ERROR("%s: timeout waiting for ringbuffer space\n",
> gpu->name);
> }
>
> static const char *iommu_ports[] = {
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index e16200d..63c36ce 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -76,7 +76,20 @@ struct adreno_platform_config {
> #endif
> };
>
> -#define ADRENO_IDLE_TIMEOUT (20 * 1000)
> +#define ADRENO_IDLE_TIMEOUT msecs_to_jiffies(1000)
> +
> +#define spin_until(X) ({ \
> + int __ret = -ETIMEDOUT;\
> + unsigned long __t = jiffies + ADRENO_IDLE_TIMEOUT; \
> + do { \
> + if (X) { \
> + __ret = 0; \
> + break; \
> + } \
> + } while (time_before(jiffies, __t)); \
> + __ret; \
> +
[PATCH 7/7] drm/msm: validate flags, etc
On 03/10/2014 10:47 AM, Rob Clark wrote:
> After reading a nice article on LWN[1], I went back and double checked
> my handling of invalid-input checking. Turns out there were a couple
> places I had missed.
>
> Since the driver is fairly young, and the devices it supports are really
> only just barely usable for basic stuff (serial console) with an
> upstream kernel, I think we should fix this now and revert specific
> parts of this patch later in the unlikely event that a regression is
> reported.
>
> [1] https://lwn.net/Articles/588444/
>
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/msm_drv.c| 20 +++-
> drivers/gpu/drm/msm/msm_gem_submit.c | 15 +--
> include/uapi/drm/msm_drm.h | 11 +++
> 3 files changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 9ffc275..eee8d37 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -664,6 +664,12 @@ static int msm_ioctl_gem_new(struct drm_device *dev,
> void *data,
> struct drm_file *file)
> {
> struct drm_msm_gem_new *args = data;
> +
> + if (args->flags & ~MSM_BO_FLAGS) {
> + DRM_ERROR("invalid flags: %08x\n", args->flags);
> + return -EINVAL;
> + }
> +
> return msm_gem_new_handle(dev, file, args->size,
> args->flags, &args->handle);
> }
> @@ -677,6 +683,11 @@ static int msm_ioctl_gem_cpu_prep(struct drm_device
> *dev, void *data,
> struct drm_gem_object *obj;
> int ret;
>
> + if (args->op & ~MSM_PREP_FLAGS) {
> + DRM_ERROR("invalid op: %08x\n", args->op);
> + return -EINVAL;
> + }
> +
> obj = drm_gem_object_lookup(dev, file, args->handle);
> if (!obj)
> return -ENOENT;
> @@ -731,7 +742,14 @@ static int msm_ioctl_wait_fence(struct drm_device *dev,
> void *data,
> struct drm_file *file)
> {
> struct drm_msm_wait_fence *args = data;
> - return msm_wait_fence_interruptable(dev, args->fence,
> &TS(args->timeout));
> +
> + if (args->pad) {
> + DRM_ERROR("invalid pad: %08x\n", args->pad);
> + return -EINVAL;
> + }
> +
> + return msm_wait_fence_interruptable(dev, args->fence,
> + &TS(args->timeout));
> }
>
> static const struct drm_ioctl_desc msm_ioctls[] = {
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 5423e91..1f1f4cf 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -23,7 +23,6 @@
>* Cmdstream submission:
>*/
>
> -#define BO_INVALID_FLAGS ~(MSM_SUBMIT_BO_READ | MSM_SUBMIT_BO_WRITE)
> /* make sure these don't conflict w/ MSM_SUBMIT_BO_x */
> #define BO_VALID0x8000
> #define BO_LOCKED 0x4000
> @@ -77,7 +76,7 @@ static int submit_lookup_objects(struct msm_gem_submit
> *submit,
> goto out_unlock;
> }
>
> - if (submit_bo.flags & BO_INVALID_FLAGS) {
> + if (submit_bo.flags & ~MSM_SUBMIT_BO_FLAGS) {
> DRM_ERROR("invalid flags: %x\n", submit_bo.flags);
> ret = -EINVAL;
> goto out_unlock;
> @@ -369,6 +368,18 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> goto out;
> }
>
> + /* validate input from userspace: */
> + switch (submit_cmd.type) {
> + case MSM_SUBMIT_CMD_BUF:
> + case MSM_SUBMIT_CMD_IB_TARGET_BUF:
> + case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
> + break;
> + default:
> + DRM_ERROR("invalid type: %08x\n", submit_cmd.type);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> ret = submit_bo(submit, submit_cmd.submit_idx,
> &msm_obj, &iova, NULL);
> if (ret)
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index bf91a78..0664c31 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -70,6 +70,12 @@ struct drm_msm_param {
> #define MSM_BO_WC0x0002
> #define MSM_BO_UNCACHED 0x0004
>
> +#define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
> + MSM_BO_GPU_READONLY | \
> + MSM_BO_CACHED | \
> + MSM_BO_WC | \
> + MSM_BO_UNCACHED)
> +
> struct drm_msm_gem_new {
> uint64_t size; /* in */
> uint32_t flags; /* in, mask of MSM_BO_x */
> @@ -86,6 +92,8 @@ struct drm_msm_gem_info {
> #define MSM_PREP_WRITE 0x02
> #define MSM_PREP_NOSYNC 0x04
>
> +#define MSM_PREP_FLAGS (MSM_PREP_READ |
[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6
https://bugs.freedesktop.org/show_bug.cgi?id=75992 Ed Tomlinson changed: What|Removed |Added Attachment #95523|text/plain |image/png mime type|| -- 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/20140310/cd0e4a9a/attachment.html>
[PATCH 4/7] drm/msm: crank down gpu when inactive
On Mon, Mar 10, 2014 at 4:24 PM, Jordan Crouse
wrote:
> On 03/10/2014 10:47 AM, Rob Clark wrote:
>>
>> Shut down the clks when the gpu has nothing to do. A short inactivity
>> timer is used to provide a low pass filter for power transitions.
>
>
> Good luck. Power management will take years off your life.
that is why I started with something extremely simple ;-)
I've actually had this patch right around the time of the 3.14 merge
window, but didn't want to push this sort of thing in last minute.
I've been using it locally since then, and so far so good
BR,
-R
>
>> Signed-off-by: Rob Clark
>
>
> Acked-by: Jordan Crouse
>
>> ---
>> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 +
>> drivers/gpu/drm/msm/msm_drv.c | 7 ++-
>> drivers/gpu/drm/msm/msm_gpu.c | 85
>> +--
>> drivers/gpu/drm/msm/msm_gpu.h | 16 ++-
>> 4 files changed, 113 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> index 59ed762..e6cb2bc 100644
>> --- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
>> @@ -395,9 +395,15 @@ static const unsigned int a3xx_registers[] = {
>> #ifdef CONFIG_DEBUG_FS
>> static void a3xx_show(struct msm_gpu *gpu, struct seq_file *m)
>> {
>> + struct drm_device *dev = gpu->dev;
>> int i;
>>
>> adreno_show(gpu, m);
>> +
>> + mutex_lock(&dev->struct_mutex);
>> +
>> + gpu->funcs->pm_resume(gpu);
>> +
>> seq_printf(m, "status: %08x\n",
>> gpu_read(gpu, REG_A3XX_RBBM_STATUS));
>>
>> @@ -413,6 +419,10 @@ static void a3xx_show(struct msm_gpu *gpu, struct
>> seq_file *m)
>> seq_printf(m, "IO:R %08x %08x\n", addr<<2, val);
>> }
>> }
>> +
>> + gpu->funcs->pm_suspend(gpu);
>> +
>> + mutex_unlock(&dev->struct_mutex);
>> }
>> #endif
>>
>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> index e6adafc..e913efa 100644
>> --- a/drivers/gpu/drm/msm/msm_drv.c
>> +++ b/drivers/gpu/drm/msm/msm_drv.c
>> @@ -311,7 +311,6 @@ static void load_gpu(struct drm_device *dev)
>> gpu = NULL;
>> /* not fatal */
>> }
>> - mutex_unlock(&dev->struct_mutex);
>>
>> if (gpu) {
>> int ret;
>> @@ -321,10 +320,16 @@ static void load_gpu(struct drm_device *dev)
>> dev_err(dev->dev, "gpu hw init failed: %d\n",
>> ret);
>> gpu->funcs->destroy(gpu);
>> gpu = NULL;
>> + } else {
>> + /* give inactive pm a chance to kick in: */
>> + msm_gpu_retire(gpu);
>> }
>> +
>> }
>>
>> priv->gpu = gpu;
>> +
>> + mutex_unlock(&dev->struct_mutex);
>> }
>>
>> static int msm_open(struct drm_device *dev, struct drm_file *file)
>> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
>> index 0cfe3f4..3e667ca 100644
>> --- a/drivers/gpu/drm/msm/msm_gpu.c
>> +++ b/drivers/gpu/drm/msm/msm_gpu.c
>> @@ -154,9 +154,18 @@ static int disable_axi(struct msm_gpu *gpu)
>>
>> int msm_gpu_pm_resume(struct msm_gpu *gpu)
>> {
>> + struct drm_device *dev = gpu->dev;
>> int ret;
>>
>> - DBG("%s", gpu->name);
>> + DBG("%s: active_cnt=%d", gpu->name, gpu->active_cnt);
>> +
>> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>> +
>> + if (gpu->active_cnt++ > 0)
>> + return 0;
>> +
>> + if (WARN_ON(gpu->active_cnt <= 0))
>> + return -EINVAL;
>>
>> ret = enable_pwrrail(gpu);
>> if (ret)
>> @@ -175,9 +184,18 @@ int msm_gpu_pm_resume(struct msm_gpu *gpu)
>>
>> int msm_gpu_pm_suspend(struct msm_gpu *gpu)
>> {
>> + struct drm_device *dev = gpu->dev;
>> int ret;
>>
>> - DBG("%s", gpu->name);
>> + DBG("%s: active_cnt=%d", gpu->name, gpu->active_cnt);
>> +
>> + WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>> +
>> + if (--gpu->active_cnt > 0)
>> + return 0;
>> +
>> + if (WARN_ON(gpu->active_cnt < 0))
>> + return -EINVAL;
>>
>> ret = disable_axi(gpu);
>> if (ret)
>> @@ -195,6 +213,55 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
>> }
>>
>> /*
>> + * Inactivity detection (for suspend):
>> + */
>> +
>> +static void inactive_worker(struct work_struct *work)
>> +{
>> + struct msm_gpu *gpu = container_of(work, struct msm_gpu,
>> inactive_work);
>> + struct drm_device *dev = gpu->dev;
>> +
>> + if (gpu->inactive)
>> + return;
>> +
>> + DBG("%s: inactive!\n", gpu->name);
>> + mutex_lock(&dev->struct_mutex);
>> + if (!(msm_gpu_active(gpu) || gpu->inactive)) {
>> + disable_axi(gpu);
>> + disable_clk(gpu);
>> + gpu->inactive
[PATCH] drm/fb-helper: Do the mode_set.connectors ZERO_SIZE_PTR check
> Subject: Re: [PATCH] drm/fb-helper: Do the mode_set.connectors ZERO_SIZE_PTR > check > > On Thu, 06 Mar 2014, Xiubo Li wrote: > > Since we cannot make sure the 'max_conn_count' will always be none > > zero from the users, and then if max_conn_count equals to zero, the > > kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16). > > > > So this patch fix this via doing the zero pionter check of it. > > Please just add a check for max_conn_count == 0 up front and handle it. > > BR, > Jani. > Yes, that's one better choice. See the next version please. Thanks very much! -- Best Regards, Xiubo > > > > > Signed-off-by: Xiubo Li > > --- > > drivers/gpu/drm/drm_fb_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > b/drivers/gpu/drm/drm_fb_helper.c > > index 3d13ca6e2..c6680ef 100644 > > --- a/drivers/gpu/drm/drm_fb_helper.c > > +++ b/drivers/gpu/drm/drm_fb_helper.c > > @@ -536,7 +536,7 @@ int drm_fb_helper_init(struct drm_device *dev, > > sizeof(struct drm_connector *), > > GFP_KERNEL); > > > > - if (!fb_helper->crtc_info[i].mode_set.connectors) > > + if > > (ZERO_OR_NULL_PTR(fb_helper->crtc_info[i].mode_set.connectors)) > > goto out_free; > > fb_helper->crtc_info[i].mode_set.num_connectors = 0; > > } > > -- > > 1.8.4 > > > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Jani Nikula, Intel Open Source Technology Center >
[PATCH v2] drm/fb-helper: Do the 'max_conn_count' zero check
Since we cannot make sure the 'max_conn_count' will always be none zero from the users, and then if max_conn_count equals to zero, the kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the 'max_conn_count' zero check in the front of drm_fb_helper_init(). Signed-off-by: Xiubo Li CC: Jani Nikula --- drivers/gpu/drm/drm_fb_helper.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 3d13ca6e2..a0d286c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -514,6 +514,9 @@ int drm_fb_helper_init(struct drm_device *dev, struct drm_crtc *crtc; int i; + if (!max_conn_count) + return -EINVAL; + fb_helper->dev = dev; INIT_LIST_HEAD(&fb_helper->kernel_fb_list); -- 1.8.4
[PATCH] drm/exynos: set the active aspect ratio as per mode
now that the drm_display_mode also provides aspect
ratio for all resolutions, this patch adds its usage
to set the active aspect ratio of AVI info frame
packets as per CEA-861-D standard's Table 9.
This is also needed to abide by the 7-27
compliance test of HDMI.
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index c021ddc..8aca52a 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -53,8 +53,6 @@
/* AVI header and aspect ratio */
#define HDMI_AVI_VERSION 0x02
#define HDMI_AVI_LENGTH0x0D
-#define AVI_PIC_ASPECT_RATIO_16_9 (2 << 4)
-#define AVI_SAME_AS_PIC_ASPECT_RATIO 8
/* AUI header info */
#define HDMI_AUI_VERSION 0x01
@@ -65,6 +63,12 @@ enum hdmi_type {
HDMI_TYPE14,
};
+enum active_aspect_ratio {
+ AVI_SAME_AS_PIC_ASPECT_RATIO = 8,
+ AVI_4_3_Center_RATIO,
+ AVI_16_9_Center_RATIO,
+};
+
struct hdmi_resources {
struct clk *hdmi;
struct clk *sclk_hdmi;
@@ -162,6 +166,7 @@ struct hdmi_v14_conf {
struct hdmi_conf_regs {
int pixel_clock;
int cea_video_id;
+ enum hdmi_picture_aspect aspect_ratio;
union {
struct hdmi_v13_conf v13_conf;
struct hdmi_v14_conf v14_conf;
@@ -668,7 +673,6 @@ static void hdmi_reg_infoframe(struct hdmi_context *hdata,
{
u32 hdr_sum;
u8 chksum;
- u32 aspect_ratio;
u32 mod;
u32 vic;
@@ -697,10 +701,25 @@ static void hdmi_reg_infoframe(struct hdmi_context *hdata,
AVI_ACTIVE_FORMAT_VALID |
AVI_UNDERSCANNED_DISPLAY_VALID);
- aspect_ratio = AVI_PIC_ASPECT_RATIO_16_9;
-
- hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2), aspect_ratio |
+ /*
+* Set the aspect ratio as per the mode, mentioned in
+* Table 9 AVI InfoFrame Data Byte 2 of CEA-861-D Standard
+*/
+ switch (hdata->mode_conf.aspect_ratio) {
+ case HDMI_PICTURE_ASPECT_4_3:
+ hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2), aspect_ratio |
+ AVI_4_3_Center_RATIO);
+ break;
+ case HDMI_PICTURE_ASPECT_16_9:
+ hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2), aspect_ratio |
+ AVI_16_9_Center_RATIO);
+ break;
+ case HDMI_PICTURE_ASPECT_NONE:
+ default:
+ hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(2), aspect_ratio |
AVI_SAME_AS_PIC_ASPECT_RATIO);
+ break;
+ }
vic = hdata->mode_conf.cea_video_id;
hdmi_reg_writeb(hdata, HDMI_AVI_BYTE(4), vic);
@@ -1421,6 +1440,7 @@ static void hdmi_v13_mode_set(struct hdmi_context *hdata,
hdata->mode_conf.cea_video_id =
drm_match_cea_mode((struct drm_display_mode *)m);
hdata->mode_conf.pixel_clock = m->clock * 1000;
+ hdata->mode_conf.aspect_ratio = m->picture_aspect_ratio;
hdmi_set_reg(core->h_blank, 2, m->htotal - m->hdisplay);
hdmi_set_reg(core->h_v_line, 3, (m->htotal << 12) | m->vtotal);
@@ -1517,6 +1537,7 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdata->mode_conf.cea_video_id =
drm_match_cea_mode((struct drm_display_mode *)m);
hdata->mode_conf.pixel_clock = m->clock * 1000;
+ hdata->mode_conf.aspect_ratio = m->picture_aspect_ratio;
hdmi_set_reg(core->h_blank, 2, m->htotal - m->hdisplay);
hdmi_set_reg(core->v_line, 2, m->vtotal);
--
1.7.10.4
[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
On 07/03/14 16:17, Philipp Zabel wrote: > Hi, > > Am Donnerstag, den 06.03.2014, 10:52 +0200 schrieb Tomi Valkeinen: >> analog; >> digital-single-link; >> digital-dual-link; >> >> My reasoning to the format I chose was basically that when a connector >> supports 'digital', it contains TMDS clock and TMDS data for link 1. >> Adding dual link to that adds only TMDS data for link 2, so the second >> data link is kind of an additional feature, marked with a flag. >> >> Not a very big argument, and I'm fine with other format suggestions. > > I'd prefer the analog / digital / dual-link variant for aesthetic > reasons. But looking at other connector types, I wonder if this should > be generalized even more: > > For HDMI/DVI (digital) single-link means one clock pair and 3 TMDS data > pairs, dual-link means one clock pair and 6 data pairs. > > On LVDS connectors, there usually are one clock pair and three (18-bit) > or four (24-bit) LVDS data pairs, in dual channel configuration two > clock pairs and 6 or 8 data pairs are used. > > For DisplayPort there is no separate clock pair, but 1 to 4 data pairs, > and MIPI DSI again has one clock pair and a one or more data pairs. > > There are already optional endpoint configuration properties > 'data-lanes' and 'clock-lanes' for MIPI CSI-2 defined in > Documentation/devicetree/bindings/media/video-interfaces.txt. > Could/should this be aligned with the same? Hmm. Well, at least for HDMI and DP we anyway need the connector type, which tells the form factor, and it also tells the TMDS details. So, we could define the lanes in a common way, but we'd still need extra information. For MIPI DSI and (I believe) LVDS, we don't need connectors. Connectors, as described in this binding, are meant for standard hotpluggable connectors to which you can connect any device that has that same connector. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140310/6e78afa8/attachment-0001.pgp>
[BUG] 3.14-rc6 problems with an R7 260X
Hi, I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. Here are some extracts from the logs of the latest fun with dpm enabled: with 3.14-rc6 (with an up to date arch, stable X and mesa-git (10.2) mesa 10.1 and 10.0 also show very similar problems. Mar 10 10:45:04 localhost kernel: [0.00] Command line: BOOT_IMAGE=/vmlinuz-linux-mainline root=/dev/sda3 ro console=tty0 verbose Mar 10 10:45:04 localhost kernel: [3.258402] [drm] radeon kernel modesetting enabled. Mar 10 10:45:04 localhost kernel: [3.258421] checking generic (e000 30) vs hw (e000 1000) Mar 10 10:45:04 localhost kernel: [3.258422] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver Mar 10 10:45:04 localhost kernel: [3.270529] Console: switching to colour dummy device 80x25 Mar 10 10:45:04 localhost kernel: [3.270757] [drm] initializing kernel modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253). Mar 10 10:45:04 localhost kernel: [3.270781] [drm] register mmio base: 0xF080 Mar 10 10:45:04 localhost kernel: [3.270782] [drm] register mmio size: 262144 Mar 10 10:45:04 localhost kernel: [3.270785] [drm] doorbell mmio base: 0xF000 Mar 10 10:45:04 localhost kernel: [3.270786] [drm] doorbell mmio size: 8388608 Mar 10 10:45:04 localhost kernel: [3.270837] ATOM BIOS: Bonaire Mar 10 10:45:04 localhost kernel: [3.270884] radeon :01:00.0: VRAM: 2048M 0x - 0x7FFF (2048M used) Mar 10 10:45:04 localhost kernel: [3.270884] radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF Mar 10 10:45:04 localhost kernel: [3.270885] [drm] Detected VRAM RAM=2048M, BAR=256M Mar 10 10:45:04 localhost kernel: [3.270886] [drm] RAM width 128bits DDR Mar 10 10:45:04 localhost kernel: [3.270925] [TTM] Zone kernel: Available graphics memory: 8145248 kiB Mar 10 10:45:04 localhost kernel: [3.270926] [TTM] Zone dma32: Available graphics memory: 2097152 kiB Mar 10 10:45:04 localhost kernel: [3.270927] [TTM] Initializing pool allocator Mar 10 10:45:04 localhost kernel: [3.270929] [TTM] Initializing DMA pool allocator Mar 10 10:45:04 localhost kernel: [3.270940] [drm] radeon: 2048M of VRAM memory ready Mar 10 10:45:04 localhost kernel: [3.270940] [drm] radeon: 1024M of GTT memory ready. Mar 10 10:45:04 localhost kernel: [3.270948] [drm] Loading BONAIRE Microcode Mar 10 10:45:04 localhost kernel: [3.276841] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290 Mar 10 10:45:04 localhost kernel: [3.280263] [drm] Internal thermal controller with fan control Mar 10 10:45:04 localhost kernel: [3.280294] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e Mar 10 10:45:04 localhost kernel: [3.286710] [drm] radeon: dpm initialized Mar 10 10:45:04 localhost kernel: [3.288706] [drm] GART: num cpu pages 262144, num gpu pages 262144 Mar 10 10:45:04 localhost kernel: [3.289112] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e Mar 10 10:45:04 localhost kernel: [3.289114] [drm] PCIE gen 3 link speeds already enabled Mar 10 10:45:04 localhost kernel: [3.299762] [drm] PCIE GART of 1024M enabled (table at 0x00277000). from xorg's log [55.320] (II) RADEON(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [55.320] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [55.320] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [55.320] (==) RADEON(0): Default visual is TrueColor [55.320] (==) RADEON(0): RGB weight 888 [55.320] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [55.320] (--) RADEON(0): Chipset: "BONAIRE" (ChipID = 0x6658) [55.320] (II) Loading sub module "dri2" [55.320] (II) LoadModule: "dri2" [55.320] (II) Module "dri2" already built-in [55.320] (II) Loading sub module "glamoregl" [55.320] (II) LoadModule: "glamoregl" [55.320] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [55.320] (II) Module glamoregl: vendor="X.Org Foundation" [55.320]compiled for 1.15.0, module version = 0.6.0 [55.320]ABI class: X.Org ANSI C Emulation, version 0.4 [55.320] (II) glamor: OpenGL accelerated X.org driver based. [55.832] (II) glamor: EGL version 1.4 (DRI2): [55.845] (II) RADEON(0): glamor detected, initialising EGL layer. [55.845] (II) RADEON(0): KMS Color Tiling: disabled [55.845] (II) RADEON(0): KMS Color Tiling 2D: disabled [55.845] (II) RADEON(0): KMS Pageflipping: enabled [55.845] (II) RADEON(0): SwapBuffers wait for vsync: enabled [55.856] (II) RADEON(0): Output DisplayPort-1 has no monitor section [55.858] (II) RADEON(0): Output HDMI-3 has no monitor section [55.861] (II) RA
[PATCH 0/9] Doc/DT: DT bindings for various display components
Hi Rob, On 10/03/14 18:05, Rob Herring wrote: >> Russell's point was that these connector bindings are very generic, i.e. >> they are not for any particular chip from a particular vendor, but for >> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we >> shouldn't define such generic bindings without consulting the whole >> device-tree community (i.e including non-linux users). > > So re-work it to be generic and send it out. DT maintainers would > rarely disagree that something shouldn't be made generic. They (in this series) are already designed to be generic. I should perhaps re-word the question: we are concerned whether these bindings are good for all the users, not just us, and whether there already exists something that overlaps. Afaik, there's nothing overlapping. And I don't see why they wouldn't be good for all users (with the few minor modifications that have been discussed in this thread). But, if I gathered right, Russell would like some kind of ack from someone who might know better than us. So is it enough to have posted these, and gotten acks from the people involved, or should we get acks from DT maintainers also? Is there a way to get the attention of, say, BSD people, or should we just presume they'll follow the list? >> So the question is, is there such a community and a forum to bring up >> this kind of things? If yes, should we bring this up there? If yes, what >> kind of things in general should be brought into the attention of >> non-linux users? > > devicetree list is just that. It is not just for Linux. There is the > newly created devicetree-spec at vger.kernel.org which is for more > core/common binding discussion. Ok. >> What I wonder here is that while a thing like DVI connector is, of >> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the >> case still the same: we're defining global bindings for hardware that >> should work for everyone, not only Linux users? > > Defining the connectors in DT is a useful thing although mainly when > you have multiple connectors of the same type. Labels for composite, > SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or > printed label (like front vs. rear connections) seem more useful to > me. My point above was that it feels mentally easier to define bindings for one particular IP block or chip, than defining bindings for a more generic thing like "HDMI connector". But, in the end, I believe they both should go through similar review, and there's no such difference. As for the labels, they can be anything that makes sense for that particular board. It can be "HDMI Front", if such makes sense, or "HDMI-2" if the connector has such physical printed label. Or, say, "Main LCD", "Secondary LCD". It's a free form text that is given to the user. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140310/d894abf5/attachment.pgp>
[PATCH] drm/edid: Remove part of the HDTV hack
The part which turns 1360x765 into 1366x768 breaks this mode on a
Toshiba TV here. 1360x765 works fine, though.
Reviewed-by: Adam Jackson
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/drm_edid.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b924306..7527f48 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1628,8 +1628,7 @@ drm_mode_std(struct drm_connector *connector, struct edid
*edid,
/* HDTV hack, part 1 */
if (vrefresh_rate == 60 &&
- ((hsize == 1360 && vsize == 765) ||
-(hsize == 1368 && vsize == 769))) {
+ (hsize == 1368 && vsize == 769)) {
hsize = 1366;
vsize = 768;
}
--
1.9.0.279.gdc9e3eb
[PATCH 0/9] Doc/DT: DT bindings for various display components
On Mon, Mar 10, 2014 at 11:40 AM, Tomi Valkeinen wrote: > Hi Rob, > > On 10/03/14 18:05, Rob Herring wrote: > >>> Russell's point was that these connector bindings are very generic, i.e. >>> they are not for any particular chip from a particular vendor, but for >>> any connector for DVI, HDMI or analog-tv. And he's worried that maybe we >>> shouldn't define such generic bindings without consulting the whole >>> device-tree community (i.e including non-linux users). >> >> So re-work it to be generic and send it out. DT maintainers would >> rarely disagree that something shouldn't be made generic. > > They (in this series) are already designed to be generic. > > I should perhaps re-word the question: we are concerned whether these > bindings are good for all the users, not just us, and whether there > already exists something that overlaps. Given this is tied into the rest of video description with endpoints and such, you really have to look at the whole picture to answer that question. I'd guess Linux well ahead of other OSs in terms of dealing with the plethora of video and graphics h/w. I'd be more concerned that the bindings are good for all h/w rather than all OS's. > Afaik, there's nothing overlapping. And I don't see why they wouldn't be > good for all users (with the few minor modifications that have been > discussed in this thread). But, if I gathered right, Russell would like > some kind of ack from someone who might know better than us. > > So is it enough to have posted these, and gotten acks from the people > involved, or should we get acks from DT maintainers also? We really leave it up to the subsystem maintainers to decide, but for new common/generic bindings it is a good idea to get DT maintainers ack. I'll go thru the individual patches. > Is there a way to get the attention of, say, BSD people, or should we > just presume they'll follow the list? devicetree-spec was created specifically to have a lower volume list without a bunch of Linux driver patches which aren't relevant to people from other OSs. >>> So the question is, is there such a community and a forum to bring up >>> this kind of things? If yes, should we bring this up there? If yes, what >>> kind of things in general should be brought into the attention of >>> non-linux users? >> >> devicetree list is just that. It is not just for Linux. There is the >> newly created devicetree-spec at vger.kernel.org which is for more >> core/common binding discussion. > > Ok. > >>> What I wonder here is that while a thing like DVI connector is, of >>> course, more generic than, say, "ti,tfp410" encoder chip, but isn't the >>> case still the same: we're defining global bindings for hardware that >>> should work for everyone, not only Linux users? >> >> Defining the connectors in DT is a useful thing although mainly when >> you have multiple connectors of the same type. Labels for composite, >> SVideo, VGA, DVI, HDMI seem less useful to me. Describing position or >> printed label (like front vs. rear connections) seem more useful to >> me. > > My point above was that it feels mentally easier to define bindings for > one particular IP block or chip, than defining bindings for a more > generic thing like "HDMI connector". But, in the end, I believe they > both should go through similar review, and there's no such difference. Unless you need to describe different types of HDMI connectors, I don't see any issue with it being generic. I certainly don't see the need for prepending with "linux," in this case. Rob
[PATCH 3/9] Doc/DT: Add DT binding documentation for DVI Connector
On Fri, Feb 28, 2014 at 10:25 AM, Philipp Zabel
wrote:
> Am Freitag, den 28.02.2014, 15:59 + schrieb Russell King - ARM
> Linux:
>> On Fri, Feb 28, 2014 at 02:20:10PM +0200, Tomi Valkeinen wrote:
>> > Add DT binding documentation for DVI Connector.
>> >
>> > Signed-off-by: Tomi Valkeinen
>> > Reviewed-by: Archit Taneja
>> > ---
>> > .../devicetree/bindings/video/dvi-connector.txt| 26
>> > ++
>> > 1 file changed, 26 insertions(+)
>> > create mode 100644
>> > Documentation/devicetree/bindings/video/dvi-connector.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt
>> > b/Documentation/devicetree/bindings/video/dvi-connector.txt
>> > new file mode 100644
>> > index ..6a0aff866c78
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
>> > @@ -0,0 +1,26 @@
>> > +DVI Connector
>> > +==
>> > +
>> > +Required properties:
>> > +- compatible: "dvi-connector"
>> > +
>> > +Optional properties:
>> > +- label: a symbolic name for the connector
>> > +- i2c-bus: phandle to the i2c bus that is connected to DVI DDC
>> > +
>> > +Required nodes:
>> > +- Video port for DVI input
>> > +
>> > +Example
>> > +---
>> > +
>> > +dvi0: connector at 0 {
>> > + compatible = "dvi-connector";
>> > + label = "dvi";
>> > +
>> > + i2c-bus = <&i2c3>;
>> > +
>> > + dvi_connector_in: endpoint {
>> > + remote-endpoint = <&tfp410_out>;
>> > + };
>> > +};
>>
>> This looks far too simplistic. There are different classes of DVI
>> connector - there is:
>>
>> DVI A - analogue only
>> DVI D - digital only (single and dual link)
>> DVI I - both (single and dual digital link)
>>
>> DRM at least makes a distinction between these three classes, and this
>> disctinction is part of the user API. How would a display system know
>> which kind of DVI connector is wired up on the board from this DT
>> description?
>
> Maybe this could be inferred from the sources connected to it. For
> example a i.MX5 board with the SoC internal TV Encoder and an external
> SiI902x HDMI encoder connected to the same DVI I connector:
>
> ipu {
> port at 2 {
> ipu_di0_disp0: endpoint {
> remote-endpoint = <&sii902x_in>;
> };
> };
> port at 3 {
> ipu_di1_tve: endpoint {
> remote-endpoint = <&tve_in>;
> };
> };
> };
>
> &sii902x {
> compatible = "si,sii9022";
>
> port at 0 {
> sii902x_in: endpoint {
> remote-endpoint = <&ipu_di0>;
> };
> };
> port at 1 {
> sii902x_out: endpoint {
> remote-endpoint = <&dvi_d_in>;
> };
> };
> };
>
> &tve {
> compatible = "fsl,imx53-tve";
> port at 0 {
> tve_in: endpoint {
> remote-endpoint = <&ipu_di1>;
> };
> };
> port at 1 {
> tve_out: endpoint {
> remote-endpoint = <&dvi_a_in>;
> };
> };
> };
>
> dvi-connector {
> compatible = "dvi-connector";
> ddc-i2c-bus = <&i2c3>;
>
> port {
> dvi_d_in: endpoint at 0 {
> remote-endpoint = <&sii902x_out>;
> };
> dvi_a_in: endpoint at 1 {
> remote-endpoint = <&tve_out>;
> };
> };
> };
>
> It should be possible to let the connector know that those two endpoints
> are connected to a TMDS source and to a VGA source, respectively.
I like this proposal over the others. Although, would dual link be a
single endpoint or 2 endpoints? How would you differentiate that?
The port node seems a bit pointless.
Rob
[BUG] 3.14-rc6 problems with an R7 260X
On Monday 10 March 2014 12:38:42 Alex Deucher wrote: > On Mon, Mar 10, 2014 at 11:47 AM, Ed Tomlinson wrote: > > Hi, > > > > I recently added a R7 260X to my system. While the card works with 3.13 > > its supposed work much better with 14-rc. > > This is not the case. My system is unstable without radeon.dpm=0 which was > > the default in .13. Here are some extracts > > from the logs of the latest fun with dpm enabled: omitted > > The above type of errors repeat hundreds of times and eventually the > > display freezes (this box does not have a serial console and it did not > > check with ssh) > > > > When X started I did notice some corruption. There are sets of two > > rectangles about of a height of 2 or 3 mm, width of 25m or so with a second > > about a cm below. The often occurs in chomium especially when scrolling. > > Runing the unigine-sanctuary or unigine-tropics demo/benchmark > > programs also produce the above problems and eventually stall. > > > > The problem is reproducible - I am not that familiar with gpu problems > > though, what else will help debug this? > > > > Please file a bug at https://bugs.freedesktop.org (Product: DRI, > Component: DRM/Radeon) and attach your dmesg output and xorg log. Filed as bug 75992 Let me know if you want me to test anything or if more info is needed. TIA Ed
[PATCH] drm/exynos: add phy settings for RB resolutions
below is list of pixel clocks and resoluitons
this patch adds:
7100 - 1280x800 at 60Hz RB
7325 - 800x600 at 120Hz RB
8875 - 1440x900 at 60Hz RB
11550 - 1024x768 at 120Hz RB
11900 - 1680x1050 at 60Hz RB
without these pixel clocks' support the mentioned
resolutions fail to be detected in exynos5250.
Signed-off-by: Shirish S
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 45 ++
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index c021ddc..650ce48 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -303,6 +303,24 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] =
{
},
},
{
+ .pixel_clock = 7100,
+ .conf = {
+ 0x01, 0x91, 0x1E, 0x15, 0x40, 0x3C, 0xCE, 0x08,
+ 0x04, 0x20, 0xB2, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+ 0x54, 0xAD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 7325,
+ .conf = {
+ 0x01, 0xD1, 0x1F, 0x15, 0x40, 0x18, 0xE9, 0x08,
+ 0x02, 0xA0, 0xB7, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+ 0x54, 0xA8, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
.pixel_clock = 74176000,
.conf = {
0x01, 0xd1, 0x3e, 0x35, 0x40, 0x5b, 0xde, 0x08,
@@ -330,6 +348,15 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] =
{
},
},
{
+ .pixel_clock = 8875,
+ .conf = {
+ 0x01, 0x91, 0x25, 0x17, 0x40, 0x30, 0xFE, 0x08,
+ 0x06, 0x20, 0xDE, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+ 0x54, 0x8A, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
.pixel_clock = 10650,
.conf = {
0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
@@ -348,6 +375,24 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] =
{
},
},
{
+ .pixel_clock = 11550,
+ .conf = {
+ 0x01, 0xD1, 0x30, 0x1A, 0x40, 0x40, 0x10, 0x04,
+ 0x04, 0xA0, 0x21, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+ 0x54, 0xAA, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
+ .pixel_clock = 11900,
+ .conf = {
+ 0x01, 0x91, 0x32, 0x14, 0x40, 0x60, 0xD8, 0x08,
+ 0x06, 0x20, 0x2A, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
+ 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+ 0x54, 0x9D, 0x25, 0x03, 0x00, 0x00, 0x01, 0x80,
+ },
+ },
+ {
.pixel_clock = 14625,
.conf = {
0x01, 0xd1, 0x3d, 0x15, 0x40, 0x18, 0xfd, 0x08,
--
1.7.10.4
