[PATCHv15 15/15] cec: add ARC and CDC support
From: Hans Verkuil
Preliminary ARC and CDC support. Untested and experimental!
Signed-off-by: Hans Verkuil
---
.../DocBook/media/v4l/cec-ioc-adap-g-caps.xml | 10 ++
Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 36
Documentation/cec.txt | 75
drivers/staging/media/cec/cec.c| 198 -
include/linux/cec.h| 5 +
include/media/cec.h| 12 ++
6 files changed, 334 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml
b/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml
index b99ed22..65250b7 100644
--- a/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml
+++ b/Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml
@@ -129,6 +129,16 @@
The CEC hardware can monitor all messages, not just directed
and
broadcast messages.
+
+ CEC_CAP_ARC
+ 0x0040
+ This adapter supports the Audio Return Channel
protocol.
+
+
+ CEC_CAP_CDC_HPD
+ 0x0080
+ This adapter supports the hotplug detect protocol over
CDC.
+
diff --git a/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml
b/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml
index 0cb1941..485e8b2 100644
--- a/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml
+++ b/Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml
@@ -187,6 +187,42 @@ The follower can of course always call
&CEC-TRANSMIT;.
&cs-def;
+ CEC_MSG_INITIATE_ARC
+
+
+
+ CEC_MSG_TERMINATE_ARC
+
+
+
+ CEC_MSG_REQUEST_ARC_INITIATION
+
+
+
+ CEC_MSG_REQUEST_ARC_TERMINATION
+
+
+
+ CEC_MSG_REPORT_ARC_INITIATED
+
+
+
+ CEC_MSG_REPORT_ARC_TERMINATED
+ If CEC_CAP_ARC is not set, then just
pass
+ it on to userspace for processing. However, if
CEC_CAP_ARC is
+ set, then the core framework processes this message and userspace
will
+ not see it, not even in passthrough mode.
+
+
+ CEC_MSG_CDC_MESSAGE
+ If CEC_CAP_CDC_HPD is not set, then
just pass
+ it on to userspace for processing. Do the same if the CDC command
is not
+ one of CEC_MSG_CDC_HPD_REPORT_STATE or
+ CEC_MSG_CDC_HPD_SET_STATE. Else the core
framework
+ processes this message and userspace will not see it, not even in
passthrough
+ mode.
+
+
CEC_MSG_GET_CEC_VERSION
When in passthrough mode this message has to be handled by
userspace,
otherwise the core will return the CEC version that was set with
&CEC-ADAP-S-LOG-ADDRS;.
diff --git a/Documentation/cec.txt b/Documentation/cec.txt
index 75155fe..8a61819 100644
--- a/Documentation/cec.txt
+++ b/Documentation/cec.txt
@@ -216,6 +216,16 @@ struct cec_adap_ops {
/* High-level CEC message callback */
int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
+
+ /* High-level CDC Hotplug Detect callbacks */
+ u8 (*source_cdc_hpd)(struct cec_adapter *adap, u8 cdc_hpd_state);
+ void (*sink_cdc_hpd)(struct cec_adapter *adap, u8 cdc_hpd_state, u8
cdc_hpd_error);
+
+ /* High-level Audio Return Channel callbacks */
+ int (*sink_initiate_arc)(struct cec_adapter *adap);
+ int (*sink_terminate_arc)(struct cec_adapter *adap);
+ int (*source_arc_initiated)(struct cec_adapter *adap);
+ int (*source_arc_terminated)(struct cec_adapter *adap);
};
The received() callback allows the driver to optionally handle a newly
@@ -228,6 +238,62 @@ callback. If it doesn't want to handle this message, then
it should return
-ENOMSG, otherwise the CEC framework assumes it processed this message and
it will not no anything with it.
+The other callbacks deal with two CEC features: CDC Hotplug Detect and
+Audio Return Channel. Here the framework takes care of handling these
+messages and it calls the callbacks to notify the driver when it needs
+to take action.
+
+CDC Hotplug Support
+---
+
+A source received a hotplug state change message:
+
+ u8 (*source_cdc_hpd)(struct cec_adapter *adap, u8 cdc_hpd_state);
+
+A source received a CEC_MSG_CDC_HPD_SET_STATE message. The framework will
+reply with a CEC_MSG_CDC_HPD_REPORT_STATE message and this callback is used
+to fill in the HPD Error Code Operand of the REPORT_STATE message. In addition,
+the driver can act in this callback on the hotplug state change.
+
+Only implement if CEC_CAP_CDC_HPD is set.
+
+A sink received a hotplug report state message:
+
+ void (*sink_cdc_hpd)(struct cec_adapter *adap, u8 cd
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> Add some utility functions for struct drm_clip_rect.
Looks like mostly you're just duplicating the drm_rect stuff. Why can't
you use what's there already?
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_rect.c | 67
> include/drm/drm_rect.h | 69
> ++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index a8e2c86..a9fb1a8 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> }
> }
> EXPORT_SYMBOL(drm_rect_rotate_inv);
> +
> +/**
> + * drm_clip_rect_intersect - intersect two clip rectangles
> + * @r1: first clip rectangle
> + * @r2: second clip rectangle
> + *
> + * Calculate the intersection of clip rectangles @r1 and @r2.
> + * @r1 will be overwritten with the intersection.
> + *
> + * RETURNS:
> + * %true if rectangle @r1 is still visible after the operation,
> + * %false otherwise.
> + */
> +bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
> + const struct drm_clip_rect *r2)
> +{
> + r1->x1 = max(r1->x1, r2->x1);
> + r1->y1 = max(r1->y1, r2->y1);
> + r1->x2 = min(r1->x2, r2->x2);
> + r1->y2 = min(r1->y2, r2->y2);
> +
> + return drm_clip_rect_visible(r1);
> +}
> +EXPORT_SYMBOL(drm_clip_rect_intersect);
> +
> +/**
> + * drm_clip_rect_merge - Merge clip rectangles
> + * @dst: destination clip rectangle
> + * @src: source clip rectangle(s), can be NULL
> + * @num_clips: number of source clip rectangles
> + * @flags: drm_mode_fb_dirty_cmd flags (DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> + * @width: width of clip rectangle if @src is NULL
> + * @height: height of clip rectangle if @src is NULL
> + *
> + * The dirtyfb ioctl allows for a NULL clip rectangle to be passed in,
> + * so if @src is NULL, width and height is used to set a full clip rectangle.
> + * @dst takes part in the merge unless it is empty {0,0,0,0}.
> + */
> +void drm_clip_rect_merge(struct drm_clip_rect *dst,
> + struct drm_clip_rect *src, unsigned num_clips,
> + unsigned flags, u32 width, u32 height)
> +{
> + int i;
> +
> + if (!src || !num_clips) {
> + dst->x1 = 0;
> + dst->x2 = width;
> + dst->y1 = 0;
> + dst->y2 = height;
> + return;
> + }
> +
> + if (drm_clip_rect_is_empty(dst)) {
> + dst->x1 = ~0;
> + dst->y1 = ~0;
> + }
> +
> + for (i = 0; i < num_clips; i++) {
> + if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> + i++;
> + dst->x1 = min(dst->x1, src[i].x1);
> + dst->x2 = max(dst->x2, src[i].x2);
> + dst->y1 = min(dst->y1, src[i].y1);
> + dst->y2 = max(dst->y2, src[i].y2);
> + }
> +}
> +EXPORT_SYMBOL(drm_clip_rect_merge);
> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> index 83bb156..936ad8d 100644
> --- a/include/drm/drm_rect.h
> +++ b/include/drm/drm_rect.h
> @@ -24,6 +24,8 @@
> #ifndef DRM_RECT_H
> #define DRM_RECT_H
>
> +#include
> +
> /**
> * DOC: rect utils
> *
> @@ -171,4 +173,71 @@ void drm_rect_rotate_inv(struct drm_rect *r,
>int width, int height,
>unsigned int rotation);
>
> +/**
> + * drm_clip_rect_width - determine the clip rectangle width
> + * @r: clip rectangle whose width is returned
> + *
> + * RETURNS:
> + * The width of the clip rectangle.
> + */
> +static inline int drm_clip_rect_width(const struct drm_clip_rect *r)
> +{
> + return r->x2 - r->x1;
> +}
> +
> +/**
> + * drm_clip_rect_height - determine the clip rectangle height
> + * @r: clip rectangle whose height is returned
> + *
> + * RETURNS:
> + * The height of the clip rectangle.
> + */
> +static inline int drm_clip_rect_height(const struct drm_clip_rect *r)
> +{
> + return r->y2 - r->y1;
> +}
> +
> +/**
> + * drm_clip_rect_visible - determine if the the clip rectangle is visible
> + * @r: clip rectangle whose visibility is returned
> + *
> + * RETURNS:
> + * %true if the clip rectangle is visible, %false otherwise.
> + */
> +static inline bool drm_clip_rect_visible(const struct drm_clip_rect *r)
> +{
> + return drm_clip_rect_width(r) > 0 && drm_clip_rect_height(r) > 0;
> +}
> +
> +/**
> + * drm_clip_rect_reset - Reset clip rectangle
> + * @clip: clip rectangle
> + *
> + * Sets clip rectangle to {0,0,0,0}.
> + */
> +static inline void drm_clip_rect_reset(struct drm_clip_rect *clip)
> +{
> + clip->x1 = 0;
> + clip->x2 = 0;
> + clip->y1 = 0;
> + clip->y2 = 0;
> +}
> +
> +/**
> + * drm_clip_rect_is_empty - Is clip rectangle empty?
> + * @clip: clip rectangle
> + *
> + * Returns true if clip rectangle is {0,0,0,0}.
> + */
> +static inline bool drm_cli
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
Den 25.04.2016 14:39, skrev Ville Syrjälä:
> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
>> Add some utility functions for struct drm_clip_rect.
> Looks like mostly you're just duplicating the drm_rect stuff. Why can't
> you use what's there already?
That's because the framebuffer flushing uses drm_clip_rect and not drm_rect:
struct drm_framebuffer_funcs {
[...]
int (*dirty)(struct drm_framebuffer *framebuffer,
struct drm_file *file_priv, unsigned flags,
unsigned color, struct drm_clip_rect *clips,
unsigned num_clips);
};
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/drm_rect.c | 67
>>
>> include/drm/drm_rect.h | 69
>> ++
>> 2 files changed, 136 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
>> index a8e2c86..a9fb1a8 100644
>> --- a/drivers/gpu/drm/drm_rect.c
>> +++ b/drivers/gpu/drm/drm_rect.c
>> @@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
>> }
>> }
>> EXPORT_SYMBOL(drm_rect_rotate_inv);
>> +
>> +/**
>> + * drm_clip_rect_intersect - intersect two clip rectangles
>> + * @r1: first clip rectangle
>> + * @r2: second clip rectangle
>> + *
>> + * Calculate the intersection of clip rectangles @r1 and @r2.
>> + * @r1 will be overwritten with the intersection.
>> + *
>> + * RETURNS:
>> + * %true if rectangle @r1 is still visible after the operation,
>> + * %false otherwise.
>> + */
>> +bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
>> + const struct drm_clip_rect *r2)
>> +{
>> +r1->x1 = max(r1->x1, r2->x1);
>> +r1->y1 = max(r1->y1, r2->y1);
>> +r1->x2 = min(r1->x2, r2->x2);
>> +r1->y2 = min(r1->y2, r2->y2);
>> +
>> +return drm_clip_rect_visible(r1);
>> +}
>> +EXPORT_SYMBOL(drm_clip_rect_intersect);
>> +
>> +/**
>> + * drm_clip_rect_merge - Merge clip rectangles
>> + * @dst: destination clip rectangle
>> + * @src: source clip rectangle(s), can be NULL
>> + * @num_clips: number of source clip rectangles
>> + * @flags: drm_mode_fb_dirty_cmd flags (DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
>> + * @width: width of clip rectangle if @src is NULL
>> + * @height: height of clip rectangle if @src is NULL
>> + *
>> + * The dirtyfb ioctl allows for a NULL clip rectangle to be passed in,
>> + * so if @src is NULL, width and height is used to set a full clip
>> rectangle.
>> + * @dst takes part in the merge unless it is empty {0,0,0,0}.
>> + */
>> +void drm_clip_rect_merge(struct drm_clip_rect *dst,
>> + struct drm_clip_rect *src, unsigned num_clips,
>> + unsigned flags, u32 width, u32 height)
>> +{
>> +int i;
>> +
>> +if (!src || !num_clips) {
>> +dst->x1 = 0;
>> +dst->x2 = width;
>> +dst->y1 = 0;
>> +dst->y2 = height;
>> +return;
>> +}
>> +
>> +if (drm_clip_rect_is_empty(dst)) {
>> +dst->x1 = ~0;
>> +dst->y1 = ~0;
>> +}
>> +
>> +for (i = 0; i < num_clips; i++) {
>> +if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
>> +i++;
>> +dst->x1 = min(dst->x1, src[i].x1);
>> +dst->x2 = max(dst->x2, src[i].x2);
>> +dst->y1 = min(dst->y1, src[i].y1);
>> +dst->y2 = max(dst->y2, src[i].y2);
>> +}
>> +}
>> +EXPORT_SYMBOL(drm_clip_rect_merge);
>> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
>> index 83bb156..936ad8d 100644
>> --- a/include/drm/drm_rect.h
>> +++ b/include/drm/drm_rect.h
>> @@ -24,6 +24,8 @@
>> #ifndef DRM_RECT_H
>> #define DRM_RECT_H
>>
>> +#include
>> +
>> /**
>>* DOC: rect utils
>>*
>> @@ -171,4 +173,71 @@ void drm_rect_rotate_inv(struct drm_rect *r,
>> int width, int height,
>> unsigned int rotation);
>>
>> +/**
>> + * drm_clip_rect_width - determine the clip rectangle width
>> + * @r: clip rectangle whose width is returned
>> + *
>> + * RETURNS:
>> + * The width of the clip rectangle.
>> + */
>> +static inline int drm_clip_rect_width(const struct drm_clip_rect *r)
>> +{
>> +return r->x2 - r->x1;
>> +}
>> +
>> +/**
>> + * drm_clip_rect_height - determine the clip rectangle height
>> + * @r: clip rectangle whose height is returned
>> + *
>> + * RETURNS:
>> + * The height of the clip rectangle.
>> + */
>> +static inline int drm_clip_rect_height(const struct drm_clip_rect *r)
>> +{
>> +return r->y2 - r->y1;
>> +}
>> +
>> +/**
>> + * drm_clip_rect_visible - determine if the the clip rectangle is visible
>> + * @r: clip rectangle whose visibility is returned
>> + *
>> + * RETURNS:
>> + * %true if the clip rectangle is visible, %false otherwise.
>> + */
>> +static inline bool drm_clip_rect_visible(const struct drm_clip_rect *r)
>> +{
>> +return drm_clip_rect_width(r) > 0 && drm_clip_r
[Bug 117171] New: Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 Bug ID: 117171 Summary: Radeon GPU lockup in X windows after resuming from blank screen Product: Drivers Version: 2.5 Kernel Version: 4.6 rc5 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc5 -wily/ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: erik.brangs at gmx.de Regression: No Created attachment 213991 --> https://bugzilla.kernel.org/attachment.cgi?id=213991&action=edit dmesg output acquired from frozen system with GPU lockup I'm using Ubuntu 16.04 with the 4.6 rc5 kernel build from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc5-wily/ . AFAIK this is a mainline kernel with an Ubuntu configuration. Sometimes, when I'm using X windows and resuming from a blank screen, X windows freezes: The previous screen content is properly restored but X windows locks up and ceases to process inputs. The system isn't completely frozen, though: I can still SSH into it. In this case, the dmesg log doesn't have any message about the lockup at the end and the of the Xorg log only has entries about mieq overflowing. This behaviour has been present as long as I have actually tried to get some debugging output. At other times, I can still attempt to switch to the terminal. In that case, the system locks up after the X windows screen content has been removed but before the terminal is shown, e.g. the screen content consists of a single colour. In that case, the tail of the dmesg output contained some lines about GPU lockup: [ 9553.364081] radeon :01:00.0: ring 0 stalled for more than 10440msec [ 9553.364093] radeon :01:00.0: GPU lockup (current fence id 0x9b9e last fence id 0x9b9f on ring 0) [ 9553.368211] radeon :01:00.0: Saved 215675 dwords of commands on ring 0. [ 9553.369258] radeon :01:00.0: GPU reset succeeded, trying to resume [ 9553.369272] radeon :01:00.0: 880035298800 unpin not necessary [ 9553.385589] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 9553.386659] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 9553.38] radeon :01:00.0: WB enabled [ 9553.386672] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x0800 and cpu addr 0x880034dee000 [ 9553.386721] [drm] radeon: ring at 0x08001000 [ 9553.941187] [drm:r100_ring_test [radeon]] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 9553.941220] [drm:r100_cp_init [radeon]] *ERROR* radeon: cp isn't working (-22). [ 9553.941224] radeon :01:00.0: failed initializing CP (-22). I don't think that this is a regression because I haven seen freezes like this for a long time (since before the 4.x series). The basic problem (i.e. lockup of X windows) hasn't changed in that time. The frequency of occurence and the timing of the lockup seem to vary based on the kernel version. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117171] Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 --- Comment #1 from erik.brangs at gmx.de --- Created attachment 214001 --> https://bugzilla.kernel.org/attachment.cgi?id=214001&action=edit Xorg log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117171] Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 --- Comment #2 from erik.brangs at gmx.de --- Created attachment 214011 --> https://bugzilla.kernel.org/attachment.cgi?id=214011&action=edit glxinfo from working system -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> > On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> >> Add some utility functions for struct drm_clip_rect.
> > Looks like mostly you're just duplicating the drm_rect stuff. Why can't
> > you use what's there already?
>
> That's because the framebuffer flushing uses drm_clip_rect and not drm_rect:
Converting to drm_rect is not an option?
>
> struct drm_framebuffer_funcs {
> [...]
> int (*dirty)(struct drm_framebuffer *framebuffer,
> struct drm_file *file_priv, unsigned flags,
> unsigned color, struct drm_clip_rect *clips,
> unsigned num_clips);
> };
>
> >> Signed-off-by: Noralf Trønnes
> >> ---
> >> drivers/gpu/drm/drm_rect.c | 67
> >>
> >> include/drm/drm_rect.h | 69
> >> ++
> >> 2 files changed, 136 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> >> index a8e2c86..a9fb1a8 100644
> >> --- a/drivers/gpu/drm/drm_rect.c
> >> +++ b/drivers/gpu/drm/drm_rect.c
> >> @@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> >>}
> >> }
> >> EXPORT_SYMBOL(drm_rect_rotate_inv);
> >> +
> >> +/**
> >> + * drm_clip_rect_intersect - intersect two clip rectangles
> >> + * @r1: first clip rectangle
> >> + * @r2: second clip rectangle
> >> + *
> >> + * Calculate the intersection of clip rectangles @r1 and @r2.
> >> + * @r1 will be overwritten with the intersection.
> >> + *
> >> + * RETURNS:
> >> + * %true if rectangle @r1 is still visible after the operation,
> >> + * %false otherwise.
> >> + */
> >> +bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
> >> + const struct drm_clip_rect *r2)
> >> +{
> >> + r1->x1 = max(r1->x1, r2->x1);
> >> + r1->y1 = max(r1->y1, r2->y1);
> >> + r1->x2 = min(r1->x2, r2->x2);
> >> + r1->y2 = min(r1->y2, r2->y2);
> >> +
> >> + return drm_clip_rect_visible(r1);
> >> +}
> >> +EXPORT_SYMBOL(drm_clip_rect_intersect);
> >> +
> >> +/**
> >> + * drm_clip_rect_merge - Merge clip rectangles
> >> + * @dst: destination clip rectangle
> >> + * @src: source clip rectangle(s), can be NULL
> >> + * @num_clips: number of source clip rectangles
> >> + * @flags: drm_mode_fb_dirty_cmd flags (DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> >> + * @width: width of clip rectangle if @src is NULL
> >> + * @height: height of clip rectangle if @src is NULL
> >> + *
> >> + * The dirtyfb ioctl allows for a NULL clip rectangle to be passed in,
> >> + * so if @src is NULL, width and height is used to set a full clip
> >> rectangle.
> >> + * @dst takes part in the merge unless it is empty {0,0,0,0}.
> >> + */
> >> +void drm_clip_rect_merge(struct drm_clip_rect *dst,
> >> + struct drm_clip_rect *src, unsigned num_clips,
> >> + unsigned flags, u32 width, u32 height)
> >> +{
> >> + int i;
> >> +
> >> + if (!src || !num_clips) {
> >> + dst->x1 = 0;
> >> + dst->x2 = width;
> >> + dst->y1 = 0;
> >> + dst->y2 = height;
> >> + return;
> >> + }
> >> +
> >> + if (drm_clip_rect_is_empty(dst)) {
> >> + dst->x1 = ~0;
> >> + dst->y1 = ~0;
> >> + }
> >> +
> >> + for (i = 0; i < num_clips; i++) {
> >> + if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> >> + i++;
> >> + dst->x1 = min(dst->x1, src[i].x1);
> >> + dst->x2 = max(dst->x2, src[i].x2);
> >> + dst->y1 = min(dst->y1, src[i].y1);
> >> + dst->y2 = max(dst->y2, src[i].y2);
> >> + }
> >> +}
> >> +EXPORT_SYMBOL(drm_clip_rect_merge);
> >> diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
> >> index 83bb156..936ad8d 100644
> >> --- a/include/drm/drm_rect.h
> >> +++ b/include/drm/drm_rect.h
> >> @@ -24,6 +24,8 @@
> >> #ifndef DRM_RECT_H
> >> #define DRM_RECT_H
> >>
> >> +#include
> >> +
> >> /**
> >>* DOC: rect utils
> >>*
> >> @@ -171,4 +173,71 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> >> int width, int height,
> >> unsigned int rotation);
> >>
> >> +/**
> >> + * drm_clip_rect_width - determine the clip rectangle width
> >> + * @r: clip rectangle whose width is returned
> >> + *
> >> + * RETURNS:
> >> + * The width of the clip rectangle.
> >> + */
> >> +static inline int drm_clip_rect_width(const struct drm_clip_rect *r)
> >> +{
> >> + return r->x2 - r->x1;
> >> +}
> >> +
> >> +/**
> >> + * drm_clip_rect_height - determine the clip rectangle height
> >> + * @r: clip rectangle whose height is returned
> >> + *
> >> + * RETURNS:
> >> + * The height of the clip rectangle.
> >> + */
> >> +static inline int drm_clip_rect_height(const struct drm_clip_rect *r)
> >> +{
> >> + return r->y2 - r->y1;
> >> +}
> >> +
> >> +/**
> >> + * drm_clip_rect_visible - deter
[PATCH] drm: rcar: remove unused variable
A cleanup for the rcar-du driver left an unused variable behind:
drm/rcar-du/rcar_du_drv.c: In function 'rcar_du_probe':
drm/rcar-du/rcar_du_drv.c:300:24: error: unused variable 'connector'
[-Werror=unused-variable]
This removes the variable.
Signed-off-by: Arnd Bergmann
Fixes: d63c25e4245a ("drm: rcar-du: Use generic drm_connector_register_all()
helper")
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 0f251dc11082..fb9242d27883 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -297,7 +297,6 @@ static int rcar_du_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct rcar_du_device *rcdu;
- struct drm_connector *connector;
struct drm_device *ddev;
struct resource *mem;
int ret;
--
2.7.0
[PATCH v4 00/11] drm: Add Allwinner A10 display engine support
Hi everyone, The Allwinner SoCs (except for the very latest ones) all share the same set of controllers, loosely coupled together to form the display pipeline. Depending on the SoC, the number of instances of the controller will change (2 instances of each in the A10, only one in the A13, for example), and the output availables will change too (HDMI, composite, VGA on the A20, none of them on the A13). On most featured SoCs, it looks like that: ++ |RAM | ++ || || v| |v ++ | | ++ |Frontend| | | |Frontend| ++ | | ++ | | | | v | | v ++ | | ++ |Backend |<+ +>|Backend | ++ ++ | | v v ++ ++---> LVDS | TCON | | TCON |---> RGB ++ ++ | +---+ +---+ | | | | | v v v v ++ ++ ++---> VGA | TV Encoder | |HDMI| | TV Encoder |---> Composite ++ ++ ++ The current code only assumes that there is a single instance of all the controllers. It also supports only the RGB and Composite interfaces. Let me know what you think, Maxime Changes from v3: - Fixed a circular dependency issue found when building as a module - Changed a bit the mode_valid checks - Fixed an issue with the timings generated by the display engine - Changed the DT bindings according to Rob feedback (removed the allwinner,panel property, documented the endpoints indices, always use the frontend as the pipeline entrypoint) - Changed the display clocks according to Stephen comments (marked structures as const, changed a variable name) Changes from v2: - Rebased on top of next-20160318 - Dropped the generic clock regmap conversion and implemented a custom clock for our pixel clock, backed by a regmap - Added the reset bits for the tcon channel 0 and display clocks - Used the new generic gates compatible for the DRAM gates - Few clock fixes (missing iounmap, return error checks, etc) - Found out that the TCON channel 1 clock was not operating properly because of some weird rounding down and up between the various generic clocks involved. Rewrote it using custom operations - Removed some TODO that were still there - Converted our panel DT description to the OF graph instead of a custom property - Tested the driver on a setup where U-Boot was not initialising the display, or initialising it on a different output, and fixed a number of associated bugs (mostly related to missing initialisation bits, missing reset handles, and so on) - Fixed the layer code that was assuming that the X and Y coordinates were in pixels, leading to a miscalculation of the buffer address when those coordinates where set. - Added the missing EXPORT_SYMBOL calls - Fixed our VBLANK interrupt code that was completely broken (and not usable, which is why it was unnoticed) Changes from v1: - Rebased on top of 4.4 - Merged the clock drivers for the display and TCON channel 0 clocks - Replaced the container_of calls in the display reset clocks to an inline function - Checked the return code of of_clk_parent_fill in the clocks drivers - Checked the return code of of_clk_add_provider in the tcon-ch1 and PLL3 clocks - Added missing clocks headers - Created a composite clock unregister function - Moved the binding documentation to Documentation/devicetree/bindings/display - Added the clocks binding documentation - Added the Olimex vendor to the list of DT vendors - Moved to the OF graph representation and the component framework - Moved the reset cells count check into the reset framework to avoid duplicating the code in every xlate implementation. - Made the reset_ops const - Reworked the DRM cmdline mode parsing code to allow named mode - Fixed the TV mode lookup when the mode name is not present (for example because it was given by the userspace) - Made the driver outputs optional (to avoid crashing when a board doesn't have either a panel or a composite output enabled) - Added multiple plane support with transparency - Moved the backend registers writes commit in the CRTC atomic_flush callback - Removed the load / unload functions - Removed the enabled booleans in my private structure and removed the implicit call to disable_
[PATCH v4 10/11] ARM: sun5i: r8: Add display blocks to the DTSI
The TCON, tv-encoder and display engine backends and frontends are combined
to create our display pipeline.
Add them to the R8 DTSI. It's supposed to be perfectly compatible with the
A10s and A13, but since we haven't tested it on them yet, it's safer to
just enable it on the R8. Eventually, it should be moved to sun5i.dtsi
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-r8.dtsi | 137
1 file changed, 137 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
index 691d3de75b35..a42b5404893e 100644
--- a/arch/arm/boot/dts/sun5i-r8.dtsi
+++ b/arch/arm/boot/dts/sun5i-r8.dtsi
@@ -57,4 +57,141 @@
status = "disabled";
};
};
+
+ soc at 01c0 {
+ tve0: tv-encoder at 01c0a000 {
+ compatible = "allwinner,sun4i-a10-tv-encoder";
+ reg = <0x01c0a000 0x1000>;
+ clocks = <&ahb_gates 34>;
+ resets = <&tcon_ch0_clk 0>;
+ status = "disabled";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tve0_in_tcon0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_tve0>;
+ };
+ };
+ };
+
+ tcon0: lcd-controller at 01c0c000 {
+ compatible = "allwinner,sun5i-a13-tcon";
+ reg = <0x01c0c000 0x1000>;
+ interrupts = <44>;
+ resets = <&tcon_ch0_clk 1>;
+ reset-names = "lcd";
+ clocks = <&ahb_gates 36>,
+<&tcon_ch0_clk>,
+<&tcon_ch1_clk>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+ clock-output-names = "tcon-pixel-clock";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon0_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon0_in_be0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint =
<&be0_out_tcon0>;
+ };
+ };
+
+ tcon0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon0_out_tve0: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint =
<&tve0_in_tcon0>;
+ };
+ };
+ };
+ };
+
+ fe0: display-frontend at 01e0 {
+ compatible = "allwinner,sun5i-a13-display-frontend";
+ reg = <0x01e0 0x2>;
+ interrupts = <47>;
+ clocks = <&ahb_gates 46>, <&de_fe_clk>,
+<&dram_gates 25>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&de_fe_clk>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ fe0_out_be0: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&be0_in_fe0>;
+ };
+ };
+ };
+ };
+
+ be0: display-backend at 01e6 {
+ compatible = "allwinner,sun5i-a13-display-backend";
+ reg = <0x01e6 0x1>;
+ clocks = <&ahb_gates 44>, <&de_be_clk>,
+<&dram_gates 26>;
+
[PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver
The A10 SoCs and its relatives has a special clock controller to drive the
display engines (both frontend and backend), that have a lot in common with
the clock to drive the first TCON channel.
Add a driver to support both.
Signed-off-by: Maxime Ripard
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
drivers/clk/sunxi/Makefile| 1 +
drivers/clk/sunxi/clk-sun4i-display.c | 261 ++
3 files changed, 264 insertions(+)
create mode 100644 drivers/clk/sunxi/clk-sun4i-display.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index f70f500256bb..8f7619d8c8d8 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -64,6 +64,7 @@ Required properties:
"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
+ "allwinner,sun4i-a10-display-clk" - for the display clocks on the A10
"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
"allwinner,sun5i-a13-dram-gates-clk" - for the DRAM gates on A13
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
@@ -75,6 +76,7 @@ Required properties:
"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
+ "allwinner,sun4i-a10-tcon-ch0-clk" - for the TCON channel 0 clock on
the A10
"allwinner,sun4i-a10-tcon-ch1-clk" - for the TCON channel 1 clock on
the A10
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
"allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 2d77407a0037..39d2044a1f49 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += clk-a10-ve.o
obj-y += clk-a20-gmac.o
obj-y += clk-mod0.o
obj-y += clk-simple-gates.o
+obj-y += clk-sun4i-display.o
obj-y += clk-sun4i-pll3.o
obj-y += clk-sun4i-tcon-ch1.o
obj-y += clk-sun8i-bus-gates.o
diff --git a/drivers/clk/sunxi/clk-sun4i-display.c
b/drivers/clk/sunxi/clk-sun4i-display.c
new file mode 100644
index ..f02e250e64ed
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun4i-display.c
@@ -0,0 +1,261 @@
+/*
+ * Copyright 2015 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct sun4i_a10_display_clk_data {
+ boolhas_div;
+ u8 num_rst;
+ u8 parents;
+
+ u8 offset_en;
+ u8 offset_div;
+ u8 offset_mux;
+ u8 offset_rst;
+
+ u8 width_div;
+ u8 width_mux;
+};
+
+struct reset_data {
+ void __iomem*reg;
+ spinlock_t *lock;
+ struct reset_controller_dev rcdev;
+ u8 offset;
+};
+
+static DEFINE_SPINLOCK(sun4i_a10_display_lock);
+
+static inline struct reset_data *rcdev_to_reset_data(struct
reset_controller_dev *rcdev)
+{
+ return container_of(rcdev, struct reset_data, rcdev);
+};
+
+static int sun4i_a10_display_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct reset_data *data = rcdev_to_reset_data(rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg & ~BIT(data->offset + id), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static int sun4i_a10_display_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct reset_data *data = rcdev_to_reset_data(rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg | BIT(data->offset + id), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static int sun4i_a10_display_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
[PATCH v4 04/11] drm: sun4i: Add DT bindings documentation
The display pipeline of the Allwinner A10 is involving several loosely
coupled components.
Add a documentation for the bindings.
Signed-off-by: Maxime Ripard
---
.../bindings/display/sunxi/sun4i-drm.txt | 258 +
1 file changed, 258 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
new file mode 100644
index ..5d7b090a97e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -0,0 +1,258 @@
+Allwinner A10 Display Pipeline
+==
+
+The Allwinner A10 Display pipeline is composed of several components
+that are going to be documented below:
+
+TV Encoder
+--
+
+The TV Encoder supports the composite and VGA output. It is one end of
+the pipeline.
+
+Required properties:
+ - compatible: value should be "allwinner,sun4i-a10-tv-encoder".
+ - reg: base address and size of memory-mapped region
+ - clocks: the clocks driving the TV encoder
+ - resets: phandle to the reset controller driving the encoder
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port should be the input endpoint.
+
+TCON
+
+
+The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
+
+Required properties:
+ - compatible: value should be "allwinner,sun5i-a13-tcon".
+ - reg: base address and size of memory-mapped region
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the TCON. Three are needed:
+ - 'ahb': the interface clocks
+ - 'tcon-ch0': The clock driving the TCON channel 0
+ - 'tcon-ch1': The clock driving the TCON channel 1
+ - resets: phandles to the reset controllers driving the encoder
+ - "lcd": the reset line for the TCON channel 0
+
+ - clock-names: the clock names mentioned above
+ - reset-names: the reset names mentioned above
+ - clock-output-names: Name of the pixel clock created
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port should be the input endpoint, the second one the output
+
+ The output should have two endpoints. The first is the block
+ connected to the TCON channel 0 (usually a panel or a bridge), the
+ second the block connected to the TCON channel 1 (usually the TV
+ encoder)
+
+
+Display Engine Backend
+--
+
+The display engine backend exposes layers and sprites to the
+system.
+
+Required properties:
+ - compatible: value must be one of:
+* allwinner,sun5i-a13-display-backend
+ - reg: base address and size of the memory-mapped region.
+ - clocks: phandles to the clocks feeding the frontend and backend
+* ahb: the backend interface clock
+* mod: the backend module clock
+* ram: the backend DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset controllers driving the backend
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port should be the input endpoints, the second one the output
+
+Display Engine Frontend
+---
+
+The display engine frontend does formats conversion, scaling,
+deinterlacing and color space conversion.
+
+Required properties:
+ - compatible: value must be one of:
+* allwinner,sun5i-a13-display-frontend
+ - reg: base address and size of the memory-mapped region.
+ - interrupts: interrupt associated to this IP
+ - clocks: phandles to the clocks feeding the frontend and backend
+* ahb: the backend interface clock
+* mod: the backend module clock
+* ram: the backend DRAM clock
+ - clock-names: the clock names mentioned above
+ - resets: phandles to the reset controllers driving the backend
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port should be the input endpoints, the second one the outputs
+
+
+Display Engine Pipeline
+---
+
+The display engine pipeline (and its entry point, since it can be
+either directly the backend or the frontend) is represented as an
+extra node.
+
+Required properties:
+ - compatible: value must be one of:
+* allwinner,sun5i-a13-display-engine
+
+ - allwinner,pipelines: list of phandle to the display engine
+frontends available.
+
+Example:
+
+panel: panel {
+ compatible = "olimex,lcd-olinuxino-43-ts";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint {
+ remote-endpoint = <&tcon0_out_panel>;
+ };
+
[PATCH v4 08/11] drm: sun4i: tv: Add PAL output standard
Now that we have support for the composite output, we can start adding new
supported standards. Start with PAL, and we will add other eventually.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 42
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 78634dfc0f77..ccf275a90132 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -178,7 +178,49 @@ struct sun4i_tv {
struct sun4i_drv*drv;
};
+struct video_levels pal_video_levels = {
+ .black = 252, .blank = 252,
+};
+
+struct burst_levels pal_burst_levels = {
+ .cb = 40, .cr = 40,
+};
+
+struct color_gains pal_color_gains = {
+ .cb = 224, .cr = 224,
+};
+
+struct resync_parameters pal_resync_parameters = {
+ .field = true, .line = 13, .pixel = 12,
+};
+
struct tv_mode tv_modes[] = {
+ {
+ .name = "PAL",
+ .mode = SUN4I_TVE_CFG0_RES_576i,
+ .chroma_freq= 0x2a098acb,
+
+ .back_porch = 138,
+ .front_porch= 24,
+ .line_number= 625,
+
+ .hdisplay = 720,
+ .hfront_porch = 3,
+ .hsync_len = 2,
+ .hback_porch= 139,
+
+ .vdisplay = 576,
+ .vfront_porch = 28,
+ .vsync_len = 2,
+ .vback_porch= 19,
+
+ .vblank_level = 252,
+
+ .color_gains= &pal_color_gains,
+ .burst_levels = &pal_burst_levels,
+ .video_levels = &pal_video_levels,
+ .resync_params = &pal_resync_parameters,
+ },
};
static inline struct sun4i_tv *
--
2.8.1
[PATCH v4 11/11] ARM: sun5i: chip: Enable the TV Encoder
The CHIP has a composite output available muxed with the microphone in the
micro-jack plug.
Enable the composite output in its DTS.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts
b/arch/arm/boot/dts/sun5i-r8-chip.dts
index f6898c6b84d4..a8d8b4582397 100644
--- a/arch/arm/boot/dts/sun5i-r8-chip.dts
+++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
@@ -66,6 +66,10 @@
};
};
+&be0 {
+ status = "okay";
+};
+
&codec {
status = "okay";
};
@@ -188,6 +192,14 @@
status = "okay";
};
+&tcon0 {
+ status = "okay";
+};
+
+&tve0 {
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
--
2.8.1
[PATCH v4 02/11] ARM: sun5i: a13: Add display and TCON clocks
Enable the display and TCON (channel 0 and channel 1) clocks that are going
to be needed to drive the display engine, tcon and TV encoders.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 39 +--
arch/arm/boot/dts/sun5i-r8.dtsi | 5 +++--
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 39f23b1ebc8f..263d46dbc7e6 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -61,8 +61,8 @@
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
- clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 44>,
-<&dram_gates 26>;
+ clocks = <&ahb_gates 36>, <&ahb_gates 44>, <&de_be_clk>,
+<&tcon_ch0_clk>, <&dram_gates 26>;
status = "disabled";
};
};
@@ -170,6 +170,41 @@
"dram_ace",
"dram_iep";
};
+
+ de_be_clk: clk at 01c20104 {
+ #clock-cells = <0>;
+ #reset-cells = <0>;
+ compatible = "allwinner,sun4i-a10-display-clk";
+ reg = <0x01c20104 0x4>;
+ clocks = <&pll3>, <&pll7>, <&pll5 1>;
+ clock-output-names = "de-be";
+ };
+
+ de_fe_clk: clk at 01c2010c {
+ #clock-cells = <0>;
+ #reset-cells = <0>;
+ compatible = "allwinner,sun4i-a10-display-clk";
+ reg = <0x01c2010c 0x4>;
+ clocks = <&pll3>, <&pll7>, <&pll5 1>;
+ clock-output-names = "de-fe";
+ };
+
+ tcon_ch0_clk: clk at 01c20118 {
+ #clock-cells = <0>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun4i-a10-tcon-ch0-clk";
+ reg = <0x01c20118 0x4>;
+ clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
+ clock-output-names = "tcon-ch0-sclk";
+ };
+
+ tcon_ch1_clk: clk at 01c2012c {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
+ reg = <0x01c2012c 0x4>;
+ clocks = <&pll3>, <&pll7>, <&pll3x2>, <&pll7x2>;
+ clock-output-names = "tcon-ch1-sclk";
+ };
};
soc at 01c0 {
diff --git a/arch/arm/boot/dts/sun5i-r8.dtsi b/arch/arm/boot/dts/sun5i-r8.dtsi
index e346ba76db5d..691d3de75b35 100644
--- a/arch/arm/boot/dts/sun5i-r8.dtsi
+++ b/arch/arm/boot/dts/sun5i-r8.dtsi
@@ -51,8 +51,9 @@
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-tve0";
- clocks = <&pll5 1>, <&ahb_gates 34>, <&ahb_gates 36>,
-<&ahb_gates 44>, <&dram_gates 26>;
+ clocks = <&ahb_gates 34>, <&ahb_gates 36>,
+<&ahb_gates 44>, <&de_be_clk>,
+<&tcon_ch1_clk>, <&dram_gates 26>;
status = "disabled";
};
};
--
2.8.1
[PATCH v4 06/11] drm: sun4i: Add RGB output
One of the A10 display pipeline possible output is an RGB interface to
drive LCD panels directly. This is done through the first channel of the
TCON that will output our video signals directly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 1 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 24
drivers/gpu/drm/sun4i/sun4i_rgb.c | 250 +
drivers/gpu/drm/sun4i/sun4i_rgb.h | 18 +++
drivers/gpu/drm/sun4i/sun4i_tcon.c | 61 -
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 +
6 files changed, 355 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.c
create mode 100644 drivers/gpu/drm/sun4i/sun4i_rgb.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 6df3ef32732d..74f804b88ff5 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -4,6 +4,7 @@ sun4i-drm-y += sun4i_framebuffer.o
sun4i-drm-y += sun4i_layer.o
sun4i-tcon-y += sun4i_tcon.o
+sun4i-tcon-y += sun4i_rgb.o
sun4i-tcon-y += sun4i_dotclock.o
obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index a081969673ac..891d434ea57f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -222,6 +222,11 @@ static bool sun4i_drv_node_is_frontend(struct device_node
*node)
"allwinner,sun5i-a13-display-frontend");
}
+static bool sun4i_drv_node_is_tcon(struct device_node *node)
+{
+ return of_device_is_compatible(node, "allwinner,sun5i-a13-tcon");
+}
+
static int compare_of(struct device *dev, void *data)
{
DRM_DEBUG_DRIVER("Comparing of node %s with %s\n",
@@ -270,6 +275,25 @@ static int sun4i_drv_add_endpoints(struct device *dev,
continue;
}
+ /*
+* If the node is our TCON, the first port is used for our
+* panel, and will not be part of the
+* component framework.
+*/
+ if (sun4i_drv_node_is_tcon(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel...
skipping\n");
+ continue;
+ }
+ }
+
/* Walk down our tree */
count += sun4i_drv_add_endpoints(dev, match, remote);
diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
new file mode 100644
index ..ab6494818050
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -0,0 +1,250 @@
+/*
+ * Copyright (C) 2015 Free Electrons
+ * Copyright (C) 2015 NextThing Co
+ *
+ * Maxime Ripard
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include "sun4i_drv.h"
+#include "sun4i_tcon.h"
+
+struct sun4i_rgb {
+ struct drm_connectorconnector;
+ struct drm_encoder encoder;
+
+ struct sun4i_drv*drv;
+};
+
+static inline struct sun4i_rgb *
+drm_connector_to_sun4i_rgb(struct drm_connector *connector)
+{
+ return container_of(connector, struct sun4i_rgb,
+ connector);
+}
+
+static inline struct sun4i_rgb *
+drm_encoder_to_sun4i_rgb(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct sun4i_rgb,
+ encoder);
+}
+
+static int sun4i_rgb_get_modes(struct drm_connector *connector)
+{
+ struct sun4i_rgb *rgb =
+ drm_connector_to_sun4i_rgb(connector);
+ struct sun4i_drv *drv = rgb->drv;
+ struct sun4i_tcon *tcon = drv->tcon;
+
+ return drm_panel_get_modes(tcon->panel);
+}
+
+static int sun4i_rgb_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ u32 hsync = mode->hsync_end - mode->hsync_start;
+ u32 vsync = mode->vsync_end - mode->vsync_start;
+
+ DRM_DEBUG_DRIVER("Validating modes...\n");
+
+ if (hsync < 1)
+ return MODE_HSYNC_NARROW;
+
+ if (hsync > 0x3ff)
+ return MODE_HSYNC_WIDE;
+
+ if ((mode->hdisplay < 1) || (mode->htotal < 1))
+ return MODE_H_ILLEGAL;
+
+ if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
+ return MODE_BAD_HVALUE;
+
+ DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
+
+
[PATCH v4 05/11] drm: Add Allwinner A10 Display Engine support
The Allwinner A10 and subsequent SoCs share the same display pipeline, with variations in the number of controllers (1 or 2), or the presence or not of some output (HDMI, TV, VGA) or not. Add a driver with a limited set of features for now, and we will hopefully support all of them eventually Signed-off-by: Maxime Ripard --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/sun4i/Kconfig | 14 + drivers/gpu/drm/sun4i/Makefile| 10 + drivers/gpu/drm/sun4i/sun4i_backend.c | 364 ++ drivers/gpu/drm/sun4i/sun4i_backend.h | 165 ++ drivers/gpu/drm/sun4i/sun4i_crtc.c| 120 +++ drivers/gpu/drm/sun4i/sun4i_crtc.h| 30 ++ drivers/gpu/drm/sun4i/sun4i_dotclock.c| 160 ++ drivers/gpu/drm/sun4i/sun4i_dotclock.h| 21 ++ drivers/gpu/drm/sun4i/sun4i_drv.c | 333 drivers/gpu/drm/sun4i/sun4i_drv.h | 30 ++ drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 54 drivers/gpu/drm/sun4i/sun4i_framebuffer.h | 19 ++ drivers/gpu/drm/sun4i/sun4i_layer.c | 161 ++ drivers/gpu/drm/sun4i/sun4i_layer.h | 30 ++ drivers/gpu/drm/sun4i/sun4i_tcon.c| 502 ++ drivers/gpu/drm/sun4i/sun4i_tcon.h| 184 +++ 18 files changed, 2201 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/sun4i/Kconfig create mode 100644 drivers/gpu/drm/sun4i/Makefile create mode 100644 drivers/gpu/drm/sun4i/sun4i_backend.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_backend.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_crtc.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_crtc.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_dotclock.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_dotclock.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_drv.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_framebuffer.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_layer.h create mode 100644 drivers/gpu/drm/sun4i/sun4i_tcon.c create mode 100644 drivers/gpu/drm/sun4i/sun4i_tcon.h diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index f2a74d0b68ae..420779064e49 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -252,6 +252,8 @@ source "drivers/gpu/drm/rcar-du/Kconfig" source "drivers/gpu/drm/shmobile/Kconfig" +source "drivers/gpu/drm/sun4i/Kconfig" + source "drivers/gpu/drm/omapdrm/Kconfig" source "drivers/gpu/drm/tilcdc/Kconfig" diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 6eb94fc561dc..e163fd3cd604 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -1,4 +1,4 @@ -# + # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. @@ -65,6 +65,7 @@ obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ obj-y += omapdrm/ +obj-$(CONFIG_DRM_SUN4I) += sun4i/ obj-y += tilcdc/ obj-$(CONFIG_DRM_QXL) += qxl/ obj-$(CONFIG_DRM_BOCHS) += bochs/ diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig new file mode 100644 index ..99510e64e91a --- /dev/null +++ b/drivers/gpu/drm/sun4i/Kconfig @@ -0,0 +1,14 @@ +config DRM_SUN4I + tristate "DRM Support for Allwinner A10 Display Engine" + depends on DRM && ARM + depends on ARCH_SUNXI || COMPILE_TEST + select DRM_GEM_CMA_HELPER + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_PANEL + select REGMAP_MMIO + select VIDEOMODE_HELPERS + help + Choose this option if you have an Allwinner SoC with a + Display Engine. If M is selected the module will be called + sun4i-drm. diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile new file mode 100644 index ..6df3ef32732d --- /dev/null +++ b/drivers/gpu/drm/sun4i/Makefile @@ -0,0 +1,10 @@ +sun4i-drm-y += sun4i_crtc.o +sun4i-drm-y += sun4i_drv.o +sun4i-drm-y += sun4i_framebuffer.o +sun4i-drm-y += sun4i_layer.o + +sun4i-tcon-y += sun4i_tcon.o +sun4i-tcon-y += sun4i_dotclock.o + +obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o +obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c new file mode 100644 index ..f7a15c1a93bf --- /dev/null +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c @@ -0,0 +1,364 @@ +/* + * Copyright (C) 2015 Free Electrons + * Copyright (C) 2015 NextThing Co + * + * Maxime Ripard + * + * This program is free software; you can redistribute it and/or + * modify it un
[PATCH v4 07/11] drm: sun4i: Add composite output
Some Allwinner SoCs have an IP called the TV encoder that is used to output composite and VGA signals. In such a case, we need to use the second TCON channel. Add support for that TV encoder. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/Makefile | 2 + drivers/gpu/drm/sun4i/sun4i_tv.c | 621 +++ 2 files changed, 623 insertions(+) create mode 100644 drivers/gpu/drm/sun4i/sun4i_tv.c diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile index 74f804b88ff5..58cd55149827 100644 --- a/drivers/gpu/drm/sun4i/Makefile +++ b/drivers/gpu/drm/sun4i/Makefile @@ -9,3 +9,5 @@ sun4i-tcon-y += sun4i_dotclock.o obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o sun4i-tcon.o obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o + +obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c new file mode 100644 index ..78634dfc0f77 --- /dev/null +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c @@ -0,0 +1,621 @@ +/* + * Copyright (C) 2015 Free Electrons + * Copyright (C) 2015 NextThing Co + * + * Maxime Ripard + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include "sun4i_backend.h" +#include "sun4i_drv.h" +#include "sun4i_tcon.h" + +#define SUN4I_TVE_EN_REG 0x000 +#define SUN4I_TVE_EN_DAC_MAP_MASK GENMASK(19, 4) +#define SUN4I_TVE_EN_DAC_MAP(dac, out) (((out) & 0xf) << (dac + 1) * 4) +#define SUN4I_TVE_EN_ENABLEBIT(0) + +#define SUN4I_TVE_CFG0_REG 0x004 +#define SUN4I_TVE_CFG0_DAC_CONTROL_54M BIT(26) +#define SUN4I_TVE_CFG0_CORE_DATAPATH_54M BIT(25) +#define SUN4I_TVE_CFG0_CORE_CONTROL_54MBIT(24) +#define SUN4I_TVE_CFG0_YC_EN BIT(17) +#define SUN4I_TVE_CFG0_COMP_EN BIT(16) +#define SUN4I_TVE_CFG0_RES(x) ((x) & 0xf) +#define SUN4I_TVE_CFG0_RES_480iSUN4I_TVE_CFG0_RES(0) +#define SUN4I_TVE_CFG0_RES_576iSUN4I_TVE_CFG0_RES(1) + +#define SUN4I_TVE_DAC0_REG 0x008 +#define SUN4I_TVE_DAC0_CLOCK_INVERTBIT(24) +#define SUN4I_TVE_DAC0_LUMA(x) (((x) & 3) << 20) +#define SUN4I_TVE_DAC0_LUMA_0_4SUN4I_TVE_DAC0_LUMA(3) +#define SUN4I_TVE_DAC0_CHROMA(x) (((x) & 3) << 18) +#define SUN4I_TVE_DAC0_CHROMA_0_75 SUN4I_TVE_DAC0_CHROMA(3) +#define SUN4I_TVE_DAC0_INTERNAL_DAC(x) (((x) & 3) << 16) +#define SUN4I_TVE_DAC0_INTERNAL_DAC_37_5_OHMS SUN4I_TVE_DAC0_INTERNAL_DAC(3) +#define SUN4I_TVE_DAC0_DAC_EN(dac) BIT(dac) + +#define SUN4I_TVE_NOTCH_REG0x00c +#define SUN4I_TVE_NOTCH_DAC0_TO_DAC_DLY(dac, x)((4 - (x)) << (dac * 3)) + +#define SUN4I_TVE_CHROMA_FREQ_REG 0x010 + +#define SUN4I_TVE_PORCH_REG0x014 +#define SUN4I_TVE_PORCH_BACK(x)((x) << 16) +#define SUN4I_TVE_PORCH_FRONT(x) (x) + +#define SUN4I_TVE_LINE_REG 0x01c +#define SUN4I_TVE_LINE_FIRST(x)((x) << 16) +#define SUN4I_TVE_LINE_NUMBER(x) (x) + +#define SUN4I_TVE_LEVEL_REG0x020 +#define SUN4I_TVE_LEVEL_BLANK(x) ((x) << 16) +#define SUN4I_TVE_LEVEL_BLACK(x) (x) + +#define SUN4I_TVE_DAC1_REG 0x024 +#define SUN4I_TVE_DAC1_AMPLITUDE(dac, x) ((x) << (dac * 8)) + +#define SUN4I_TVE_DETECT_STA_REG 0x038 +#define SUN4I_TVE_DETECT_STA_DAC(dac) BIT((dac * 8)) +#define SUN4I_TVE_DETECT_STA_UNCONNECTED 0 +#define SUN4I_TVE_DETECT_STA_CONNECTED 1 +#define SUN4I_TVE_DETECT_STA_GROUND2 + +#define SUN4I_TVE_CB_CR_LVL_REG0x10c +#define SUN4I_TVE_CB_CR_LVL_CR_BURST(x)((x) << 8) +#define SUN4I_TVE_CB_CR_LVL_CB_BURST(x)(x) + +#define SUN4I_TVE_TINT_BURST_PHASE_REG 0x110 +#define SUN4I_TVE_TINT_BURST_PHASE_CHROMA(x) (x) + +#define SUN4I_TVE_BURST_WIDTH_REG 0x114 +#define SUN4I_TVE_BURST_WIDTH_BREEZEWAY(x) ((x) << 16) +#define SUN4I_TVE_BURST_WIDTH_BURST_WIDTH(x) ((x) << 8) +#define SUN4I_TVE_BURST_WIDTH_HSYNC_WIDTH(x) (x) + +#define SUN4I_TVE_CB_CR_GAIN_REG 0x118 +#define SUN4I_TVE_CB_CR_GAIN_CR(x) ((x) << 8) +#define SUN4I_TVE_CB_CR_GAIN_CB(x) (x) + +#define SUN4I_TVE_SYNC_VBI_REG 0x11c +#define SUN4I_TVE_SYNC_VBI_SYNC(x) ((x) << 16) +#define SUN4I_TVE_SYNC_VBI_VBLANK(x) (x) + +#define SUN4I_TVE_ACTIVE_LINE_REG 0x124 +#define SUN4I_TVE_ACTIVE_LINE(x) (x
[PATCH v4 09/11] drm: sun4i: tv: Add NTSC output standard
Add the settings to support the NTSC standard.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 45
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index ccf275a90132..bc047f923508 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -178,24 +178,69 @@ struct sun4i_tv {
struct sun4i_drv*drv;
};
+struct video_levels ntsc_video_levels = {
+ .black = 282, .blank = 240,
+};
+
struct video_levels pal_video_levels = {
.black = 252, .blank = 252,
};
+struct burst_levels ntsc_burst_levels = {
+ .cb = 79, .cr = 0,
+};
+
struct burst_levels pal_burst_levels = {
.cb = 40, .cr = 40,
};
+struct color_gains ntsc_color_gains = {
+ .cb = 160, .cr = 160,
+};
+
struct color_gains pal_color_gains = {
.cb = 224, .cr = 224,
};
+struct resync_parameters ntsc_resync_parameters = {
+ .field = false, .line = 14, .pixel = 12,
+};
+
struct resync_parameters pal_resync_parameters = {
.field = true, .line = 13, .pixel = 12,
};
struct tv_mode tv_modes[] = {
{
+ .name = "NTSC",
+ .mode = SUN4I_TVE_CFG0_RES_480i,
+ .chroma_freq= 0x21f07c1f,
+ .yc_en = true,
+ .dac3_en= true,
+ .dac_bit25_en = true,
+
+ .back_porch = 118,
+ .front_porch= 32,
+ .line_number= 525,
+
+ .hdisplay = 720,
+ .hfront_porch = 18,
+ .hsync_len = 2,
+ .hback_porch= 118,
+
+ .vdisplay = 480,
+ .vfront_porch = 26,
+ .vsync_len = 2,
+ .vback_porch= 17,
+
+ .vblank_level = 240,
+
+ .color_gains= &ntsc_color_gains,
+ .burst_levels = &ntsc_burst_levels,
+ .video_levels = &ntsc_video_levels,
+ .resync_params = &ntsc_resync_parameters,
+ },
+ {
.name = "PAL",
.mode = SUN4I_TVE_CFG0_RES_576i,
.chroma_freq= 0x2a098acb,
--
2.8.1
[PATCH v4 03/11] drm: fb: Add seq_file definition
Otherwise, building with DEBUG_FS enabled will trigger a build warning because we're using a structure that has not been declared. Signed-off-by: Maxime Ripard --- include/drm/drm_fb_cma_helper.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h index be62bd321e75..ae49c24fbf50 100644 --- a/include/drm/drm_fb_cma_helper.h +++ b/include/drm/drm_fb_cma_helper.h @@ -24,6 +24,8 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct drm_framebuffer *fb, unsigned int plane); #ifdef CONFIG_DEBUG_FS +struct seq_file; + int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg); #endif -- 2.8.1
[PATCH] rcar-du: add/rename DEFR6 TCON bits
On 4/25/2016 10:25 AM, Geert Uytterhoeven wrote: >> The TCNE2 bit of the DEFR6 register was renamed to TCNE1 in the R-Car gen2 >> manuals -- which makes more sense as that bit controls whether DU1, not DU2 >> is connected to TCON. >> >> While at it, add the TCNE0 bit which controls whether DU0 is connected to >> TCON. >> >> Based on the large patch by Andrey Gusakov > cogentembedded.com>. >> >> Signed-off-by: Andrey Gusakov >> Signed-off-by: Sergei Shtylyov > > I hard a hard time finding this register, as it's actually called "DEF6R"... Well, the R-Car M1A manual named it this way, hence is this name in the driver, I guess. > Care to update /DEFRx/DEFxR/ as well? No. :-) > Regardless: > Reviewed-by: Geert Uytterhoeven Thank you. [...] MBR, Sergei
[PATCH v4] drm/dsi: Implement set tear scanline
Provide a small convenience wrapper that transmits
ia set_tear_scanline command as suggested by
Thierry Reding.
Also includes small build fixes from Sumit Semwal.
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
---
v2:
* Added fix for compilation issue from Sumit Semwal
v3:
* Simple subject line change
v4
* commit message changes from john stultz
---
drivers/gpu/drm/drm_mipi_dsi.c | 23 +++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..2f0b85c 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,29 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
/**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ * output signal on the TE signal line when display module reaches line N
+ * defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param1: STS[10:8]
+ * @param2: STS[7:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi,
+ u8 param1, u8 param2)
+{
+ u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param1, param2};
+ ssize_t err;
+
+ err = mipi_dsi_generic_write(dsi, &payload, sizeof(payload));
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+
+/**
* mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
*data used by the interface
* @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..2788dbe 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,8 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device
*dsi, u16 start,
u16 end);
int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u8 param1,
+ u8 param2);
int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dsi_dcs_tear_mode mode);
--
2.1.2
[Bug 92059] [radeonsi, apitrace] Missing textures and geometry in "Middle-earth: Shadow of Mordor"
https://bugs.freedesktop.org/show_bug.cgi?id=92059 --- Comment #22 from Christoph Haag --- (In reply to Edwin Smith (Feral Interactive) from comment #21) > Ernst Sj�strand, the build is unlikely to be released publicly until the > compute shaders are checked into git FYI (and for the people who are testing and are not aware): 1. Compute Shaders for radeonsi have been checked into git 6 days ago: https://cgit.freedesktop.org/mesa/mesa/commit/?id=464cef5b06e65aa740704e4adac68b7f5fee1b88 2. Compute Shaders for radeonsi require a recent llvm 3.9 svn build. 3. For some (SI only?) GPUs, compute shaders will be disabled even with Linus' current git master of the kernel, but will work with the drm-next-4.7-wip branch from this repository: https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip (I heard it's because this here is needed: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.7-wip&id=974cf6cc403d881b9fa939cb2afed19d53afab21) 4. OpenGL 4.3 is not enabled because the mesa devs first want to solve some problems with unreal engine 4, so if you want to test Shadow of Mordor, Alien Isolation, etc. you still need to set MESA_GL_VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/8b476ef5/attachment.html>
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #6 from Alex Deucher --- Your system is muxless so there is no mux to switch. The displays are only connected to the IGP. You need to use the xserver PRIME stuff to render with the dGPU. The dGPU renders offscreen and then the result is copied to the IGP for display. See: https://wiki.archlinux.org/index.php/PRIME -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
Den 25.04.2016 15:02, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>> Den 25.04.2016 14:39, skrev Ville Syrjälä:
>>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
Add some utility functions for struct drm_clip_rect.
>>> Looks like mostly you're just duplicating the drm_rect stuff. Why can't
>>> you use what's there already?
>> That's because the framebuffer flushing uses drm_clip_rect and not drm_rect:
> Converting to drm_rect is not an option?
That's difficult or at least verbose to do because clips is an array.
I could use drm_rect on the calling side (fbdev) since it's only one clip
which the changes are merged into, and then convert it when I call dirty().
But the driver can get zero or more clips from the dirty ioctl so I don't
see a clean way to convert this array to drm_rect without more code than
this proposal has.
Here's the driver side:
static int mipi_dbi_dirtyfb(struct drm_framebuffer *fb, void *vmem,
unsigned flags, unsigned color,
struct drm_clip_rect *clips, unsigned num_clips)
{
struct tinydrm_device *tdev = fb->dev->dev_private;
struct lcdreg *reg = tdev->lcdreg;
struct drm_clip_rect full_clip = {
.x1 = 0,
.x2 = fb->width,
.y1 = 0,
.y2 = fb->height,
};
struct drm_clip_rect clip;
int ret;
drm_clip_rect_reset(&clip);
drm_clip_rect_merge(&clip, clips, num_clips, flags,
fb->width, fb->height);
if (!drm_clip_rect_intersect(&clip, &full_clip)) {
DRM_DEBUG_KMS("Empty clip\n");
return -EINVAL;
}
[...]
>> struct drm_framebuffer_funcs {
>> [...]
>> int (*dirty)(struct drm_framebuffer *framebuffer,
>>struct drm_file *file_priv, unsigned flags,
>>unsigned color, struct drm_clip_rect *clips,
>>unsigned num_clips);
>> };
>>
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_rect.c | 67
include/drm/drm_rect.h | 69
++
2 files changed, 136 insertions(+)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index a8e2c86..a9fb1a8 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
}
}
EXPORT_SYMBOL(drm_rect_rotate_inv);
+
+/**
+ * drm_clip_rect_intersect - intersect two clip rectangles
+ * @r1: first clip rectangle
+ * @r2: second clip rectangle
+ *
+ * Calculate the intersection of clip rectangles @r1 and @r2.
+ * @r1 will be overwritten with the intersection.
+ *
+ * RETURNS:
+ * %true if rectangle @r1 is still visible after the operation,
+ * %false otherwise.
+ */
+bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
+ const struct drm_clip_rect *r2)
+{
+ r1->x1 = max(r1->x1, r2->x1);
+ r1->y1 = max(r1->y1, r2->y1);
+ r1->x2 = min(r1->x2, r2->x2);
+ r1->y2 = min(r1->y2, r2->y2);
+
+ return drm_clip_rect_visible(r1);
+}
+EXPORT_SYMBOL(drm_clip_rect_intersect);
+
+/**
+ * drm_clip_rect_merge - Merge clip rectangles
+ * @dst: destination clip rectangle
+ * @src: source clip rectangle(s), can be NULL
+ * @num_clips: number of source clip rectangles
+ * @flags: drm_mode_fb_dirty_cmd flags (DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
+ * @width: width of clip rectangle if @src is NULL
+ * @height: height of clip rectangle if @src is NULL
+ *
+ * The dirtyfb ioctl allows for a NULL clip rectangle to be passed in,
+ * so if @src is NULL, width and height is used to set a full clip
rectangle.
+ * @dst takes part in the merge unless it is empty {0,0,0,0}.
+ */
+void drm_clip_rect_merge(struct drm_clip_rect *dst,
+ struct drm_clip_rect *src, unsigned num_clips,
+ unsigned flags, u32 width, u32 height)
+{
+ int i;
+
+ if (!src || !num_clips) {
+ dst->x1 = 0;
+ dst->x2 = width;
+ dst->y1 = 0;
+ dst->y2 = height;
+ return;
+ }
+
+ if (drm_clip_rect_is_empty(dst)) {
+ dst->x1 = ~0;
+ dst->y1 = ~0;
+ }
+
+ for (i = 0; i < num_clips; i++) {
+ if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
+ i++;
+ dst->x1 = min(dst->x1, src[i].x1);
+ dst->x2 = max(dst->x2, src[i].x2);
+ dst->y1 = min(dst->y1, src[i].y1);
+ dst->y2 = max(dst->y2, src[i].y2);
+ }
+}
+EXPORT_SYMBOL(drm_clip_rect_merge);
diff -
[PATCH v2 3/3] MAINTAINERS: Add entry for Mali-DP driver
Add MAINTAINERS entry for ARM Mali-DP driver and update the HDLCD file matching pattern to cover only HDLCD rather than the whole drivers/gpu/drm/arm directory. Signed-off-by: Liviu Dudau --- MAINTAINERS | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..a5a4346 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -850,9 +850,17 @@ F: include/uapi/linux/if_arcnet.h ARM HDLCD DRM DRIVER M: Liviu Dudau S: Supported -F: drivers/gpu/drm/arm/ +F: drivers/gpu/drm/arm/hdlcd_* F: Documentation/devicetree/bindings/display/arm,hdlcd.txt +ARM MALI-DP DRM DRIVER +M: Liviu Dudau +M: Brian Starkey +M: Mali DP Maintainers +S: Supported +F: drivers/gpu/drm/arm/ +F: Documentation/devicetree/bindings/display/arm,malidp.txt + ARM MFM AND FLOPPY DRIVERS M: Ian Molton S: Maintained -- 2.8.0
[PATCH v2 0/3] Add support for ARM Mali Display Processors
Hello, This is the second revision of the driver for the Mali Display Processors (Mali DP). Currently, the driver supports the Display Engine found in Mali DP500, DP550 and DP650, with up to 3 planes that can be rotated by the hardware. There are features that the hardware supports that are not currently implemented in the driver, but in the current form it is capable of supporting X11 using fbdev emulation as well as Wayland with pixman rendering. Changes in v2 vs initial RFC: - merged malidp_crtc_mode_set_nofb into malidp_crtc_enable and removed the mode_set hooks. This removed the need for a custom destroy hook as well, switched to using drm_crtc_cleanup for that. - implemented proper async support for atomic page flip. - removed un-necessary checks and empty hooks. - clarifications in the bindings document for the use of interrupt-names. - removed the MALIDP_HW_FEATURE_DS (display split) from this version pending further development - Renamed module from malidp to mali-dp. - Added MAINTAINERS update Many thanks, Liviu Liviu Dudau (3): dt/bindings: display: Add DT bindings for Mali Display Processors. drm/arm: Add support for Mali Display Processors MAINTAINERS: Add entry for Mali-DP driver .../devicetree/bindings/display/arm,malidp.txt | 65 ++ drivers/gpu/drm/arm/Kconfig| 16 + drivers/gpu/drm/arm/Makefile | 2 + drivers/gpu/drm/arm/malidp_crtc.c | 259 +++ drivers/gpu/drm/arm/malidp_drv.c | 538 ++ drivers/gpu/drm/arm/malidp_drv.h | 54 ++ drivers/gpu/drm/arm/malidp_hw.c| 774 + drivers/gpu/drm/arm/malidp_hw.h| 189 + drivers/gpu/drm/arm/malidp_planes.c| 337 + drivers/gpu/drm/arm/malidp_regs.h | 172 + MAINTAINERS| 10 +- 11 files changed, 2415 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c create mode 100644 drivers/gpu/drm/arm/malidp_drv.c create mode 100644 drivers/gpu/drm/arm/malidp_drv.h create mode 100644 drivers/gpu/drm/arm/malidp_hw.c create mode 100644 drivers/gpu/drm/arm/malidp_hw.h create mode 100644 drivers/gpu/drm/arm/malidp_planes.c create mode 100644 drivers/gpu/drm/arm/malidp_regs.h -- 2.8.0
[PATCH v2 2/3] drm/arm: Add support for Mali Display Processors
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig | 16 +
drivers/gpu/drm/arm/Makefile| 2 +
drivers/gpu/drm/arm/malidp_crtc.c | 259
drivers/gpu/drm/arm/malidp_drv.c| 538 +
drivers/gpu/drm/arm/malidp_drv.h| 54 +++
drivers/gpu/drm/arm/malidp_hw.c | 774
drivers/gpu/drm/arm/malidp_hw.h | 189 +
drivers/gpu/drm/arm/malidp_planes.c | 337
drivers/gpu/drm/arm/malidp_regs.h | 172
9 files changed, 2341 insertions(+)
create mode 100644 drivers/gpu/drm/arm/malidp_crtc.c
create mode 100644 drivers/gpu/drm/arm/malidp_drv.c
create mode 100644 drivers/gpu/drm/arm/malidp_drv.h
create mode 100644 drivers/gpu/drm/arm/malidp_hw.c
create mode 100644 drivers/gpu/drm/arm/malidp_hw.h
create mode 100644 drivers/gpu/drm/arm/malidp_planes.c
create mode 100644 drivers/gpu/drm/arm/malidp_regs.h
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index eaed454..1b29065 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -25,3 +25,19 @@ config DRM_HDLCD_SHOW_UNDERRUN
Enable this option to show in red colour the pixels that the
HDLCD device did not fetch from framebuffer due to underrun
conditions.
+
+config DRM_MALI_DISPLAY
+ tristate "ARM Mali Display Processor"
+ depends on DRM && OF && (ARM || ARM64)
+ depends on COMMON_CLK
+ select DRM_ARM
+ select DRM_KMS_HELPER
+ select DRM_KMS_CMA_HELPER
+ select DRM_GEM_CMA_HELPER
+ select VIDEOMODE_HELPERS
+ help
+ Choose this option if you want to compile the ARM Mali Display
+ Processor driver. It supports the DP500, DP550 and DP650 variants
+ of the hardware.
+
+ If compiled as a module it will be called mali-dp.
diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
index 89dcb7b..bb8b158 100644
--- a/drivers/gpu/drm/arm/Makefile
+++ b/drivers/gpu/drm/arm/Makefile
@@ -1,2 +1,4 @@
hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
+mali-dp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
+obj-$(CONFIG_DRM_MALI_DISPLAY) += mali-dp.o
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
new file mode 100644
index 000..12893d0
--- /dev/null
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -0,0 +1,259 @@
+/*
+ * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
+ * Author: Liviu Dudau
+ *
+ * This program is free software and is provided to you under the terms of the
+ * GNU General Public License version 2 as published by the Free Software
+ * Foundation, and any use by you of this program is subject to the terms
+ * of such GNU licence.
+ *
+ * ARM Mali DP500/DP550/DP650 driver (crtc operations)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "malidp_drv.h"
+#include "malidp_hw.h"
+
+static bool malidp_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
+ struct malidp_hw_device *hwdev = malidp->dev;
+
+ /*
+* check that the hardware can drive the required clock rate,
+* but skip the check if the clock is meant to be disabled (req_rate =
0)
+*/
+ long rate, req_rate = mode->crtc_clock * 1000;
+
+ if (req_rate) {
+ rate = clk_round_rate(hwdev->mclk, req_rate);
+ if (rate < req_rate) {
+ DRM_DEBUG_DRIVER("mclk clock unable to reach %d kHz\n",
+mode->crtc_clock);
+ return false;
+ }
+
+ rate = clk_round_rate(hwdev->pxlclk, req_rate);
+ if (rate != req_rate) {
+ DRM_DEBUG_DRIVER("pxlclk doesn't support %ld Hz\n",
+req_rate);
+ return false;
+ }
+ }
+
+ return true;
+}
+
+static void malidp_crtc_enable(struct drm_crtc *crtc)
+{
+ struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
+ struct malidp_hw_device *hwdev = malidp->dev;
+ struct videomode vm;
+
+ drm_display_mode_to_videomode(&crtc->state->adjusted_mode, &vm);
+
+ clk_prepare_enable(hwdev->pxlclk);
+
+ /* mclk needs to be set to the same or higher rate than pxlclk */
+ clk_set_rate(hwdev->mclk, crtc->state->adjusted_mode.crtc_clock * 1000);
+ clk_set_rate(hwdev->pxlclk, crtc->state->adjust
[PATCH v2 1/3] dt/bindings: display: Add DT bindings for Mali Display Processors.
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
---
.../devicetree/bindings/display/arm,malidp.txt | 65 ++
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/arm,malidp.txt
diff --git a/Documentation/devicetree/bindings/display/arm,malidp.txt
b/Documentation/devicetree/bindings/display/arm,malidp.txt
new file mode 100644
index 000..2f78709
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,malidp.txt
@@ -0,0 +1,65 @@
+ARM Mali-DP
+
+The following bindings apply to a family of Display Processors sold as
+licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
+DP650 processors that offer multiple composition layers, support for
+rotation and scaling output.
+
+Required properties:
+ - compatible: should be one of
+ "arm,mali-dp500"
+ "arm,mali-dp550"
+ "arm,mali-dp650"
+depending on the particular implementation present in the hardware
+ - reg: Physical base address and size of the block of registers used by
+the processor.
+ - interrupts: Interrupt list, as defined in
../interrupt-controller/interrupts.txt,
+interrupt client nodes.
+ - interrupt-names: name of the engine inside the processor that will
+use the corresponding interrupt. Should be one of "DE" or "SE".
+ - clocks: A list of phandle + clock-specifier pairs, one for each entry
+in 'clock-names'
+ - clock-names: A list of clock names. It should contain:
+ - "pclk": for the APB interface clock
+ - "aclk": for the AXI interface clock
+ - "mclk": for the main processor clock
+ - "pxlclk": for the pixel clock feeding the output PLL of the processor.
+ - arm,malidp-output-port-lines: Array of u8 values describing the number
+of output lines per channel (R, G and B).
+
+Required sub-nodes:
+ - port: The Mali DP connection to an encoder input port. The connection
+is modelled using the OF graph bindings specified in
+Documentation/devicetree/bindings/graph.txt
+
+Optional properties:
+ - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+to be used for the framebuffer; if not present, the framebuffer may
+be located anywhere in memory.
+
+
+Example:
+
+/ {
+ ...
+
+ dp0: malidp at 6f20 {
+ compatible = "arm,mali-dp650";
+ reg = <0 0x6f20 0 0x2>;
+ memory-region = <&display_reserved>;
+ interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>,
+<0 168 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "DE", "SE";
+ clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>;
+ clock-names = "pxlclk", "mclk", "aclk", "pclk";
+ arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
+ port {
+ dp0_output: endpoint {
+ remote-endpoint = <&tda998x_2_input>;
+ };
+ };
+ };
+
+ ...
+};
--
2.8.0
[Bug 95085] Invalid sampling of second texture in fragment shader that have two samplers with different parameters.
https://bugs.freedesktop.org/show_bug.cgi?id=95085 Marek Olšák changed: What|Removed |Added Assignee|idr at freedesktop.org |dri-devel at lists.freedesktop ||.org Component|glsl-compiler |Drivers/Gallium/radeonsi CC|maraeo at gmail.com| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/8d8b6e09/attachment.html>
[Bug 95093] Brutal legend messy image on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95093 cosiekvfj at o2.pl changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #2 from cosiekvfj at o2.pl --- Game too demanding to this GPU -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/215576e0/attachment.html>
[Bug 95092] Euro Truck Simulator 2 static messy or black screen on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95092 cosiekvfj at o2.pl changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #2 from cosiekvfj at o2.pl --- Game to demanding to this GPU -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/06592ce9/attachment.html>
[Bug 95106] Stacking messy screen on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95106 cosiekvfj at o2.pl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from cosiekvfj at o2.pl --- Game to demanding to this GPU -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/112f54fc/attachment.html>
[Bug 95089] EON game ports black screen on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95089 cosiekvfj at o2.pl changed: What|Removed |Added Summary|Stronghold3 Black screen|EON game ports black screen |with glove on RC410M|on RC410M [Mobility Radeon |[Mobility Radeon Xpress |Xpress 200M] |200M] | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/6aef418b/attachment.html>
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> >> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> >>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> Add some utility functions for struct drm_clip_rect.
> >>> Looks like mostly you're just duplicating the drm_rect stuff. Why can't
> >>> you use what's there already?
> >> That's because the framebuffer flushing uses drm_clip_rect and not
> >> drm_rect:
> > Converting to drm_rect is not an option?
>
> That's difficult or at least verbose to do because clips is an array.
> I could use drm_rect on the calling side (fbdev) since it's only one clip
> which the changes are merged into, and then convert it when I call dirty().
> But the driver can get zero or more clips from the dirty ioctl so I don't
> see a clean way to convert this array to drm_rect without more code than
> this proposal has.
Just some kind of simple drm_clip_rect_to_rect() thing should be enough AFAICS.
>
> Here's the driver side:
>
> static int mipi_dbi_dirtyfb(struct drm_framebuffer *fb, void *vmem,
> unsigned flags, unsigned color,
> struct drm_clip_rect *clips, unsigned num_clips)
> {
> struct tinydrm_device *tdev = fb->dev->dev_private;
> struct lcdreg *reg = tdev->lcdreg;
> struct drm_clip_rect full_clip = {
> .x1 = 0,
> .x2 = fb->width,
> .y1 = 0,
> .y2 = fb->height,
> };
> struct drm_clip_rect clip;
> int ret;
>
> drm_clip_rect_reset(&clip);
> drm_clip_rect_merge(&clip, clips, num_clips, flags,
> fb->width, fb->height);
> if (!drm_clip_rect_intersect(&clip, &full_clip)) {
> DRM_DEBUG_KMS("Empty clip\n");
> return -EINVAL;
> }
> [...]
>
> >> struct drm_framebuffer_funcs {
> >> [...]
> >> int (*dirty)(struct drm_framebuffer *framebuffer,
> >>struct drm_file *file_priv, unsigned flags,
> >>unsigned color, struct drm_clip_rect *clips,
> >>unsigned num_clips);
> >> };
> >>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_rect.c | 67
>
> include/drm/drm_rect.h | 69
> ++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> index a8e2c86..a9fb1a8 100644
> --- a/drivers/gpu/drm/drm_rect.c
> +++ b/drivers/gpu/drm/drm_rect.c
> @@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> }
> }
> EXPORT_SYMBOL(drm_rect_rotate_inv);
> +
> +/**
> + * drm_clip_rect_intersect - intersect two clip rectangles
> + * @r1: first clip rectangle
> + * @r2: second clip rectangle
> + *
> + * Calculate the intersection of clip rectangles @r1 and @r2.
> + * @r1 will be overwritten with the intersection.
> + *
> + * RETURNS:
> + * %true if rectangle @r1 is still visible after the operation,
> + * %false otherwise.
> + */
> +bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
> + const struct drm_clip_rect *r2)
> +{
> +r1->x1 = max(r1->x1, r2->x1);
> +r1->y1 = max(r1->y1, r2->y1);
> +r1->x2 = min(r1->x2, r2->x2);
> +r1->y2 = min(r1->y2, r2->y2);
> +
> +return drm_clip_rect_visible(r1);
> +}
> +EXPORT_SYMBOL(drm_clip_rect_intersect);
> +
> +/**
> + * drm_clip_rect_merge - Merge clip rectangles
> + * @dst: destination clip rectangle
> + * @src: source clip rectangle(s), can be NULL
> + * @num_clips: number of source clip rectangles
> + * @flags: drm_mode_fb_dirty_cmd flags (DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> + * @width: width of clip rectangle if @src is NULL
> + * @height: height of clip rectangle if @src is NULL
> + *
> + * The dirtyfb ioctl allows for a NULL clip rectangle to be passed in,
> + * so if @src is NULL, width and height is used to set a full clip
> rectangle.
> + * @dst takes part in the merge unless it is empty {0,0,0,0}.
> + */
> +void drm_clip_rect_merge(struct drm_clip_rect *dst,
> + struct drm_clip_rect *src, unsigned num_clips,
> + unsigned flags, u32 width, u32 height)
> +{
> +int i;
> +
> +if (!src || !num_clips) {
> +dst->x1 = 0;
> +dst->x2 = width;
> +dst->y1 = 0;
> +dst->y2 = height;
> +return;
> +}
> +
> +if (drm_clip_rect_is_
[Bug 117111] Quitting X with xrandr rotation enabled freezes vt
https://bugzilla.kernel.org/show_bug.cgi?id=117111 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 12/14] MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver
On Sun, Apr 24, 2016 at 11:12:28AM +0100, Emil Velikov wrote: > On 22 April 2016 at 15:22, Sinclair Yeh wrote: > > Hi, > > > > On Fri, Apr 22, 2016 at 12:04:00AM +0100, Emil Velikov wrote: > >> Thomas is one of the original authors of the driver, with recent > >> contributions from Sinclair and Brian. > >> > >> Cc: Sinclair Yeh > >> Cc: Thomas Hellstrom > >> Cc: Brian Paul > >> Cc: "VMware Graphics" > >> Signed-off-by: Emil Velikov > >> --- > >> Gents can anyone confirm if the data is correct ? > > > > You can also add me as a maintainer for vmwgfx if you like. > > > Nice one, thanks. > > Just realised that it's missing a tree tag, so based on the last few > pull req. it should be: > > T:git git://people.freedesktop.org/~thomash/linux This is fine. > > >> > >> I'm thinking that the status should be Supported, although the driver > >> hasn't see much action recently. > >> > Can I bother you for a confirmation on the Maintained vs Supported question ? Yes, it's "Supported." > > >> NOTE: The following email linux-graphics-maintainer at vmware.com is also > >> listed for the VMMOUSE driver. Is that correct ? > > > > Yes, correct since it's the same team that maintains the vmmouse driver. > > > Ack. > > Thanks > Emil
[Bug 95119] Trine bad graphic on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95119 cosiekvfj at o2.pl changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from cosiekvfj at o2.pl --- Game too demanding to this gpu. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/95ea0939/attachment.html>
[Bug 95121] Trine 2 bad graphic on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95121 cosiekvfj at o2.pl changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from cosiekvfj at o2.pl --- Game too demanding to this gpu. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/e375fc26/attachment.html>
[PATCH 0/2 v2] tonga_get_evv_voltage error handling fixes
On Sun, Apr 17, 2016 at 10:15 AM, Moritz Kühner wrote: > I got myself a 380X recently and started reading random mesa and kernel > code in the hopes that I would find something that I can fix or improve, > and something actually caught my eye. Some of the error handling in > tonga_get_evv_voltage just seemed of and based on the comments I think > the patches provided will do the intended thing. > While I did test the patch I have to admit that i did not try what > happens when I apply 2V to my card ;-). > > PS: This is my first submission. So... please tell me if I did something > wrong. > > v2: added signed of by > fixed error message print > > Moritz Kühner (2): > drm/amd/powerplay/hwmgr: prevent VDDC from exceeding 2V > drm/amd/powerplay/hwmgr: don't add invalid voltage Applied. thanks! Alex > > drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 55 > --- > 1 file changed, 30 insertions(+), 25 deletions(-) > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/11] drm: Add Allwinner A10 display engine support
Hi Maxime, On 25 April 2016 at 14:22, Maxime Ripard wrote: > Documentation/devicetree/bindings/clock/sunxi.txt | 2 + > .../bindings/display/sunxi/sun4i-drm.txt | 258 > arch/arm/boot/dts/sun5i-a13.dtsi | 39 +- > arch/arm/boot/dts/sun5i-r8-chip.dts| 12 + > arch/arm/boot/dts/sun5i-r8.dtsi| 142 - > drivers/clk/sunxi/Makefile | 1 + > drivers/clk/sunxi/clk-sun4i-display.c | 261 > drivers/gpu/drm/Kconfig| 2 + > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/sun4i/Kconfig | 14 + > drivers/gpu/drm/sun4i/Makefile | 13 + > drivers/gpu/drm/sun4i/sun4i_backend.c | 364 +++ > drivers/gpu/drm/sun4i/sun4i_backend.h | 165 + > drivers/gpu/drm/sun4i/sun4i_crtc.c | 120 > drivers/gpu/drm/sun4i/sun4i_crtc.h | 30 + > drivers/gpu/drm/sun4i/sun4i_dotclock.c | 160 + > drivers/gpu/drm/sun4i/sun4i_dotclock.h | 21 + > drivers/gpu/drm/sun4i/sun4i_drv.c | 357 +++ > drivers/gpu/drm/sun4i/sun4i_drv.h | 30 + > drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 54 ++ > drivers/gpu/drm/sun4i/sun4i_framebuffer.h | 19 + > drivers/gpu/drm/sun4i/sun4i_layer.c| 161 + > drivers/gpu/drm/sun4i/sun4i_layer.h| 30 + > drivers/gpu/drm/sun4i/sun4i_rgb.c | 250 > drivers/gpu/drm/sun4i/sun4i_rgb.h | 18 + > drivers/gpu/drm/sun4i/sun4i_tcon.c | 561 > drivers/gpu/drm/sun4i/sun4i_tcon.h | 186 ++ > drivers/gpu/drm/sun4i/sun4i_tv.c | 708 > + > include/drm/drm_fb_cma_helper.h| 2 + Having a look at the diff stat, can we please have an entry in MAINTAINERS for this driver ? Don't bother re-spinning the whole series just for that and add the patch on top [for the pull request]. Thank you ! -Emil
[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=95133 Bug ID: 95133 Summary: X-COM Enemy Within crashes when entering tactical mission with Bonaire Product: Mesa Version: 11.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: juho-mikko.pellinen at iki.fi QA Contact: dri-devel at lists.freedesktop.org Created attachment 123246 --> https://bugs.freedesktop.org/attachment.cgi?id=123246&action=edit apitrace from the starting of the game until entering of a tactical mission and subsequent crash X-Com Enemy Within from Steam crashes when entering a tactical mission. The globe part of the game works just fine. This happens with AMD Radeon R7 360 gpu which I just installed. I had previously HD5750 (Juniper) which ran the game just fine. The crash happens always when entering a tactical mission. Apitrace and other logs are attached. I'm running Gentoo. Installed package versions: x11-drivers/xf86-video-amdgpu 1.1.0 media-libs/mesa 11.2.1 kernel 4.5.1 x11-base/xorg-server 1.18.3 x11-libs/libdrm 2.4.67 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/14c02077/attachment-0001.html>
[Bug 95120] Worms Clan Wars bad rendering on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95120 --- Comment #1 from cosiekvfj at o2.pl --- Created attachment 123247 --> https://bugs.freedesktop.org/attachment.cgi?id=123247&action=edit Screen -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/bf631032/attachment.html>
[Bug 95120] Worms Clan Wars bad rendering on RC410M [Mobility Radeon Xpress 200M]
, GL_ARB_vertex_type_2_10_10_10_rev, GL_ARB_window_pos, GL_ATI_blend_equation_separate, GL_ATI_draw_buffers, GL_ATI_separate_stencil, GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_multisample_blit_scaled, GL_EXT_framebuffer_object, GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_texture_sRGB_decode, GL_EXT_texture_snorm, GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_KHR_context_flush_control, GL_KHR_debug, GL_MESA_pack_invert, GL_MESA_texture_signed_rgba, GL_MESA_window_pos, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_conditional_render, GL_NV_fog_distance, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, GL_NV_primitive_restart, GL_NV_texgen_reflection, GL_NV_texture_barrier, GL_NV_texture_env_combine4, GL_NV_texture_rectangle, GL_OES_EGL_image, GL_OES_read_format, GL_S3_s3tc, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays OpenGL ES profile version string: OpenGL ES 2.0 Mesa 11.1.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 OpenGL ES profile extensions: GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_APPLE_texture_max_level, GL_EXT_blend_minmax, GL_EXT_discard_framebuffer, GL_EXT_draw_buffers, GL_EXT_draw_elements_base_vertex, GL_EXT_map_buffer_range, GL_EXT_multi_draw_arrays, GL_EXT_read_format_bgra, GL_EXT_separate_shader_objects, GL_EXT_texture_compression_dxt1, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_format_BGRA, GL_EXT_texture_rg, GL_EXT_texture_type_2_10_10_10_REV, GL_EXT_unpack_subimage, GL_KHR_context_flush_control, GL_KHR_debug, GL_NV_draw_buffers, GL_NV_fbo_color_attachments, GL_NV_read_buffer, GL_NV_read_depth, GL_NV_read_depth_stencil, GL_NV_read_stencil, GL_OES_EGL_image, GL_OES_EGL_image_external, GL_OES_EGL_sync, GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, GL_OES_depth_texture, GL_OES_draw_elements_base_vertex, GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer, GL_OES_packed_depth_stencil, GL_OES_rgb8_rgba8, GL_OES_stencil8, GL_OES_surfaceless_context, GL_OES_texture_3D, GL_OES_texture_float, GL_OES_texture_half_float, GL_OES_texture_npot, GL_OES_vertex_array_object -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f62c4b02/attachment.html>
[PATCH v2 3/3] MAINTAINERS: Add entry for Mali-DP driver
On 25 April 2016 at 15:19, Liviu Dudau wrote: > Add MAINTAINERS entry for ARM Mali-DP driver and update the > HDLCD file matching pattern to cover only HDLCD rather than > the whole drivers/gpu/drm/arm directory. > > Signed-off-by: Liviu Dudau > --- > MAINTAINERS | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1d5b4be..a5a4346 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -850,9 +850,17 @@ F: include/uapi/linux/if_arcnet.h > ARM HDLCD DRM DRIVER > M: Liviu Dudau > S: Supported > -F: drivers/gpu/drm/arm/ > +F: drivers/gpu/drm/arm/hdlcd_* > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > +ARM MALI-DP DRM DRIVER > +M: Liviu Dudau > +M: Brian Starkey > +M: Mali DP Maintainers > +S: Supported > +F: drivers/gpu/drm/arm/ Woohoo. Thanks Liviu ! Note that having both drivers' sources in the same folder will cause some grief wrt getting the correct maintainer. If you want to avoid that the easiest way is to move things in subdirectories roughly like: drivers/gpu/arm/hdlcd/ drivers/gpu/arm/mapidp/ Regards, Emil
[Bug 95120] Worms Clan Wars bad rendering on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95120 --- Comment #3 from cosiekvfj at o2.pl --- Created attachment 123248 --> https://bugs.freedesktop.org/attachment.cgi?id=123248&action=edit Screen shoot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/233ef7bc/attachment-0001.html>
[Bug 117111] Quitting X with xrandr rotation enabled freezes vt
https://bugzilla.kernel.org/show_bug.cgi?id=117111
MichaÅ Pecio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from MichaÅ Pecio ---
OK, so I checked Xorg log and it's missing the final line indicating clean
shutdown. strace revealed that X is aborting for some reason:
<... futex resumed> ) = 0
ioctl(12, DRM_IOCTL_GEM_CLOSE, 0x7ffdfee3d4e0) = 0
close(12) = 0
close(11) = 0
munmap(0x7f1fa4a69000, 13890560)= 0
munmap(0x7f1fa5bef000, 2126232) = 0
munmap(0x7f1fa4861000, 2126248) = 0
munmap(0x7f1fa4649000, 2191808) = 0
write(2, "Xorg: ../include/privates.h:122:"..., 89) = 89
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f1fad47c000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(2858, 2858, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2858, si_uid=1000} ---
+++ killed by SIGABRT +++
So much for a kernel bug, I guess.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> >
> > Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> > >> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> > >>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> > Add some utility functions for struct drm_clip_rect.
> > >>> Looks like mostly you're just duplicating the drm_rect stuff. Why can't
> > >>> you use what's there already?
> > >> That's because the framebuffer flushing uses drm_clip_rect and not
> > >> drm_rect:
> > > Converting to drm_rect is not an option?
> >
> > That's difficult or at least verbose to do because clips is an array.
> > I could use drm_rect on the calling side (fbdev) since it's only one clip
> > which the changes are merged into, and then convert it when I call dirty().
> > But the driver can get zero or more clips from the dirty ioctl so I don't
> > see a clean way to convert this array to drm_rect without more code than
> > this proposal has.
>
> Just some kind of simple drm_clip_rect_to_rect() thing should be enough
> AFAICS.
Yeah, drm_clip_rect is the uapi struct, drm_rect is the internal one.
Similar case is drm_display_mode vs. drm_mode_modeinfo. We have
umode_to_mode and mode_to_umode helpers to deal with that. I do agree that
it would make sense to switch the internal ->dirty callback over to the
internal drm_struct. Would need a kmalloc+copy in the dirtyfb ioctl, but
since the structs actually match in their member names (just not the
size/signedness, sigh) there shouldn't be any need for driver changes. So
fairly simple patch.
Ofc you need to compile-test all the drivers (at least those using ->dirty
hook) to make sure gcc is still happy with all the signed vs. unsigned
stuff. Maybe that turns up something, but hopefully not.
Sorry for that late request, but I really didn't realize what's going on
here :(
-Daniel
>
> >
> > Here's the driver side:
> >
> > static int mipi_dbi_dirtyfb(struct drm_framebuffer *fb, void *vmem,
> > unsigned flags, unsigned color,
> > struct drm_clip_rect *clips, unsigned num_clips)
> > {
> > struct tinydrm_device *tdev = fb->dev->dev_private;
> > struct lcdreg *reg = tdev->lcdreg;
> > struct drm_clip_rect full_clip = {
> > .x1 = 0,
> > .x2 = fb->width,
> > .y1 = 0,
> > .y2 = fb->height,
> > };
> > struct drm_clip_rect clip;
> > int ret;
> >
> > drm_clip_rect_reset(&clip);
> > drm_clip_rect_merge(&clip, clips, num_clips, flags,
> > fb->width, fb->height);
> > if (!drm_clip_rect_intersect(&clip, &full_clip)) {
> > DRM_DEBUG_KMS("Empty clip\n");
> > return -EINVAL;
> > }
> > [...]
>
> >
> > >> struct drm_framebuffer_funcs {
> > >> [...]
> > >> int (*dirty)(struct drm_framebuffer *framebuffer,
> > >>struct drm_file *file_priv, unsigned flags,
> > >>unsigned color, struct drm_clip_rect *clips,
> > >>unsigned num_clips);
> > >> };
> > >>
> > Signed-off-by: Noralf Trønnes
> > ---
> > drivers/gpu/drm/drm_rect.c | 67
> >
> > include/drm/drm_rect.h | 69
> > ++
> > 2 files changed, 136 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > index a8e2c86..a9fb1a8 100644
> > --- a/drivers/gpu/drm/drm_rect.c
> > +++ b/drivers/gpu/drm/drm_rect.c
> > @@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> > }
> > }
> > EXPORT_SYMBOL(drm_rect_rotate_inv);
> > +
> > +/**
> > + * drm_clip_rect_intersect - intersect two clip rectangles
> > + * @r1: first clip rectangle
> > + * @r2: second clip rectangle
> > + *
> > + * Calculate the intersection of clip rectangles @r1 and @r2.
> > + * @r1 will be overwritten with the intersection.
> > + *
> > + * RETURNS:
> > + * %true if rectangle @r1 is still visible after the operation,
> > + * %false otherwise.
> > + */
> > +bool drm_clip_rect_intersect(struct drm_clip_rect *r1,
> > + const struct drm_clip_rect *r2)
> > +{
> > + r1->x1 = max(r1->x1, r2->x1);
> > + r1->y1 = max(r1->y1, r2->y1);
> > + r1->x2 = min(r1->x2, r2->x2);
> > + r1->y2 = min(r1->y2, r2->y2);
> > +
> > + return drm_clip_rect_visible(r1);
> > +}
> > +EXPORT_SYMBOL(drm_clip_rect_intersect);
> > +
> > +/**
> > + * drm_clip_rect_merge - Merge clip rectangles
> > + * @dst: destination clip rectangle
> > + * @src: source clip rectangle(s), can be NUL
[Bug 95105] Puddle liquid not visible on RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95105 --- Comment #1 from cosiekvfj at o2.pl --- Created attachment 123249 --> https://bugs.freedesktop.org/attachment.cgi?id=123249&action=edit Screen shoot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/a7c33cde/attachment.html>
[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=95133 --- Comment #1 from Juho-Mikko Pellinen --- Created attachment 123251 --> https://bugs.freedesktop.org/attachment.cgi?id=123251&action=edit Steam log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/47875db4/attachment-0001.html>
[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=95133 --- Comment #2 from Juho-Mikko Pellinen --- Created attachment 123252 --> https://bugs.freedesktop.org/attachment.cgi?id=123252&action=edit Kernel dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/1b9f4b9f/attachment-0001.html>
[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=95133 --- Comment #3 from Juho-Mikko Pellinen --- Created attachment 123253 --> https://bugs.freedesktop.org/attachment.cgi?id=123253&action=edit Glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/05e483c1/attachment-0001.html>
[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=95133 --- Comment #4 from Juho-Mikko Pellinen --- Created attachment 123254 --> https://bugs.freedesktop.org/attachment.cgi?id=123254&action=edit uname -a -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/d9592bd8/attachment.html>
[Bug 117181] New: graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 Bug ID: 117181 Summary: graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake Product: Drivers Version: 2.5 Kernel Version: 4.5.2 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: yves.dufournaud at gmail.com Regression: No I am on an Asus UX305UA-FC057T - Intel Core i7-6500U - Intel HD Graphics 5500 when using kernel above > 4.2, I observe punctual screen glitch similar to those seen on image linked. This happens through the usage of cinamon (3d) on linux mint. But still I do use version 4.5.2 compiled by myself. uname -a Linux yves-asus 4.5.2 #2 SMP Sun Apr 24 20:17:09 CEST 2016 x86_64 x86_64 x86_64 GNU/Linux The glitch happens only with new kernel, previous kernel like 4.2.xxx are working fine for display with same system (they have othere issues). And seems (as a user point of view) be linked to a certain pattern: menu compositing + mouse hovering. Image showing the issue https://forums.linuxmint.com/download/file.php?id=26842&sid=ae05af439953d8fac51a9658d2eba0c1&mode=view it's flickering: so the screen is scrambled, and then normal Thank you for your time, Yves -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> > >
> > > Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > > > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> > > >> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> > > >>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> > > Add some utility functions for struct drm_clip_rect.
> > > >>> Looks like mostly you're just duplicating the drm_rect stuff. Why
> > > >>> can't
> > > >>> you use what's there already?
> > > >> That's because the framebuffer flushing uses drm_clip_rect and not
> > > >> drm_rect:
> > > > Converting to drm_rect is not an option?
> > >
> > > That's difficult or at least verbose to do because clips is an array.
> > > I could use drm_rect on the calling side (fbdev) since it's only one clip
> > > which the changes are merged into, and then convert it when I call
> > > dirty().
> > > But the driver can get zero or more clips from the dirty ioctl so I don't
> > > see a clean way to convert this array to drm_rect without more code than
> > > this proposal has.
> >
> > Just some kind of simple drm_clip_rect_to_rect() thing should be enough
> > AFAICS.
>
> Yeah, drm_clip_rect is the uapi struct, drm_rect is the internal one.
> Similar case is drm_display_mode vs. drm_mode_modeinfo. We have
> umode_to_mode and mode_to_umode helpers to deal with that. I do agree that
> it would make sense to switch the internal ->dirty callback over to the
> internal drm_struct. Would need a kmalloc+copy in the dirtyfb ioctl, but
> since the structs actually match in their member names (just not the
> size/signedness, sigh) there shouldn't be any need for driver changes. So
> fairly simple patch.
Or if we want to avoid the malloc, then the merge() thing could just
internally convert one at a time on stack when going through them.
Though then someone might want to do a merge() with internal drm_rects,
and we'd be right where we started. But I'm not sure that will happen,
so perhaps it's just too much future proofing.
>
> Ofc you need to compile-test all the drivers (at least those using ->dirty
> hook) to make sure gcc is still happy with all the signed vs. unsigned
> stuff. Maybe that turns up something, but hopefully not.
>
> Sorry for that late request, but I really didn't realize what's going on
> here :(
> -Daniel
>
> >
> > >
> > > Here's the driver side:
> > >
> > > static int mipi_dbi_dirtyfb(struct drm_framebuffer *fb, void *vmem,
> > > unsigned flags, unsigned color,
> > > struct drm_clip_rect *clips, unsigned num_clips)
> > > {
> > > struct tinydrm_device *tdev = fb->dev->dev_private;
> > > struct lcdreg *reg = tdev->lcdreg;
> > > struct drm_clip_rect full_clip = {
> > > .x1 = 0,
> > > .x2 = fb->width,
> > > .y1 = 0,
> > > .y2 = fb->height,
> > > };
> > > struct drm_clip_rect clip;
> > > int ret;
> > >
> > > drm_clip_rect_reset(&clip);
> > > drm_clip_rect_merge(&clip, clips, num_clips, flags,
> > > fb->width, fb->height);
> > > if (!drm_clip_rect_intersect(&clip, &full_clip)) {
> > > DRM_DEBUG_KMS("Empty clip\n");
> > > return -EINVAL;
> > > }
> > > [...]
> >
> > >
> > > >> struct drm_framebuffer_funcs {
> > > >> [...]
> > > >> int (*dirty)(struct drm_framebuffer *framebuffer,
> > > >>struct drm_file *file_priv, unsigned flags,
> > > >>unsigned color, struct drm_clip_rect *clips,
> > > >>unsigned num_clips);
> > > >> };
> > > >>
> > > Signed-off-by: Noralf Trønnes
> > > ---
> > > drivers/gpu/drm/drm_rect.c | 67
> > >
> > > include/drm/drm_rect.h | 69
> > > ++
> > > 2 files changed, 136 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
> > > index a8e2c86..a9fb1a8 100644
> > > --- a/drivers/gpu/drm/drm_rect.c
> > > +++ b/drivers/gpu/drm/drm_rect.c
> > > @@ -434,3 +434,70 @@ void drm_rect_rotate_inv(struct drm_rect *r,
> > > }
> > > }
> > > EXPORT_SYMBOL(drm_rect_rotate_inv);
> > > +
> > > +/**
> > > + * drm_clip_rect_intersect - intersect two clip rectangles
> > > + * @r1: first clip rectangle
> > > + * @r2: second clip rectangle
> > > + *
> > > + * Calculate the intersection of clip rectangles @r1 and @r2.
> > > + * @r1 will be overwritten with the intersection.
> > > + *
> > > + * RETURNS:
> > > + * %true if rectangle @r1 is still visible after the operation,
> > > + * %false otherwise.
> > > + */
> > > +boo
[PATCH] drm: rcar: remove unused variable
Hi Arnd,
Thank you for the patch.
On Monday 25 Apr 2016 15:11:08 Arnd Bergmann wrote:
> A cleanup for the rcar-du driver left an unused variable behind:
>
> drm/rcar-du/rcar_du_drv.c: In function 'rcar_du_probe':
> drm/rcar-du/rcar_du_drv.c:300:24: error: unused variable 'connector'
> [-Werror=unused-variable]
>
> This removes the variable.
>
> Signed-off-by: Arnd Bergmann
> Fixes: d63c25e4245a ("drm: rcar-du: Use generic drm_connector_register_all()
> helper")
I've already submitted an identical patch and Daniel Vetter has queued it up.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 0f251dc11082..fb9242d27883
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -297,7 +297,6 @@ static int rcar_du_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct rcar_du_device *rcdu;
> - struct drm_connector *connector;
> struct drm_device *ddev;
> struct resource *mem;
> int ret;
--
Regards,
Laurent Pinchart
[PATCH v2 3/3] MAINTAINERS: Add entry for Mali-DP driver
On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote: > On 25 April 2016 at 15:19, Liviu Dudau wrote: > > Add MAINTAINERS entry for ARM Mali-DP driver and update the > > HDLCD file matching pattern to cover only HDLCD rather than > > the whole drivers/gpu/drm/arm directory. > > > > Signed-off-by: Liviu Dudau > > --- > > MAINTAINERS | 10 +- > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 1d5b4be..a5a4346 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -850,9 +850,17 @@ F: include/uapi/linux/if_arcnet.h > > ARM HDLCD DRM DRIVER > > M: Liviu Dudau > > S: Supported > > -F: drivers/gpu/drm/arm/ > > +F: drivers/gpu/drm/arm/hdlcd_* > > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt > > > > +ARM MALI-DP DRM DRIVER > > +M: Liviu Dudau > > +M: Brian Starkey > > +M: Mali DP Maintainers > > +S: Supported > > +F: drivers/gpu/drm/arm/ > Woohoo. Thanks Liviu ! > > Note that having both drivers' sources in the same folder will cause > some grief wrt getting the correct maintainer. If you want to avoid > that the easiest way is to move things in subdirectories roughly like: > > drivers/gpu/arm/hdlcd/ > drivers/gpu/arm/mapidp/ I'm surprised to hear that there might be problems. All HDLCD files start with hdlcd_ and the rest will go to the Mali-DP DRM maintainers (which includes me as well). I understand your suggestion and I thank for it, but I really hate to have to navigate too many directories (for now). Lets see how things evolve and then we can move stuff around. Best regards, Liviu > > Regards, > Emil > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
[Bug 95080] Source games "Could not find required OpenGL entry point 'glColorMaskIndexedEXT'!" RC410M [Mobility Radeon Xpress 200M]
https://bugs.freedesktop.org/show_bug.cgi?id=95080 Nicolai H�hnle changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #2 from Nicolai H�hnle --- Keep in mind that the RC410 is a very old chip which lacks many features that modern games require. If you do a brief search on Steam forums, you'll find many discussions of similar "error messages" regarding TF2. It seems some people have had luck by hacking the driver to pretend that it supports certain features, but it seems safe to say that your hardware is simply too old. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/2e0abace/attachment-0001.html>
[Bug 94874] radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=94874 --- Comment #16 from Paulo Dias --- fixed in 4.6.0 rc5. commit bfaddd9fc8ac048b99475f000dbef6f08297417f Author: Alex Deucher Date: Mon Apr 18 11:19:19 2016 -0400 Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control" This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/9cfcde54/attachment.html>
[Bug 94726] [Tonga] ARK: Survival Evolved crashes on savegame load. Out of Memory
https://bugs.freedesktop.org/show_bug.cgi?id=94726 --- Comment #11 from Nicolai H�hnle --- Well, you can open /proc/$pid/maps and read it, but that is inefficient and hackish. I don't know of a nice way to determine the total number of open mmaps in a process. One possible approach we'd discussed is indeed to maintain a LRU list of open mappings and close the oldest one when a certain threshold number is reached. This might be the easiest way to avoid the crashes, but some applications might be hurt in terms of performance, if they expect to be able to update those small buffers often. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/487c3031/attachment.html>
[Bug 95130] Derivatives of gl_Color wrong when helper pixels used
https://bugs.freedesktop.org/show_bug.cgi?id=95130 --- Comment #3 from Nicolai H�hnle --- Hi James, thank you for the detailed report. I can reproduce this and am going to investigate. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/86496701/attachment.html>
[Bug 94874] radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=94874 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/739f179b/attachment.html>
[Bug 95130] Derivatives of gl_Color wrong when helper pixels used
https://bugs.freedesktop.org/show_bug.cgi?id=95130 --- Comment #4 from Nicolai H�hnle --- As a temporary workaround, the error should disappear when you run with the environment variable setting R600_DEBUG=mono. The cause is that with non-monolithic shaders, input interpolation happens in the prolog. However, when we compile the prolog we do not see the derivative computations and therefore fail to turn the helper pixels on. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/ccca2221/attachment.html>
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #7 from Jason Vas Dias --- (In reply to Alex Deucher from comment #6) > Your system is muxless so there is no mux to switch. The displays are only > connected to the IGP. You need to use the xserver PRIME stuff to render > with the dGPU. The dGPU renders offscreen and then the result is copied to > the IGP for display. See: > https://wiki.archlinux.org/index.php/PRIME Thanks for the info, Alex . But that page seems mainly to be a reference for xrandr usage, which as I understand it works only with a running X-server , which I do not have : $ unset DISPLAY; xrandr --listproviders Can't open display $ I am trying to get the X-server running, which it refuses to do because it cannot probe for display modes, and seemingly cannot be configured not to do so without major reworking. The modes cannot be determined because it seems the card is not in the fully 'powered on' state , and because whenever I attempt to switch into graphics mode, the radeon driver fails to execute this ACPI callout : [ 474.269102] ACPI Error: No handler for Region [EC81] (88041d8d9bd0) [EmbeddedControl] (20160108/evregion-166) [ 474.269724] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160108/exfldio-299) [ 474.270325] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PEGP.SGOF] (Node 88041d8fca50), AE_NOT_EXIST (20160108/psparse-542) [ 474.270940] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PEGP._OFF] (Node 88041d8fce88), AE_NOT_EXIST (20160108/psparse-542) [ 474.271548] ACPI Error: Method parse/execution failed [\_SB.PCI0.GFX0.ATPX] (Node 88041d9034b0), AE_NOT_EXIST (20160108/psparse-542) [ 474.272164] failed to evaluate ATPX got AE_NOT_EXIST I think the Linux radeon driver needs to be fixed to make the ACPI calls correctly - if anyone can please decode what it is trying to do by invoking this ACPI method, please let me know . If you or anyone could please suggest how to start the X-server with the xf86-video-ati driver controlling the Radeon Card, as it claims to be able to do, I'd be most appreciative of any tips . My xorg.conf as shown above was largely copied from the https://wiki.archlinux.org/index.php/PRIME page, and still does not work to enable me to start the X-server - the X-server cannot determine the display modes of the card and will not allow the modes to be specified in any other way - I guess I'll have to hack it to forget trying to determine the modes and use a hard-coded mode table. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #8 from Jason Vas Dias --- As stated on the web-page quoted above , ( https://wiki.archlinux.org/index.php/PRIME ) an example xorg.conf to use the discrete card as primary GPU is: # Discrete Card as Primary GPU Section "ServerLayout" Identifier "layout" Screen 0 "nouveau" Inactive "intel" EndSection Section "Device" Identifier "nouveau" Driver "nouveau" BusID "PCI:x:x:x" # Sample: "PCI:1:0:0" EndSection Section "Screen" Identifier "nouveau" Device "nouveau" EndSection Section "Device" Identifier "intel" Driver "intel" BusID "PCI:x:x:x" # Sample: "PCI:0:2:0" EndSection Section "Screen" Identifier "intel" Device "intel" EndSection My xorg.conf is basically the same with the string 'nouveau' replaced by 'ati' . It started out as simple as this, but then grew as I tried every conceivable method to specify the modes , but still the X-server exits with a 'No modes.' error in every case . The reason the X-server cannot determine the modes is because of this Linux bug - the radeon DRM driver makes incorrect ACPI calls. Also I think that if vga_switcheroo does not work or is incapable of working , as it provably is in the above example, it should return EIO on the write to the debugfs control 'switch' file , and not proceed to display spurious data in that file. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 95133] X-COM Enemy Within crashes when entering tactical mission with Bonaire
https://bugs.freedesktop.org/show_bug.cgi?id=95133 --- Comment #5 from Nicolai H�hnle --- Juho-Mikko, thank you for the report. Unfortunately, the apitrace you attached is of the pre-game launcher and not of the game itself. There should be a separate, much larger trace file of the game itself. It should be too large to attach in Bugzilla, use e.g. Google Drive. That said, I can reproduce the crash here with my local copy of the game. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/057e8dbf/attachment.html>
[PATCH v2 3/3] MAINTAINERS: Add entry for Mali-DP driver
On 25 April 2016 at 18:08, Liviu Dudau wrote: > On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote: >> On 25 April 2016 at 15:19, Liviu Dudau wrote: >> > Add MAINTAINERS entry for ARM Mali-DP driver and update the >> > HDLCD file matching pattern to cover only HDLCD rather than >> > the whole drivers/gpu/drm/arm directory. >> > >> > Signed-off-by: Liviu Dudau >> > --- >> > MAINTAINERS | 10 +- >> > 1 file changed, 9 insertions(+), 1 deletion(-) >> > >> > diff --git a/MAINTAINERS b/MAINTAINERS >> > index 1d5b4be..a5a4346 100644 >> > --- a/MAINTAINERS >> > +++ b/MAINTAINERS >> > @@ -850,9 +850,17 @@ F: include/uapi/linux/if_arcnet.h >> > ARM HDLCD DRM DRIVER >> > M: Liviu Dudau >> > S: Supported >> > -F: drivers/gpu/drm/arm/ >> > +F: drivers/gpu/drm/arm/hdlcd_* >> > F: Documentation/devicetree/bindings/display/arm,hdlcd.txt >> > >> > +ARM MALI-DP DRM DRIVER >> > +M: Liviu Dudau >> > +M: Brian Starkey >> > +M: Mali DP Maintainers >> > +S: Supported >> > +F: drivers/gpu/drm/arm/ >> Woohoo. Thanks Liviu ! >> >> Note that having both drivers' sources in the same folder will cause >> some grief wrt getting the correct maintainer. If you want to avoid >> that the easiest way is to move things in subdirectories roughly like: >> >> drivers/gpu/arm/hdlcd/ >> drivers/gpu/arm/mapidp/ > > I'm surprised to hear that there might be problems. All HDLCD files start > with hdlcd_ and the rest will go to the Mali-DP DRM maintainers (which > includes > me as well). > You're absolutely right. I read things the wrong way - the MaliDP maintainers will be added for the HDLCD patches. Which obviously isn't the case. > I understand your suggestion and I thank for it, but I really hate to have > to navigate too many directories (for now). Lets see how things evolve and > then > we can move stuff around. > IIRC DRM had the same structure (all drivers living in a single a folder) before 2008, before people got fed up. Feel free to do as you wish, just pointing out some historical observations ;-) Regardless of my suggestions/nitpicks, thanks for all the work Liviu ! It's really nice to see more vendors contributing to DRM. Regards, Emil
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #9 from Alex Deucher --- (In reply to Jason Vas Dias from comment #8) > As stated on the web-page quoted above , > ( https://wiki.archlinux.org/index.php/PRIME ) > an example xorg.conf to use the discrete card > as primary GPU is: > This is only possible if there are displays physically connected to the dGPU (e.g., laptop panel is connected to IGP and HDMI is connected to dGPU). I'd need to see your full dmesg output, but I suspect there are no displays physically connected to the dGPU on your system. As such, there is no way to make it the primary. > > > My xorg.conf is basically the same with the string 'nouveau' > replaced by 'ati' . > > It started out as simple as this, but then grew as I tried > every conceivable method to specify the modes , but still > the X-server exits with a 'No modes.' error in every case . > > The reason the X-server cannot determine the modes is because > of this Linux bug - the radeon DRM driver makes incorrect ACPI > calls. No. There are no displays or display connectors actually wired to the dGPU. This is what is called a mux-less laptop. mux-less in that there is no mux to switch the display connections between the IGP and the dGPU. > > Also I think that if vga_switcheroo does not work or is > incapable of working , as it provably is in the above > example, it should return EIO on the write to the > debugfs control 'switch' file , and not proceed to > display spurious data in that file. vag-switcheroo should only be used on old muxed laptops where there was a mux to switch the display routing. As I said, the only way to use the dGPU on your system is to follow the "PRIME GPU offloading" section of that page. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 95072] [wine] Rendering bug in GTA IV
https://bugs.freedesktop.org/show_bug.cgi?id=95072 --- Comment #1 from Nicolai H�hnle --- Hi Sven, thanks for the bug report. I can indeed reproduce the problem with the apitrace. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f6edfeaf/attachment.html>
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
Den 25.04.2016 18:38, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
>>> On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
Den 25.04.2016 15:02, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>> Den 25.04.2016 14:39, skrev Ville Syrjälä:
>>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
Add some utility functions for struct drm_clip_rect.
>>> Looks like mostly you're just duplicating the drm_rect stuff. Why can't
>>> you use what's there already?
>> That's because the framebuffer flushing uses drm_clip_rect and not
>> drm_rect:
> Converting to drm_rect is not an option?
That's difficult or at least verbose to do because clips is an array.
I could use drm_rect on the calling side (fbdev) since it's only one clip
which the changes are merged into, and then convert it when I call dirty().
But the driver can get zero or more clips from the dirty ioctl so I don't
see a clean way to convert this array to drm_rect without more code than
this proposal has.
>>> Just some kind of simple drm_clip_rect_to_rect() thing should be enough
>>> AFAICS.
>> Yeah, drm_clip_rect is the uapi struct, drm_rect is the internal one.
>> Similar case is drm_display_mode vs. drm_mode_modeinfo. We have
>> umode_to_mode and mode_to_umode helpers to deal with that. I do agree that
>> it would make sense to switch the internal ->dirty callback over to the
>> internal drm_struct. Would need a kmalloc+copy in the dirtyfb ioctl, but
>> since the structs actually match in their member names (just not the
>> size/signedness, sigh) there shouldn't be any need for driver changes. So
>> fairly simple patch.
> Or if we want to avoid the malloc, then the merge() thing could just
> internally convert one at a time on stack when going through them.
> Though then someone might want to do a merge() with internal drm_rects,
> and we'd be right where we started. But I'm not sure that will happen,
> so perhaps it's just too much future proofing.
>
>> Ofc you need to compile-test all the drivers (at least those using ->dirty
>> hook) to make sure gcc is still happy with all the signed vs. unsigned
>> stuff. Maybe that turns up something, but hopefully not.
>>
>> Sorry for that late request, but I really didn't realize what's going on
>> here :(
>> -Daniel
How about we just drop this patch?
I couldn't find anyone else that merge these clips, they just loop and
handle them individually.
The relevant part in drm_fb_helper would become:
static void drm_fb_helper_dirty_work(struct work_struct *work)
{
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
dirty_work);
struct drm_clip_rect *clip = &helper->dirty_clip;
struct drm_clip_rect clip_copy;
unsigned long flags;
spin_lock_irqsave(&helper->dirty_lock, flags);
clip_copy = *clip;
clip->x1 = clip->y1 = ~0;
clip->x2 = clip->y2 = 0;
spin_unlock_irqrestore(&helper->dirty_lock, flags);
helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
}
static void drm_fb_helper_dirty_init(struct drm_fb_helper *helper)
{
spin_lock_init(&helper->dirty_lock);
INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
}
static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y,
u32 width, u32 height)
{
struct drm_fb_helper *helper = info->par;
struct drm_clip_rect *clip = &helper->dirty_clip;
unsigned long flags;
if (!helper->fb->funcs->dirty)
return;
spin_lock_irqsave(&helper->dirty_lock, flags);
clip->x1 = min(clip->x1, x);
clip->y1 = min(clip->y1, y);
clip->x2 = max(clip->x2, x + width);
clip->y2 = max(clip->y2, y + height);
spin_unlock_irqrestore(&helper->dirty_lock, flags);
schedule_work(&helper->dirty_work);
}
And the driver would use this tinydrm function:
void tinydrm_merge_clips(struct drm_clip_rect *dst,
struct drm_clip_rect *src, unsigned num_clips,
unsigned flags, u32 width, u32 height)
{
int i;
if (!src || !num_clips) {
dst->x1 = 0;
dst->x2 = width;
dst->y1 = 0;
dst->y2 = height;
return;
}
dst->x1 = dst->y1 = ~0;
dst->x2 = dst->y2 = 0;
for (i = 0; i < num_clips; i++) {
if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
i++;
dst->x1 = min(dst->x1, src[i].x1);
dst->x2 = max(dst->x2, src[i].x2);
dst->y1 = min(dst->y1, src[i].y1);
dst->y2 = max(dst->y2, src[i].y2);
}
if (dst->x2 > width || dst->y2 > height ||
dst->x1 >= dst->x2 || dst->y1 >= dst->y2) {
DRM_DEBUG_KMS("Illegal clip: x1=%u, x2=%u, y1=%u, y2
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #10 from Jason Vas Dias --- OK, fine, I have to use FGLRX to use the Radeon as the primary display as I do under OEL7 (Linux 3.10) - what a terrific new open source radeon driver Linux 4.5 has. But I cannot even get the Intel card to go into graphics mode under Linux 4.5.0, owing to the failure of the radeon module to call that ACPI method . My xorg.conf now has no references to radeon driver : Section "ServerLayout" Identifier "X Radeon" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/lib64/xorg/modules" FontPath "/usr/share/fonts/X11/misc/" FontPath "/usr/share/fonts/X11/TTF/" FontPath "/usr/share/fonts/X11/OTF/" FontPath "/usr/share/fonts/X11/Type1/" FontPath "/usr/share/fonts/X11/100dpi/" FontPath "/usr/share/fonts/X11/75dpi/" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "evdev" EndSection Section "InputDevice" Identifier "Mouse0" Driver "synaptics" Option "Protocol" "auto" Option "Device" "/dev/input/mice" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" Option "DPMS" "true" EndSection Section "Device" Identifier "Intel" Screen 0 Driver "intel" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Intel" Monitor"Monitor0" SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Now, I boot only with the 'i915.modeset=1' kernel boot parameter . I do : $ dmesg -c >/var/log/dmesg-4.5.0.boot.log # available on request $ export DISPLAY=:0 $ Xorg -logverbose 7 :0 vt04 & (sleep 2; xterm &) Now the X-server gets a segmentation violation in the xf86-video-intel driver, and the following dmesgs are generated : $ dmesg [ 121.166547] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e [ 121.167141] [drm] PCIE gen 3 link speeds already enabled [ 121.171391] [drm] PCIE GART of 2048M enabled (table at 0x002E8000). [ 121.172068] radeon :01:00.0: WB enabled [ 121.172638] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x00010c00 and cpu addr 0x880414eb5c00 [ 121.173232] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x00010c04 and cpu addr 0x880414eb5c04 [ 121.173821] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x00010c08 and cpu addr 0x880414eb5c08 [ 121.174409] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x00010c0c and cpu addr 0x880414eb5c0c [ 121.174990] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x00010c10 and cpu addr 0x880414eb5c10 [ 121.175941] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc9435a18 [ 121.196617] radeon :01:00.0: fence driver on ring 6 use gpu addr 0x00010c18 and cpu addr 0x880414eb5c18 [ 121.197169] radeon :01:00.0: fence driver on ring 7 use gpu addr 0x00010c1c and cpu addr 0x880414eb5c1c [ 121.344986] [drm] ring test on 0 succeeded in 2 usecs [ 121.345536] [drm] ring test on 1 succeeded in 1 usecs [ 121.346090] [drm] ring test on 2 succeeded in 1 usecs [ 121.346659] [drm] ring test on 3 succeeded in 4 usecs [ 121.347202] [drm] ring test on 4 succeeded in 2 usecs [ 121.524819] [drm] ring test on 5 succeeded in 2 usecs [ 121.525345] [drm] UVD initialized successfully. [ 121.635907] [drm] ring test on 6 succeeded in 13 usecs [ 121.636449] [drm] ring test on 7 succeeded in 4 usecs [ 121.636978] [drm] VCE initialized successfully. [ 121.637570] f 0#2: signaled from fence_wait [ 121.638109] [drm] ib test on ring 0 succeeded in 0 usecs [ 121.638641] f 1#2: signaled from fence_wait [ 121.639152] [drm] ib test on ring 1 succeeded in 0 usecs [ 121.639722] f 2#2: signaled from fence_wait [ 121.640233] [drm] ib test on ring 2 succeeded in 0 usecs [ 121.640801] f 3#2: signaled from fence_wait [ 121.641313] [drm] ib test on ring 3 succeeded in 0 usecs [ 121.641878] f 4#2: signaled from fence_wait [ 121.642404] [drm] ib test on ring 4 succeeded in 0 usecs [ 122.295105] f 5#4: signaled from fence_wait [ 122.295672] [drm] ib test on ring 5 succeeded [ 122.797067] f 6#4: signaled from fence_wait [ 122.797648] [drm] ib test on ring 6 succeeded [ 123.299048] f 7#4: signaled from fence_wait [ 123.299662] [drm] ib test on ring 7 succeeded [ 123.387817] device: 'vcs4': device_add [ 123.387832] PM: Adding info for No Bus:vcs4 [ 123.387875] device: 'vcsa4': device_add [ 123.387893] PM: Adding info for
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #11 from Alex Deucher --- (In reply to Jason Vas Dias from comment #10) > OK, fine, I have to use FGLRX to use the Radeon as the primary display > as I do under OEL7 (Linux 3.10) - > what a terrific new open source radeon driver Linux 4.5 has. fglrx still uses the intel card for display, it just hacks a bunch of stuff under the covers rather than using the PRIME infrastructure. > > But I cannot even get the Intel card to go into graphics mode under Linux > 4.5.0, > owing to the failure of the radeon module to call that ACPI method . > > My xorg.conf now has no references to radeon driver : > Please remove your xorg config completely. You shouldn't need one, and some older xservers didn't properly handle multi-GPU with one in place. > > > Now, I boot only with the 'i915.modeset=1' kernel boot parameter . > > I do : > > $ dmesg -c >/var/log/dmesg-4.5.0.boot.log # available on request > $ export DISPLAY=:0 > $ Xorg -logverbose 7 :0 vt04 & (sleep 2; xterm &) > > Now the X-server gets a segmentation violation in the xf86-video-intel > driver, > and the following dmesgs are generated : > > $ dmesg > [ 121.166547] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e > [ 121.167141] [drm] PCIE gen 3 link speeds already enabled > [ 121.171391] [drm] PCIE GART of 2048M enabled (table at > 0x002E8000). > [ 121.172068] radeon :01:00.0: WB enabled > [ 121.172638] radeon :01:00.0: fence driver on ring 0 use gpu addr > 0x00010c00 and cpu addr 0x880414eb5c00 > [ 121.173232] radeon :01:00.0: fence driver on ring 1 use gpu addr > 0x00010c04 and cpu addr 0x880414eb5c04 > [ 121.173821] radeon :01:00.0: fence driver on ring 2 use gpu addr > 0x00010c08 and cpu addr 0x880414eb5c08 > [ 121.174409] radeon :01:00.0: fence driver on ring 3 use gpu addr > 0x00010c0c and cpu addr 0x880414eb5c0c > [ 121.174990] radeon :01:00.0: fence driver on ring 4 use gpu addr > 0x00010c10 and cpu addr 0x880414eb5c10 > [ 121.175941] radeon :01:00.0: fence driver on ring 5 use gpu addr > 0x00075a18 and cpu addr 0xc9435a18 > [ 121.196617] radeon :01:00.0: fence driver on ring 6 use gpu addr > 0x00010c18 and cpu addr 0x880414eb5c18 > [ 121.197169] radeon :01:00.0: fence driver on ring 7 use gpu addr > 0x00010c1c and cpu addr 0x880414eb5c1c > [ 121.344986] [drm] ring test on 0 succeeded in 2 usecs > [ 121.345536] [drm] ring test on 1 succeeded in 1 usecs > [ 121.346090] [drm] ring test on 2 succeeded in 1 usecs > [ 121.346659] [drm] ring test on 3 succeeded in 4 usecs > [ 121.347202] [drm] ring test on 4 succeeded in 2 usecs > [ 121.524819] [drm] ring test on 5 succeeded in 2 usecs > [ 121.525345] [drm] UVD initialized successfully. > [ 121.635907] [drm] ring test on 6 succeeded in 13 usecs > [ 121.636449] [drm] ring test on 7 succeeded in 4 usecs > [ 121.636978] [drm] VCE initialized successfully. > [ 121.637570] f 0#2: signaled from fence_wait > [ 121.638109] [drm] ib test on ring 0 succeeded in 0 usecs > [ 121.638641] f 1#2: signaled from fence_wait > [ 121.639152] [drm] ib test on ring 1 succeeded in 0 usecs > [ 121.639722] f 2#2: signaled from fence_wait > [ 121.640233] [drm] ib test on ring 2 succeeded in 0 usecs > [ 121.640801] f 3#2: signaled from fence_wait > [ 121.641313] [drm] ib test on ring 3 succeeded in 0 usecs > [ 121.641878] f 4#2: signaled from fence_wait > [ 121.642404] [drm] ib test on ring 4 succeeded in 0 usecs > [ 122.295105] f 5#4: signaled from fence_wait > [ 122.295672] [drm] ib test on ring 5 succeeded > [ 122.797067] f 6#4: signaled from fence_wait > [ 122.797648] [drm] ib test on ring 6 succeeded > [ 123.299048] f 7#4: signaled from fence_wait > [ 123.299662] [drm] ib test on ring 7 succeeded > [ 123.387817] device: 'vcs4': device_add > [ 123.387832] PM: Adding info for No Bus:vcs4 > [ 123.387875] device: 'vcsa4': device_add > [ 123.387893] PM: Adding info for No Bus:vcsa4 > [ 123.400978] Xorg (4385) used greatest stack depth: 12016 bytes left > [ 129.273612] ACPI Error: No handler for Region [EC81] (88041d8d9bd0) > [EmbeddedControl] (20160108/evregion-166) > [ 129.274317] ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160108/exfldio-299) > [ 129.275027] ACPI Error: Method parse/execution failed > [\_SB.PCI0.PEG0.PEGP.SGOF] (Node 88041d8fca50), AE_NOT_EXIST > (20160108/psparse-542) > [ 129.275779] ACPI Error: Method parse/execution failed > [\_SB.PCI0.PEG0.PEGP._OFF] (Node 88041d8fce88), AE_NOT_EXIST > (20160108/psparse-542) > [ 129.276495] ACPI Error: Method parse/execution failed > [\_SB.PCI0.GFX0.ATPX] (Node 88041d9034b0), AE_NOT_EXIST > (20160108/psparse-542) > [ 129.277229] failed to evaluate ATPX got AE_NOT_EXIST > > It seems even when I specify Intel driver should be used, the Intel driver > is still hooking into
[PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions
On Mon, Apr 25, 2016 at 08:35:18PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 18:38, skrev Ville Syrjälä:
> >On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> >>>On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> Den 25.04.2016 15:02, skrev Ville Syrjälä:
> >On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> >>Den 25.04.2016 14:39, skrev Ville Syrjälä:
> >>>On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> Add some utility functions for struct drm_clip_rect.
> >>>Looks like mostly you're just duplicating the drm_rect stuff. Why can't
> >>>you use what's there already?
> >>That's because the framebuffer flushing uses drm_clip_rect and not
> >>drm_rect:
> >Converting to drm_rect is not an option?
> That's difficult or at least verbose to do because clips is an array.
> I could use drm_rect on the calling side (fbdev) since it's only one clip
> which the changes are merged into, and then convert it when I call
> dirty().
> But the driver can get zero or more clips from the dirty ioctl so I don't
> see a clean way to convert this array to drm_rect without more code than
> this proposal has.
> >>>Just some kind of simple drm_clip_rect_to_rect() thing should be enough
> >>>AFAICS.
> >>Yeah, drm_clip_rect is the uapi struct, drm_rect is the internal one.
> >>Similar case is drm_display_mode vs. drm_mode_modeinfo. We have
> >>umode_to_mode and mode_to_umode helpers to deal with that. I do agree that
> >>it would make sense to switch the internal ->dirty callback over to the
> >>internal drm_struct. Would need a kmalloc+copy in the dirtyfb ioctl, but
> >>since the structs actually match in their member names (just not the
> >>size/signedness, sigh) there shouldn't be any need for driver changes. So
> >>fairly simple patch.
> >Or if we want to avoid the malloc, then the merge() thing could just
> >internally convert one at a time on stack when going through them.
> >Though then someone might want to do a merge() with internal drm_rects,
> >and we'd be right where we started. But I'm not sure that will happen,
> >so perhaps it's just too much future proofing.
> >
> >>Ofc you need to compile-test all the drivers (at least those using ->dirty
> >>hook) to make sure gcc is still happy with all the signed vs. unsigned
> >>stuff. Maybe that turns up something, but hopefully not.
> >>
> >>Sorry for that late request, but I really didn't realize what's going on
> >>here :(
> >>-Daniel
>
> How about we just drop this patch?
> I couldn't find anyone else that merge these clips, they just loop and
> handle them individually.
>
> The relevant part in drm_fb_helper would become:
>
> static void drm_fb_helper_dirty_work(struct work_struct *work)
> {
> struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> dirty_work);
> struct drm_clip_rect *clip = &helper->dirty_clip;
> struct drm_clip_rect clip_copy;
> unsigned long flags;
>
> spin_lock_irqsave(&helper->dirty_lock, flags);
> clip_copy = *clip;
> clip->x1 = clip->y1 = ~0;
> clip->x2 = clip->y2 = 0;
> spin_unlock_irqrestore(&helper->dirty_lock, flags);
>
> helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
> }
>
> static void drm_fb_helper_dirty_init(struct drm_fb_helper *helper)
> {
> spin_lock_init(&helper->dirty_lock);
> INIT_WORK(&helper->dirty_work, drm_fb_helper_dirty_work);
> helper->dirty_clip.x1 = helper->dirty_clip.y1 = ~0;
> }
>
> static void drm_fb_helper_dirty(struct fb_info *info, u32 x, u32 y,
> u32 width, u32 height)
> {
> struct drm_fb_helper *helper = info->par;
> struct drm_clip_rect *clip = &helper->dirty_clip;
> unsigned long flags;
>
> if (!helper->fb->funcs->dirty)
> return;
>
> spin_lock_irqsave(&helper->dirty_lock, flags);
> clip->x1 = min(clip->x1, x);
> clip->y1 = min(clip->y1, y);
> clip->x2 = max(clip->x2, x + width);
> clip->y2 = max(clip->y2, y + height);
> spin_unlock_irqrestore(&helper->dirty_lock, flags);
>
> schedule_work(&helper->dirty_work);
> }
>
>
> And the driver would use this tinydrm function:
>
> void tinydrm_merge_clips(struct drm_clip_rect *dst,
> struct drm_clip_rect *src, unsigned num_clips,
> unsigned flags, u32 width, u32 height)
> {
> int i;
>
> if (!src || !num_clips) {
> dst->x1 = 0;
> dst->x2 = width;
> dst->y1 = 0;
> dst->y2 = height;
> return;
> }
>
> dst->x1 = dst->y1 = ~0;
> dst->x2 = dst->y2 = 0;
>
> for (i = 0; i < num_clips; i++) {
> if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
> i++;
> dst->x1 = min(dst->x1, src[i].x1);
> dst->x2 = max(dst->x2, src[i].x2);
> dst->y1 = min(dst->y
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #12 from Jason Vas Dias --- Created attachment 214151 --> https://bugzilla.kernel.org/attachment.cgi?id=214151&action=edit dmesg boot log Boot DMESG log as requested -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94708] Open source radeon drivers not working properly with Radeon HD 8550M
https://bugs.freedesktop.org/show_bug.cgi?id=94708 --- Comment #11 from Marko Tikvic --- Error/behaviour is still present at: Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GN U/Linux -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/367eb80d/attachment.html>
[PATCH v2] drm/amdgpu: Constify some tables
Some more tables with constant data were added with the polaris support
v2: missed a few
Signed-off-by: Nils Wallménius
---
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 32 --
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h | 2 +-
.../drm/amd/powerplay/hwmgr/polaris10_powertune.c | 14 +-
.../drm/amd/powerplay/hwmgr/polaris10_thermal.c| 8 +++---
.../gpu/drm/amd/powerplay/inc/polaris10_pwrvirus.h | 2 +-
.../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 11
6 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index b146ec8..010199f 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -99,16 +99,17 @@
#define TCLK(PCIE_BUS_CLK / 10)
-uint16_t polaris10_clock_stretcher_lookup_table[2][4] = { {600, 1050, 3, 0},
- {600, 1050, 6, 1} };
+static const uint16_t polaris10_clock_stretcher_lookup_table[2][4] =
+{ {600, 1050, 3, 0}, {600, 1050, 6, 1} };
/* [FF, SS] type, [] 4 voltage ranges, and [Floor Freq, Boundary Freq, VID
min , VID max] */
-uint32_t polaris10_clock_stretcher_ddt_table[2][4][4] = { { {265, 529, 120,
128}, {325, 650, 96, 119}, {430, 860, 32, 95}, {0, 0, 0, 31} },
- { {275, 550, 104, 112},
{319, 638, 96, 103}, {360, 720, 64, 95}, {384, 768, 32, 63} } };
+static const uint32_t polaris10_clock_stretcher_ddt_table[2][4][4] =
+{ { {265, 529, 120, 128}, {325, 650, 96, 119}, {430, 860, 32, 95}, {0, 0, 0,
31} },
+ { {275, 550, 104, 112}, {319, 638, 96, 103}, {360, 720, 64, 95}, {384, 768,
32, 63} } };
/* [Use_For_Low_freq] value, [0%, 5%, 10%, 7.14%, 14.28%, 20%] (coming from
PWR_CKS_CNTL.stretch_amount reg spec) */
-uint8_t polaris10_clock_stretch_amount_conversion[2][6] = { {0, 1, 3, 2, 4, 5},
- {0, 2, 4, 5, 6, 5}
};
+static const uint8_t polaris10_clock_stretch_amount_conversion[2][6] =
+{ {0, 1, 3, 2, 4, 5}, {0, 2, 4, 5, 6, 5} };
/** Values for the CG_THERMAL_CTRL::DPM_EVENT_SRC field. */
enum DPM_EVENT_SRC {
@@ -119,7 +120,7 @@ enum DPM_EVENT_SRC {
DPM_EVENT_SRC_DIGITAL_OR_EXTERNAL = 4
};
-const unsigned long PhwPolaris10_Magic = (unsigned long)(PHM_VIslands_Magic);
+static const unsigned long PhwPolaris10_Magic = (unsigned
long)(PHM_VIslands_Magic);
struct polaris10_power_state *cast_phw_polaris10_power_state(
struct pp_hw_power_state *hw_ps)
@@ -1069,14 +1070,15 @@ static int polaris10_get_dependency_volt_by_clk(struct
pp_hwmgr *hwmgr,
return 0;
}
-sclkFcwRange_t Range_Table[NUM_SCLK_RANGE] = { {VCO_2_4, POSTDIV_DIV_BY_16,
75, 160, 112},
- {VCO_3_6, POSTDIV_DIV_BY_16,
112, 224, 160},
- {VCO_2_4, POSTDIV_DIV_BY_8,
75, 160, 112},
- {VCO_3_6, POSTDIV_DIV_BY_8,
112, 224, 160},
- {VCO_2_4, POSTDIV_DIV_BY_4,
75, 160, 112},
- {VCO_3_6, POSTDIV_DIV_BY_4,
112, 216, 160},
- {VCO_2_4, POSTDIV_DIV_BY_2,
75, 160, 108},
- {VCO_3_6, POSTDIV_DIV_BY_2,
112, 216, 160} };
+static const sclkFcwRange_t Range_Table[NUM_SCLK_RANGE] =
+{ {VCO_2_4, POSTDIV_DIV_BY_16, 75, 160, 112},
+ {VCO_3_6, POSTDIV_DIV_BY_16, 112, 224, 160},
+ {VCO_2_4, POSTDIV_DIV_BY_8, 75, 160, 112},
+ {VCO_3_6, POSTDIV_DIV_BY_8, 112, 224, 160},
+ {VCO_2_4, POSTDIV_DIV_BY_4, 75, 160, 112},
+ {VCO_3_6, POSTDIV_DIV_BY_4, 112, 216, 160},
+ {VCO_2_4, POSTDIV_DIV_BY_2, 75, 160, 108},
+ {VCO_3_6, POSTDIV_DIV_BY_2, 112, 216, 160} };
static void polaris10_get_sclk_range_table(struct pp_hwmgr *hwmgr)
{
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
index b022964..beedf35 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
@@ -264,7 +264,7 @@ struct polaris10_hwmgr {
bool enable_tdc_limit_feature;
bool enable_pkg_pwr_tracking_feature;
bool disable_uvd_power_tune_feature;
- struct polaris10_pt_defaults *power_tune_defaults;
+ const struct polaris10_pt_defaults *power_tune_defaults;
struct SMU74_Discrete_PmFuses power_tune_table;
uint32_t dte_tj_offset;
uint32_t fast_watermark_threshold;
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #13 from Jason Vas Dias --- Yes, radeon.runpm=0 has stopped the ACPI problem - but the latest Xorg xf86-video-intel driver ( 2.99.917 ) apparently does not work with the latest xorg server (1.18.3) and gets a segmentation violation on initialization - S.N.A.F.U . So, still no graphics mode under 4.5.0 until Xorg gets fixed or I can bother building each previous Xorg server to find one that works with the intel driver. So, please confirm: In order to use the Radeon 8970M at all, currently I have no choice but to run FGLRX closed source drivers and OpenGL user-space library stack, and the open-source radeon drivers (both kernel and Xorg) are of no use to me? There is no way I can use any open-source driver or OpenGL implementation to control the card for X-Windows display use ? Is there any xorg.conf that might potentially let me use the Radeon GPU for display on the laptop LCD without using FGLRX ? I can't see how any xorg.conf can load the Radeon driver for the card, since that driver cannot determine the display modes . I'll see about getting the 8970M card removed from my laptop so I can sell it on ebay - it is of no use to me in the computer. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 --- Comment #1 from yves.dufournaud at gmail.com --- there is another issue: resuming from suspend to ram is failing, I would have filled a separate bug, but apparently it can be linked to graphics. following the instruction here: https://01.org/linuxgraphics/documentation/development/how-debug-suspend-resume-issues S3 suspend (a.k.a Suspend To RAM): dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after the machine go to sleep : led blinking after pressing power button, make machine reboot. but dmesg_after exists with same content as dmesg_before, so quoting source: "If dmesg_after exists, it means that the system can be resumed from BIOS, so it's likely to be a graphics issue. Otherwise, it's not related to graphics and don't report it to freedesktop.org bugzilla." will try to set Enable "CONFIG_PM_DEBUG" for next test -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2] drm/amdgpu: Constify some tables
On Mon, Apr 25, 2016 at 3:31 PM, Nils Wallménius
wrote:
> Some more tables with constant data were added with the polaris support
>
> v2: missed a few
>
> Signed-off-by: Nils Wallménius
Applied. thanks!
Alex
> ---
> .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 32
> --
> .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h | 2 +-
> .../drm/amd/powerplay/hwmgr/polaris10_powertune.c | 14 +-
> .../drm/amd/powerplay/hwmgr/polaris10_thermal.c| 8 +++---
> .../gpu/drm/amd/powerplay/inc/polaris10_pwrvirus.h | 2 +-
> .../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 11
> 6 files changed, 36 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> index b146ec8..010199f 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
> @@ -99,16 +99,17 @@
> #define TCLK(PCIE_BUS_CLK / 10)
>
>
> -uint16_t polaris10_clock_stretcher_lookup_table[2][4] = { {600, 1050, 3, 0},
> - {600, 1050, 6, 1} };
> +static const uint16_t polaris10_clock_stretcher_lookup_table[2][4] =
> +{ {600, 1050, 3, 0}, {600, 1050, 6, 1} };
>
> /* [FF, SS] type, [] 4 voltage ranges, and [Floor Freq, Boundary Freq, VID
> min , VID max] */
> -uint32_t polaris10_clock_stretcher_ddt_table[2][4][4] = { { {265, 529, 120,
> 128}, {325, 650, 96, 119}, {430, 860, 32, 95}, {0, 0, 0, 31} },
> - { {275, 550, 104,
> 112}, {319, 638, 96, 103}, {360, 720, 64, 95}, {384, 768, 32, 63} } };
> +static const uint32_t polaris10_clock_stretcher_ddt_table[2][4][4] =
> +{ { {265, 529, 120, 128}, {325, 650, 96, 119}, {430, 860, 32, 95}, {0, 0, 0,
> 31} },
> + { {275, 550, 104, 112}, {319, 638, 96, 103}, {360, 720, 64, 95}, {384,
> 768, 32, 63} } };
>
> /* [Use_For_Low_freq] value, [0%, 5%, 10%, 7.14%, 14.28%, 20%] (coming from
> PWR_CKS_CNTL.stretch_amount reg spec) */
> -uint8_t polaris10_clock_stretch_amount_conversion[2][6] = { {0, 1, 3, 2, 4,
> 5},
> - {0, 2, 4, 5, 6,
> 5} };
> +static const uint8_t polaris10_clock_stretch_amount_conversion[2][6] =
> +{ {0, 1, 3, 2, 4, 5}, {0, 2, 4, 5, 6, 5} };
>
> /** Values for the CG_THERMAL_CTRL::DPM_EVENT_SRC field. */
> enum DPM_EVENT_SRC {
> @@ -119,7 +120,7 @@ enum DPM_EVENT_SRC {
> DPM_EVENT_SRC_DIGITAL_OR_EXTERNAL = 4
> };
>
> -const unsigned long PhwPolaris10_Magic = (unsigned long)(PHM_VIslands_Magic);
> +static const unsigned long PhwPolaris10_Magic = (unsigned
> long)(PHM_VIslands_Magic);
>
> struct polaris10_power_state *cast_phw_polaris10_power_state(
> struct pp_hw_power_state *hw_ps)
> @@ -1069,14 +1070,15 @@ static int
> polaris10_get_dependency_volt_by_clk(struct pp_hwmgr *hwmgr,
> return 0;
> }
>
> -sclkFcwRange_t Range_Table[NUM_SCLK_RANGE] = { {VCO_2_4, POSTDIV_DIV_BY_16,
> 75, 160, 112},
> - {VCO_3_6, POSTDIV_DIV_BY_16,
> 112, 224, 160},
> - {VCO_2_4, POSTDIV_DIV_BY_8,
> 75, 160, 112},
> - {VCO_3_6, POSTDIV_DIV_BY_8,
> 112, 224, 160},
> - {VCO_2_4, POSTDIV_DIV_BY_4,
> 75, 160, 112},
> - {VCO_3_6, POSTDIV_DIV_BY_4,
> 112, 216, 160},
> - {VCO_2_4, POSTDIV_DIV_BY_2,
> 75, 160, 108},
> - {VCO_3_6, POSTDIV_DIV_BY_2,
> 112, 216, 160} };
> +static const sclkFcwRange_t Range_Table[NUM_SCLK_RANGE] =
> +{ {VCO_2_4, POSTDIV_DIV_BY_16, 75, 160, 112},
> + {VCO_3_6, POSTDIV_DIV_BY_16, 112, 224, 160},
> + {VCO_2_4, POSTDIV_DIV_BY_8, 75, 160, 112},
> + {VCO_3_6, POSTDIV_DIV_BY_8, 112, 224, 160},
> + {VCO_2_4, POSTDIV_DIV_BY_4, 75, 160, 112},
> + {VCO_3_6, POSTDIV_DIV_BY_4, 112, 216, 160},
> + {VCO_2_4, POSTDIV_DIV_BY_2, 75, 160, 108},
> + {VCO_3_6, POSTDIV_DIV_BY_2, 112, 216, 160} };
>
> static void polaris10_get_sclk_range_table(struct pp_hwmgr *hwmgr)
> {
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
> b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
> index b022964..beedf35 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h
> @@ -264,7 +264,7 @@ struct polaris10_hwmgr {
> bool enable_tdc_limit_feature;
> bool enable_pkg_pwr_tracking_feature;
> bool disable_uvd_power_tune_feature;
> - struct polaris10_pt_defaults *power_tune_defaults;
> + const struct
[PATCH] drm/amd/powerplay: Delete dead struct declaration
On Sun, Apr 24, 2016 at 7:21 AM, Nils Wallménius wrote: > Signed-off-by: Nils Wallménius Applied, thanks! Alex > --- > drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h > b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h > index 35e1b36..1954cea 100644 > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h > @@ -29,7 +29,6 @@ > > extern int cz_phm_set_asic_block_gating(struct pp_hwmgr *hwmgr, enum > PHM_AsicBlock block, enum PHM_ClockGateSetting gating); > extern const struct phm_master_table_header > cz_phm_enable_clock_power_gatings_master; > -extern struct phm_master_table_header > cz_phm_disable_clock_power_gatings_master; > extern int cz_dpm_powergate_vce(struct pp_hwmgr *hwmgr, bool bgate); > extern int cz_dpm_powergate_uvd(struct pp_hwmgr *hwmgr, bool bgate); > extern int cz_enable_disable_vce_dpm(struct pp_hwmgr *hwmgr, bool enable); > -- > 2.8.0.rc3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amd/powerplay: Delete unused functions in ppevvmath.h
On Sun, Apr 24, 2016 at 7:22 AM, Nils Wallménius
wrote:
> Signed-off-by: Nils Wallménius
Let me check with the powerplay team and make sure they are planning
to use these in the near future.
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h | 59
> +
> 1 file changed, 1 insertion(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> index a9b40eb..8f50a03 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h
> @@ -64,7 +64,6 @@ static fInt fGetSquare(fInt);
> /* Returns the square
> static fInt fSqrt(fInt); /* Returns the
> Square Root of a fInt number */
>
> static int uAbs(int); /* Returns the
> Absolute value of the Int */
> -static fInt fAbs(fInt); /* Returns the
> Absolute value of the fInt */
> static int uPow(int base, int exponent); /* Returns
> base^exponent an INT */
>
> static void SolveQuadracticEqn(fInt, fInt, fInt, fInt[]); /* Returns the 2
> roots via the array */
> @@ -85,21 +84,12 @@ static fInt fDecodeLeakageID (uint32_t leakageID_fuse,
> fInt ln_max_div_min, fInt
> *
> -
> * Some of the following functions take two INTs as their input - This is
> unsafe for a variety of reasons.
> */
> -static fInt Add (int, int); /* Add two INTs
> and return Sum as FINT */
> -static fInt Multiply (int, int); /* Multiply two
> INTs and return Product as FINT */
> -static fInt Divide (int, int);/* You get the
> idea... */
> +static fInt Divide (int, int);/* Divide two INTs
> and return result as FINT */
> static fInt fNegate(fInt);
>
> static int uGetScaledDecimal (fInt); /* Internal
> function */
> static int GetReal (fInt A); /* Internal
> function */
>
> -/* Future Additions and Incomplete Functions
> - *
> -
> - */
> -static int GetRoundedValue(fInt); /* Incomplete
> function - Useful only when Precision is lacking */
> - /* Let us say we
> have 2.126 but can only handle 2 decimal points. We could */
> - /* either chop of
> 6 and keep 2.12 or use this function to get 2.13, which is more accurate */
> -
> /*
> -
> * TROUBLESHOOTING INFORMATION
> *
> -
> @@ -498,51 +488,12 @@ static void SolveQuadracticEqn(fInt A, fInt B, fInt C,
> fInt Roots[])
> *
> -
> */
>
> -/* Addition using two normal ints - Temporary - Use only for testing
> purposes?. */
> -static fInt Add (int X, int Y)
> -{
> - fInt A, B, Sum;
> -
> - A.full = (X << SHIFT_AMOUNT);
> - B.full = (Y << SHIFT_AMOUNT);
> -
> - Sum.full = A.full + B.full;
> -
> - return Sum;
> -}
> -
> /* Conversion Functions */
> static int GetReal (fInt A)
> {
> return (A.full >> SHIFT_AMOUNT);
> }
>
> -/* Temporarily Disabled */
> -static int GetRoundedValue(fInt A) /*For now, round the 3rd decimal place */
> -{
> - /* ROUNDING TEMPORARLY DISABLED
> - int temp = A.full;
> - int decimal_cutoff, decimal_mask = 0x01FF;
> - decimal_cutoff = temp & decimal_mask;
> - if (decimal_cutoff > 0x147) {
> - temp += 673;
> - }*/
> -
> - return ConvertBackToInteger(A)/1; /*Temporary - in case this was
> used somewhere else */
> -}
> -
> -static fInt Multiply (int X, int Y)
> -{
> - fInt A, B, Product;
> -
> - A.full = X << SHIFT_AMOUNT;
> - B.full = Y << SHIFT_AMOUNT;
> -
> - Product = fMultiply(A, B);
> -
> - return Product;
> -}
> -
> static fInt Divide (int X, int Y)
> {
> fInt A, B, Quotient;
> @@ -578,14 +529,6 @@ static int uPow(int base, int power)
> return (base)*uPow(base, power - 1);
> }
>
> -static fInt fAbs(fInt A)
> -{
> - if (A.partial.real < 0)
> - return (fMultiply(A, ConvertToFraction(-1)));
> - else
> - return A;
> -}
> -
> static int uAbs(int X)
> {
> if (X < 0)
> --
> 2.8.0.rc3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #14 from Alex Deucher --- It sounds like it's a bug in the intel driver. The radeon driver appears to be loading fine. Can you get any display on the intel card at all? You can blacklist the radeon driver (append modeprobe.blanklist=radeon to the kernel command line in grub) to get that out of the way. If you can't get any display on the intel card, I'd suggest updating the intel xorg driver or trying a different kernel to get a different intel kernel driver. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 Benjamin Bellec changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #108 from Benjamin Bellec --- (In reply to Michael Rosile from comment #107) > Thank you Alex Deucher! > I have the same graphics card as samdenies (XFX R9 270X), and was looking > through various mailing lists to find an answer (I wasn't expecting to find > an answer at bugs.freedesktop.org). I knew the issue was related to the > memory clock speed, but didn't know how to change it in Linux, until now. > > I manually added the required 'quirk' line to a custom 4.5.2 kernel, and > it's working great! This is not fixed at all: - there is probably several other videocards from other vendors which don't works (the Gigabyte "GV-R737WF2OC-2GD" for instance) - the quirk added underclocks the mclock from 5600 MHz to 4800 MHz, so you don't get the full performance you are expecting -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/41fe6d14/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #109 from Gustavo Lopes --- Not to mention that even with the quirk I would get (last time I tried) a hang every 1-2 days. Catalyst has been quite stable for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/e8cabb76/attachment.html>
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #15 from 3pb33h+1ymmkx54pslys at sharklasers.com --- Seems like alex made an typo i think it should be modprobe.blacklist=radeon -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #16 from Alex Deucher --- (In reply to 3pb33h+1ymmkx54pslys from comment #15) > Seems like alex made an typo i think it should be modprobe.blacklist=radeon Yes you are correct, sorry about that. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 --- Comment #2 from yves.dufournaud at gmail.com --- tested with CONFIG_PM_DEBUG with core/processors/device dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after machine resume after few second, but mouse pointer is lost (not visible/not acting) joined dmesg_after -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 --- Comment #3 from yves.dufournaud at gmail.com --- Created attachment 214301 --> https://bugzilla.kernel.org/attachment.cgi?id=214301&action=edit dmesg_after.txt output of dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 95078] [Bisected] dGPU broken in linux 4.4.7
https://bugs.freedesktop.org/show_bug.cgi?id=95078 --- Comment #3 from Niklas 'Nille' �kerstr�m --- Looking at the info i supplied in http://www.linuxquestions.org/questions/slackware-14/current-14-2-and-dri-3-and-dri_prime-ain't-working-4175578108/ It looks like it's related to 94874 only kernel versions differ. https://bugs.freedesktop.org/show_bug.cgi?id=94874 If the commit is reverted from the 4.4.y and 4.5.y this could be marked as solved. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/a178d2b0/attachment.html>
[RFC v2 0/8] drm: explicit fencing support
From: Gustavo Padovan Hi, Currently the Linux Kernel only have an implicit fencing mechanism where the fence are attached directly to buffers and userspace is unaware of what is happening. On the other hand explicit fencing which is not supported yet by Linux but it expose fences to the userspace to handle fencing between producer/consumer explicitely. For that we use the Android Sync Framework[1], a explicit fencing mechanism that help the userspace handles fences directly. It has the concept of sync_file (called sync_fence in Android) that expose the driver's fences to userspace via file descriptors. File descriptors are useful because we can pass them around between process. The Sync Framework is currently in the staging tree and on the process to be de-staged[2]. With explicit fencing we have a global mechanism that optimizes the flow of buffers between consumers and producers, avoid a lot of waiting. So instead of waiting for a buffer to be processed by the GPU before sending it to DRM in an Atomic IOCTL we can get a sync_file fd from the GPU driver at the moment we submit the buffer processing. The compositor then passes these fds to DRM in a atomic commit request, that will not be displayed until the fences signal, i.e, the GPU finished processing the buffer and it is ready to display. In DRM the fences we wait on before displaying a buffer are called in-fences. Vice-versa, we have out-fences, to sychronize the return of buffers to GPU (producer) to be processed again. When DRM receives an atomic request with a special flag set it generates one fence per-crtc and attach it to a per-crtc sync_file. It then returns the array of sync_file fds to userspace as an atomic_ioctl out arg. With the fences available userspace can forward these fences to the GPU, where it will wait the fence to signal before starting to process on buffer again. Explicit fencing with Sync Framework allows buffer suballocation. Userspace get a large buffer and divides it into small ones and submit requests to process them, each subbuffer gets and sync_file fd and can be processed in parallel. This is not even possible with implicit fencing. While these are out-fences in DRM (the consumer) they become in-fences once they get to the GPU (the producer). DRM explicit fences are opt-in, as the default will still be implicit fencing. To enable explicit in-fences one just need to pass a sync_file fd in the FENCE_FD plane property. *In-fences are per-plane*, i.e., per framebuffer. For out-fences, just enabling DRM_MODE_ATOMIC_OUT_FENCE flag is enough. *Out-fences are per-crtc*. In-fences - In the first discussions on #dri-devel on IRC we decided to hide the Sync Framework from DRM drivers to reduce complexity, so as soon we get the fd via FENCE_FD plane property we convert the sync_file fd to a struct fence. However a sync_file might contain more than one fence, so we created the fence_collection concept. struct fence_collection is a subclass of struct fence and stores a group of fences that needs to be waited together, in other words, all the fences in the sync_file. Then we just use the already in place fence support to wait on those fences. Once the producer calls fence_signal() for all fences on wait we can proceed with the atomic commit and display the framebuffers. DRM drivers only needs to be converted to struct fence to make use of this feature. Out-fences -- Passing the DRM_MODE_ATOMIC_OUT_FENCE flag to an atomic request enables out-fences. The kernel then creates a fence, attach it to a sync_file and install this file on a unused fd for each crtc. Userspace get the fence back as an array of per-crtc sync_file fds. DRM core use the already in place drm_event infrastructure to help signal fences, we've added a fence pointer to struct drm_pending_event. If the atomic update received requested an PAGE_FLIP_EVENT we just use the same drm_pending_event and set our fence there, otherwise we just create an event with a NULL file_priv to set our fence. On vblank we just call fence_signal() to signal that the buffer related to this fence is *now* on the screen. Note that this is exactly the opposite behaviour from Android, where the fences are signaled when they are not on display anymore, so free to be reused. No changes are required to DRM drivers to have out-fences support, apart from atomic support of course. Kernel tree --- For those who want all patches on this RFC are in my tree. The tree includes all sync frameworks patches needed at the moment: https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=fences I also hacked some poor some fake fences support to modetest here: https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic v2 changes -- The changes from RFC v1 to RFC v2 are in the patches description. TODO * upstream Android Sync ABI changes * de-stage Android Sync Framework * Upstream sync selftests (Emilio Lopez) * create tests
[RFC v2 3/8] dma-buf/sync_file: add sync_file_fences_get()
From: Gustavo Padovan
Creates a function that given an sync file descriptor returns a
fence_collection containing all fences in the sync_file.
If there is only one fence in the sync_file this fence itself is returned,
however if there is more than one, a fence_collection fence is returned.
v2: Comments by Daniel Vetter
- Adapt to new version of fence_collection_init()
- Hold a reference for the fence we return
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/sync_file.c | 60 +
include/linux/sync_file.h | 3 +++
2 files changed, 63 insertions(+)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 40ee098..5dd76c0 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -147,6 +148,62 @@ void sync_file_install(struct sync_file *sync_file, int fd)
}
EXPORT_SYMBOL(sync_file_install);
+/**
+ * sync_file_fences_get - get the fence(s) related to the sync_file fd
+ * @fd:sync_file fd to get the fence(s) from
+ *
+ * Ensures @fd references a valid sync_file and returns a fence that
+ * represents all fence in the sync_file.
+ *
+ * If there is only one fence in the sync_file, this fence is returned.
+ * If there is more than one, a fence_collection containing all fences
+ * is created and its base fence object is returned.
+ * On both cases a reference to the returned fence is held. On error
+ * NULL is returned.
+ */
+struct fence *sync_file_fences_get(int fd)
+{
+ struct sync_file *sync_file;
+ struct fence_collection *collection;
+ struct fence_collection_cb *cb;
+ int i;
+
+ sync_file = sync_file_fdget(fd);
+ if (!sync_file)
+ return NULL;
+
+ if (sync_file->num_fences == 1) {
+ struct fence *fence = sync_file->cbs[0].fence;
+
+ fence_get(fence);
+ sync_file_put(sync_file);
+ return fence;
+ }
+
+ cb = kcalloc(sync_file->num_fences, sizeof(*cb), GFP_KERNEL);
+ if (!cb) {
+ sync_file_put(sync_file);
+ return NULL;
+ }
+
+ for (i = 0 ; i < sync_file->num_fences ; i++)
+ cb[i].fence = sync_file->cbs[i].fence;
+
+ collection = fence_collection_create(sync_file->num_fences, cb);
+ if (!collection) {
+ kfree(cb);
+ sync_file_put(sync_file);
+ return NULL;
+ }
+
+ sync_file->collection = collection;
+ fence_get(&collection->base);
+ sync_file_put(sync_file);
+
+ return &collection->base;
+}
+EXPORT_SYMBOL(sync_file_fences_get);
+
static void sync_file_add_pt(struct sync_file *sync_file, int *i,
struct fence *fence)
{
@@ -234,6 +291,9 @@ static void sync_file_free(struct kref *kref)
kref);
int i;
+ if (sync_file->collection)
+ fence_put(&sync_file->collection->base);
+
for (i = 0; i < sync_file->num_fences; ++i) {
fence_remove_callback(sync_file->cbs[i].fence,
&sync_file->cbs[i].cb);
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 900fa0c..3eb3aad 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -35,6 +35,7 @@ struct sync_file_cb {
* @num_fences:number of sync_pts in the fence
* @wq:wait queue for fence signaling
* @status:0: signaled, >0:active, <0: error
+ * @collection:collection with the fences in the sync_file
* @cbs: sync_pts callback information
*/
struct sync_file {
@@ -49,6 +50,7 @@ struct sync_file {
wait_queue_head_t wq;
atomic_tstatus;
+ struct fence_collection *collection;
struct sync_file_cb cbs[];
};
@@ -59,4 +61,5 @@ void sync_file_install(struct sync_file *sync_file, int fd);
struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
struct sync_file *b);
+struct fence *sync_file_fences_get(int fd);
#endif /* _LINUX_SYNC_H */
--
2.5.5
[RFC v2 1/8] dma-buf/fence: add fence_collection fences
From: Gustavo Padovan
struct fence_collection inherits from struct fence and carries a
collection of fences that needs to be waited together.
It is useful to translate a sync_file to a fence to remove the complexity
of dealing with sync_files on DRM drivers. So even if there are many
fences in the sync_file that needs to waited for a commit to happen,
they all get added to the fence_collection and passed for DRM use as
a standard struct fence.
That means that no changes needed to any driver besides supporting fences.
fence_collection's fence doesn't belong to any timeline context, so
fence_is_later() and fence_later() are not meant to be called with
fence_collections fences.
v2: Comments by Daniel Vetter:
- merge fence_collection_init() and fence_collection_add()
- only add callbacks at ->enable_signalling()
- remove fence_collection_put()
- check for type on to_fence_collection()
- adjust fence_is_later() and fence_later() to WARN_ON() if they
are used with collection fences.
Signed-off-by: Gustavo Padovan
---
drivers/dma-buf/Makefile | 2 +-
drivers/dma-buf/fence-collection.c | 159 +
drivers/dma-buf/fence.c| 2 +-
include/linux/fence-collection.h | 73 +
include/linux/fence.h | 9 +++
5 files changed, 243 insertions(+), 2 deletions(-)
create mode 100644 drivers/dma-buf/fence-collection.c
create mode 100644 include/linux/fence-collection.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 4a424ec..52f818f 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,2 +1,2 @@
-obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
+obj-y := dma-buf.o fence.o reservation.o seqno-fence.o fence-collection.o
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
diff --git a/drivers/dma-buf/fence-collection.c
b/drivers/dma-buf/fence-collection.c
new file mode 100644
index 000..88872e5
--- /dev/null
+++ b/drivers/dma-buf/fence-collection.c
@@ -0,0 +1,159 @@
+/*
+ * fence-collection: aggregate fences to be waited together
+ *
+ * Copyright (C) 2016 Collabora Ltd
+ * Authors:
+ * Gustavo Padovan
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+
+static const char *fence_collection_get_driver_name(struct fence *fence)
+{
+ struct fence_collection *collection = to_fence_collection(fence);
+ struct fence *f = collection->fences[0].fence;
+
+ return f->ops->get_driver_name(fence);
+}
+
+static const char *fence_collection_get_timeline_name(struct fence *fence)
+{
+ return "no context";
+}
+
+static void collection_check_cb_func(struct fence *fence, struct fence_cb *cb)
+{
+ struct fence_collection_cb *f_cb;
+ struct fence_collection *collection;
+
+ f_cb = container_of(cb, struct fence_collection_cb, cb);
+ collection = f_cb->collection;
+
+ if (atomic_dec_and_test(&collection->num_pending_fences))
+ fence_signal(&collection->base);
+}
+
+static bool fence_collection_enable_signaling(struct fence *fence)
+{
+ struct fence_collection *collection = to_fence_collection(fence);
+ int i;
+
+ for (i = 0 ; i < collection->num_fences ; i++) {
+ if (fence_add_callback(collection->fences[i].fence,
+ &collection->fences[i].cb,
+ collection_check_cb_func)) {
+ atomic_dec(&collection->num_pending_fences);
+ return false;
+ }
+ }
+
+ return !!atomic_read(&collection->num_pending_fences);
+}
+
+static bool fence_collection_signaled(struct fence *fence)
+{
+ struct fence_collection *collection = to_fence_collection(fence);
+
+ return (atomic_read(&collection->num_pending_fences) == 0);
+}
+
+static void fence_collection_release(struct fence *fence)
+{
+ struct fence_collection *collection = to_fence_collection(fence);
+ int i;
+
+ for (i = 0 ; i < collection->num_fences ; i++)
+ fence_put(collection->fences[i].fence);
+
+ kfree(collection->fences);
+ fence_free(fence);
+}
+
+static signed long fence_collection_wait(struct fence *fence, bool intr,
+signed long timeout)
+{
+ struct fence_collection *collection = to_fence_collection(fence);
+ int i;
+
+ if (test_bit(FENCE_FLAG_SIGNALED_BIT, &fence->flags))
+ return timeout;
+
+ fence_e
[RFC v2 8/8] drm/fence: add out-fences support
From: Gustavo Padovan
Support DRM out-fences creating a sync_file with a fence for each crtc
update with the DRM_MODE_ATOMIC_OUT_FENCE flag.
We then send an struct drm_out_fences array with the out-fences fds back in
the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.
struct drm_out_fences {
__u32 crtc_id;
__u32 fd;
};
v2: Comment by Rob Clark:
- Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
Comment by Daniel Vetter:
- Add clean up code for out_fences
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c | 163 +--
include/drm/drm_crtc.h | 10 +++
include/uapi/drm/drm_mode.h | 11 ++-
3 files changed, 179 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5f9d434..06c6007 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1566,6 +1566,133 @@ void drm_atomic_clean_old_fb(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_clean_old_fb);
+static struct drm_out_fence_state *get_out_fence(struct drm_device *dev,
+struct drm_atomic_state *state,
+uint32_t __user
*out_fences_ptr,
+uint64_t count_out_fences,
+uint64_t user_data)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_out_fences *out_fences;
+ struct drm_out_fence_state *fence_state;
+ int num_fences = 0;
+ int i, ret;
+
+ if (count_out_fences > dev->mode_config.num_crtc)
+ return ERR_PTR(-EINVAL);
+
+ out_fences = kcalloc(count_out_fences, sizeof(*out_fences),
+GFP_KERNEL);
+ if (!out_fences)
+ return ERR_PTR(-ENOMEM);
+
+ fence_state = kcalloc(count_out_fences, sizeof(*fence_state),
+GFP_KERNEL);
+ if (!fence_state) {
+ kfree(out_fences);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ for (i = 0 ; i < count_out_fences ; i++)
+ fence_state[i].fd = -1;
+
+ for_each_crtc_in_state(state, crtc, crtc_state, i) {
+ struct drm_pending_vblank_event *e;
+ struct fence *fence;
+ char name[32];
+
+ fence = kzalloc(sizeof(*fence), GFP_KERNEL);
+ if (!fence) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ fence_init(fence, &drm_crtc_fence_ops, &crtc->fence_lock,
+ crtc->fence_context, crtc->fence_seqno);
+
+ snprintf(name, sizeof(name), "crtc-%d_%lu",
+drm_crtc_index(crtc), crtc->fence_seqno++);
+
+ fence_state[i].fd = get_unused_fd_flags(O_CLOEXEC);
+ if (fence_state[i].fd < 0) {
+ fence_put(fence);
+ ret = fence_state[i].fd;
+ goto out;
+ }
+
+ fence_state[i].sync_file = sync_file_create(name, fence);
+ if(!fence_state[i].sync_file) {
+ fence_put(fence);
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ if (crtc_state->event) {
+ crtc_state->event->base.fence = fence;
+ } else {
+ e = create_vblank_event(dev, NULL, fence, user_data);
+ if (!e) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ crtc_state->event = e;
+ }
+
+ out_fences[num_fences].crtc_id = crtc->base.id;
+ out_fences[num_fences].fd = fence_state[i].fd;
+ num_fences++;
+ }
+
+ if (copy_to_user(out_fences_ptr, out_fences,
+num_fences * sizeof(*out_fences))) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ kfree(out_fences);
+
+ return fence_state;
+
+out:
+ for (i = 0 ; i < count_out_fences ; i++) {
+ if (fence_state[i].sync_file)
+ sync_file_put(fence_state[i].sync_file);
+ if (fence_state[i].fd >= 0)
+ put_unused_fd(fence_state[i].fd);
+ }
+
+ kfree(fence_state);
+ kfree(out_fences);
+
+ return ERR_PTR(ret);
+}
+
+static void install_out_fence(uint64_t count_out_fences,
+ struct drm_out_fence_state *state)
+{
+ int i;
+
+ for (i = 0 ; i < count_out_fences ; i++) {
+ if (state[i].sync_file)
+ sync_file_install(state[i].sync_file, state[i].fd);
+ }
+}
+
+static void release_out_fence(
[RFC v2 2/8] Documentation: add fence-collection to kernel DocBook
From: Gustavo Padovan Include fence-collection files in the DocBook. Signed-off-by: Gustavo Padovan --- Documentation/DocBook/device-drivers.tmpl | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 509a187..68539e5 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -132,8 +132,10 @@ X!Edrivers/base/interface.c !Edrivers/dma-buf/dma-buf.c !Edrivers/dma-buf/fence.c !Edrivers/dma-buf/seqno-fence.c +!Edrivers/dma-buf/fence-collection.c !Iinclude/linux/fence.h !Iinclude/linux/seqno-fence.h +!Iinclude/linux/fence-collection.h !Edrivers/dma-buf/reservation.c !Iinclude/linux/reservation.h !Edrivers/dma-buf/sync_file.c -- 2.5.5
[RFC v2 4/8] drm/fence: allow fence waiting to be interrupted by userspace
From: Gustavo Padovan
If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.
Also adds the necessary error checking for fence_wait().
v2: Comment by Daniel Vetter
- Add error checking for fence_wait()
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic_helper.c | 21 +++--
include/drm/drm_atomic_helper.h | 4 ++--
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7bf678e..f1cfcce 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -993,13 +993,15 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_enables);
* incoming fb's and stash it in the drm_plane_state. This is called after
* drm_atomic_helper_swap_state() so it uses the current plane state (and
* just uses the atomic state to find the changed planes)
+ *
+ * Return 0 on sucess or < 0 on error.
*/
-void drm_atomic_helper_wait_for_fences(struct drm_device *dev,
- struct drm_atomic_state *state)
+int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
+ struct drm_atomic_state *state)
{
struct drm_plane *plane;
struct drm_plane_state *plane_state;
- int i;
+ int i, ret;
for_each_plane_in_state(state, plane, plane_state, i) {
if (!plane->state->fence)
@@ -1007,10 +1009,14 @@ void drm_atomic_helper_wait_for_fences(struct
drm_device *dev,
WARN_ON(!plane->state->fb);
- fence_wait(plane->state->fence, false);
+ ret = fence_wait(plane->state->fence, true);
+ if (ret)
+ return ret;
fence_put(plane->state->fence);
plane->state->fence = NULL;
}
+
+ return 0;
}
EXPORT_SYMBOL(drm_atomic_helper_wait_for_fences);
@@ -1174,7 +1180,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
* current layout.
*/
- drm_atomic_helper_wait_for_fences(dev, state);
+ ret = drm_atomic_helper_wait_for_fences(dev, state);
+ if (ret)
+ goto out;
drm_atomic_helper_commit_modeset_disables(dev, state);
@@ -1184,11 +1192,12 @@ int drm_atomic_helper_commit(struct drm_device *dev,
drm_atomic_helper_wait_for_vblanks(dev, state);
+out:
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_state_free(state);
- return 0;
+ return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_commit);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index fe9d89c..3a5d2e5 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -42,8 +42,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
struct drm_atomic_state *state,
bool async);
-void drm_atomic_helper_wait_for_fences(struct drm_device *dev,
- struct drm_atomic_state *state);
+int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
+ struct drm_atomic_state *state);
bool drm_atomic_helper_framebuffer_changed(struct drm_device *dev,
struct drm_atomic_state *old_state,
struct drm_crtc *crtc);
--
2.5.5
[RFC v2 5/8] drm/fence: add in-fences support
From: Gustavo Padovan
There is now a new property called FENCE_FD attached to every plane
state that receives the sync_file fd from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_collection
subclass or just a normal fence) and then used by DRM to fence_wait() for
all fences in the sync_file to signal. So it only commits when all
framebuffers are ready to scanout.
Signed-off-by: Gustavo Padovan
v2: Comments by Daniel Vetter:
- remove set state->fence = NULL in destroy phase
- accept fence -1 as valid and just return 0
- do not call fence_get() - sync_file_fences_get() already calls it
- fence_put() if state->fence is already set, in case userspace
set the property more than once.
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_atomic.c| 14 ++
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
drivers/gpu/drm/drm_crtc.c | 7 +++
include/drm/drm_crtc.h | 1 +
5 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f2a74d0..3c987e3 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select I2C
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
+ select SYNC_FILE
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8ee1db8..13674c7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/**
* drm_atomic_state_default_release -
@@ -680,6 +681,17 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
drm_framebuffer_unreference(fb);
+ } else if (property == config->prop_fence_fd) {
+ if (U642I64(val) == -1)
+ return 0;
+
+ if (state->fence)
+ fence_put(state->fence);
+
+ state->fence = sync_file_fences_get(val);
+ if (!state->fence)
+ return -EINVAL;
+
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, val);
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -737,6 +749,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
if (property == config->prop_fb_id) {
*val = (state->fb) ? state->fb->base.id : 0;
+ } else if (property == config->prop_fence_fd) {
+ *val = -1;
} else if (property == config->prop_crtc_id) {
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->prop_crtc_x) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index f1cfcce..866f332 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2696,6 +2696,9 @@ void __drm_atomic_helper_plane_destroy_state(struct
drm_plane *plane,
{
if (state->fb)
drm_framebuffer_unreference(state->fb);
+
+ if (state->fence)
+ fence_put(state->fence);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 55ffde5..65212ce 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1278,6 +1278,7 @@ int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(&plane->base, config->prop_fb_id, 0);
+ drm_object_attach_property(&plane->base, config->prop_fence_fd,
-1);
drm_object_attach_property(&plane->base, config->prop_crtc_id,
0);
drm_object_attach_property(&plane->base, config->prop_crtc_x,
0);
drm_object_attach_property(&plane->base, config->prop_crtc_y,
0);
@@ -1533,6 +1534,12 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_fb_id = prop;
+ prop = drm_property_create_signed_range(dev, DRM_MODE_PROP_ATOMIC,
+ "FENCE_FD", -1, INT_MAX);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.prop_fence_fd = prop;
+
prop = drm_property_create_object(dev, DRM_MODE_PROP_ATOMIC,
"CRTC_ID", DRM_MODE_OBJECT_CRTC);
if (!prop)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8cb377c..5ba3cda 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2122,6 +2122,7 @@ struct drm_mode_config {
struct
[RFC v2 7/8] drm/fence: add fence timeline to drm_crtc
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init() to be
used by the fence.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_crtc.c | 29 +
include/drm/drm_crtc.h | 19 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 65212ce..cf9750a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -659,6 +659,32 @@ static unsigned int drm_num_crtcs(struct drm_device *dev)
return num;
}
+static const char *drm_crtc_fence_get_driver_name(struct fence *fence)
+{
+ struct drm_crtc *crtc = fence_to_crtc(fence);
+
+ return crtc->dev->driver->name;
+}
+
+static const char *drm_crtc_fence_get_timeline_name(struct fence *fence)
+{
+ struct drm_crtc *crtc = fence_to_crtc(fence);
+
+ return crtc->name;
+}
+
+static bool drm_crtc_fence_enable_signaling(struct fence *fence)
+{
+ return true;
+}
+
+const struct fence_ops drm_crtc_fence_ops = {
+ .get_driver_name = drm_crtc_fence_get_driver_name,
+ .get_timeline_name = drm_crtc_fence_get_timeline_name,
+ .enable_signaling = drm_crtc_fence_enable_signaling,
+ .wait = fence_default_wait,
+};
+
/**
* drm_crtc_init_with_planes - Initialise a new CRTC object with
*specified primary and cursor planes.
@@ -709,6 +735,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
return -ENOMEM;
}
+ crtc->fence_context = fence_context_alloc(1);
+ spin_lock_init(&crtc->fence_lock);
+
crtc->base.properties = &crtc->properties;
list_add_tail(&crtc->head, &config->crtc_list);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5ba3cda..d8c32c8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -715,6 +716,9 @@ struct drm_crtc_funcs {
* @helper_private: mid-layer private data
* @properties: property tracking for this CRTC
* @state: current atomic state for this CRTC
+ * @fence_context: context for fence signalling
+ * @fence_lock: fence lock for the fence context
+ * @fence_seqno: seqno variable to create fences
* @acquire_ctx: per-CRTC implicit acquire context used by atomic drivers for
* legacy IOCTLs
*
@@ -771,6 +775,11 @@ struct drm_crtc {
struct drm_crtc_state *state;
+ /* fence timelines info for DRM out-fences */
+ unsigned int fence_context;
+ spinlock_t fence_lock;
+ unsigned long fence_seqno;
+
/*
* For legacy crtc IOCTLs so that atomic drivers can get at the locking
* acquire context.
@@ -778,6 +787,16 @@ struct drm_crtc {
struct drm_modeset_acquire_ctx *acquire_ctx;
};
+extern const struct fence_ops drm_crtc_fence_ops;
+
+static inline struct drm_crtc *fence_to_crtc(struct fence *fence)
+{
+ if (fence->ops != &drm_crtc_fence_ops)
+ return NULL;
+
+ return container_of(fence->lock, struct drm_crtc, fence_lock);
+}
+
/**
* struct drm_connector_state - mutable connector state
* @connector: backpointer to the connector
--
2.5.5
[RFC v2 6/8] drm/fence: add fence to drm_pending_event
From: Gustavo Padovan
Now a drm_pending_event can either send a real drm_event or signal a
fence, or both. It allow us to signal via fences when the buffer is
displayed on the screen. Which in turn means that the previous buffer
is not in use anymore and can be freed or sent back to another driver
for processing.
v2: Comments from Daniel Vetter
- call fence_signal in drm_send_event_locked()
- remove unneeded !e->event check
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic.c | 19 +--
drivers/gpu/drm/drm_fops.c | 8 +++-
include/drm/drmP.h | 2 ++
3 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 13674c7..5f9d434 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1437,7 +1437,8 @@ EXPORT_SYMBOL(drm_atomic_async_commit);
*/
static struct drm_pending_vblank_event *create_vblank_event(
- struct drm_device *dev, struct drm_file *file_priv, uint64_t
user_data)
+ struct drm_device *dev, struct drm_file *file_priv,
+ struct fence *fence, uint64_t user_data)
{
struct drm_pending_vblank_event *e = NULL;
int ret;
@@ -1450,12 +1451,17 @@ static struct drm_pending_vblank_event
*create_vblank_event(
e->event.base.length = sizeof(e->event);
e->event.user_data = user_data;
- ret = drm_event_reserve_init(dev, file_priv, &e->base, &e->event.base);
- if (ret) {
- kfree(e);
- return NULL;
+ if (file_priv) {
+ ret = drm_event_reserve_init(dev, file_priv, &e->base,
+&e->event.base);
+ if (ret) {
+ kfree(e);
+ return NULL;
+ }
}
+ e->base.fence = fence;
+
return e;
}
@@ -1682,7 +1688,8 @@ retry:
for_each_crtc_in_state(state, crtc, crtc_state, i) {
struct drm_pending_vblank_event *e;
- e = create_vblank_event(dev, file_priv, arg->user_data);
+ e = create_vblank_event(dev, file_priv, NULL,
+ arg->user_data);
if (!e) {
ret = -ENOMEM;
goto out;
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index aeef58e..7872635 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -801,8 +801,14 @@ void drm_send_event_locked(struct drm_device *dev, struct
drm_pending_event *e)
{
assert_spin_locked(&dev->event_lock);
+ if (e->fence) {
+ fence_signal(e->fence);
+ fence_put(e->fence);
+ }
+
if (!e->file_priv) {
- e->destroy(e);
+ if (e->destroy)
+ e->destroy(e);
return;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3c8422c..2ae6d7e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -56,6 +56,7 @@
#include
#include
#include
+#include
#include
#include
@@ -282,6 +283,7 @@ struct drm_ioctl_desc {
/* Event queued up for userspace to read */
struct drm_pending_event {
struct drm_event *event;
+ struct fence *fence;
struct list_head link;
struct list_head pending_link;
struct drm_file *file_priv;
--
2.5.5
[Bug 92258] [regression] Opening menu in Steam running via DRI_PRIME with enabled DRI3 could lead to radeon kernel module crash
https://bugs.freedesktop.org/show_bug.cgi?id=92258 --- Comment #40 from Vladislav Kamenev --- cannot encounter freeze while using kernel with ZEN patches. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f667fc1c/attachment.html>
[RFC v2 0/8] drm: explicit fencing support
nces support, apart > from > atomic support of course. > > Kernel tree > --- > > For those who want all patches on this RFC are in my tree. The tree > includes > all sync frameworks patches needed at the moment: > > > https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=fences > > I also hacked some poor some fake fences support to modetest here: > > https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic > > > v2 changes > -- > > The changes from RFC v1 to RFC v2 are in the patches description. > > TODO > > > * upstream Android Sync ABI changes > * de-stage Android Sync Framework > * Upstream sync selftests (Emilio Lopez) > * create tests for DRM fences > > Regards, > > Gustavo > --- > > [1] https://source.android.com/devices/graphics/implement.html#vsync > [2] > https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=sync > > Gustavo Padovan (8): > dma-buf/fence: add fence_collection fences > Documentation: add fence-collection to kernel DocBook > dma-buf/sync_file: add sync_file_fences_get() > drm/fence: allow fence waiting to be interrupted by userspace > drm/fence: add in-fences support > drm/fence: add fence to drm_pending_event > drm/fence: add fence timeline to drm_crtc > drm/fence: add out-fences support > > Documentation/DocBook/device-drivers.tmpl | 2 + > drivers/dma-buf/Makefile | 2 +- > drivers/dma-buf/fence-collection.c| 159 > drivers/dma-buf/fence.c | 2 +- > drivers/dma-buf/sync_file.c | 60 + > drivers/gpu/drm/Kconfig | 1 + > drivers/gpu/drm/drm_atomic.c | 196 > -- > drivers/gpu/drm/drm_atomic_helper.c | 24 +++- > drivers/gpu/drm/drm_crtc.c| 36 ++ > drivers/gpu/drm/drm_fops.c| 8 +- > include/drm/drmP.h| 2 + > include/drm/drm_atomic_helper.h | 4 +- > include/drm/drm_crtc.h| 30 + > include/linux/fence-collection.h | 73 +++ > include/linux/fence.h | 9 ++ > include/linux/sync_file.h | 3 + > include/uapi/drm/drm_mode.h | 11 +- > 17 files changed, 600 insertions(+), 22 deletions(-) > create mode 100644 drivers/dma-buf/fence-collection.c > create mode 100644 include/linux/fence-collection.h > > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/356c86d0/attachment-0001.html>
