[RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
Hello Gustavo!
Gustavo Padovan wrote:
> Hi Tobias,
>
> 2015-04-15 Tobias Jakobi :
>
>> This struct encapsulates the configuration for a plane
>> object. The pixel format config is currently unused.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
>> drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
>> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
>> drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
>> 7 files changed, 67 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> index 84a3638..ca70599 100644
>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> @@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct device
>> *master, void *data)
>> struct decon_context *ctx = dev_get_drvdata(dev);
>> struct drm_device *drm_dev = data;
>> struct exynos_drm_plane *exynos_plane;
>> -enum drm_plane_type type;
>> -unsigned int zpos;
>> +struct exynos_drm_plane_config plane_config = { 0 };
>> +unsigned int i;
>> int ret;
>>
>> ret = decon_ctx_initialize(ctx, drm_dev);
>> @@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct
>> device *master, void *data)
>> return ret;
>> }
>>
>> -for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
>> -type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
>> -DRM_PLANE_TYPE_OVERLAY;
>> -ret = exynos_plane_init(drm_dev, >planes[zpos],
>> -1 << ctx->pipe, type, zpos);
>> +plane_config.possible_crtcs = 1 << ctx->pipe;
>> +
>> +for (i = 0; i < WINDOWS_NR; i++) {
>> +plane_config.type = (i == ctx->default_win) ?
>> +DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
>> +plane_config.zpos = i;
>> +
>> +ret = exynos_plane_init(drm_dev, >planes[i],
>> _config);
>> if (ret)
>> return ret;
>> }
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 4c14a89..35698f3 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -116,6 +116,25 @@ struct exynos_drm_plane {
>> };
>>
>> /*
>> + * Exynos DRM plane configuration structure.
>> + *
>> + * @possible_crtcs: bitfield describing the valid CRTCs
>> + * for this plane.
>> + * @type: plane type (primary, overlay, etc.)
>> + * @zpos: z-position of the plane.
>> + * @pixel_formats: supported pixel formats.
>> + * @num_pixel_formats: number of elements in 'pixel_formats'.
>> + */
>> +
>> +struct exynos_drm_plane_config {
>> +unsigned long possible_crtcs;
>> +enum drm_plane_type type;
>> +unsigned int zpos;
>> +const uint32_t *pixel_formats;
>> +unsigned int num_pixel_formats;
>> +};
>
> As a follow up of my atomic series I started cleaning up exynos drm a bit more
> and right now I'm removing most of struct exynos_drm_plane. Most of the plane
> information there is also present in plane->state thus I'm basically removing
> all the duplicated information there.
Sounds like a good plan.
> That said, I think we avoid creating exynos_drm_plane_config and stuff
> everything directly in struct exynos_drm_plane, it will be quite small and
> easier to manipulate.
So that would imply that we then just have:
int exynos_plane_init(struct drm_device *dev, struct exynos_drm_plane
*exynos_plane);
Correct?
Anyway, I'm going to wait then until the cleanups are posted and rebase
this series onto it.
With best wishes,
Tobias
[RFC 2/6] drm/exynos: remove used 'activated' field from exynos_drm_plane
Gustavo Padovan wrote: > Hi Tobias, > > 2015-04-15 Tobias Jakobi : > >> Signed-off-by: Tobias Jakobi > > I think you mean "unused" in the commit subject. And would also be good to > have some commit message as well. Other than that: Right, I'm going to change that and respin the series! With best wishes, Tobias
[PATCH v2 2/2] drm/exynos: remove unused 'activated' field from exynos_drm_plane
No component of Exynos DRM uses this field. Perhaps it was
once meant to provide more fine-grained information in
addition to the status stored in the 'enabled' field.
Reviewed-by: Gustavo Padovan
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6a849cf..4c14a89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -77,7 +77,6 @@ extern void exynos4412_qos(u8 tm, u8 ac);
* @color_key: color key on or off.
* @local_path: in case of lcd type, local path mode on or off.
* @transparency: transparency on or off.
- * @activated: activated or not.
* @enabled: enabled or not.
* @resume: to resume or not.
*
@@ -112,7 +111,6 @@ struct exynos_drm_plane {
bool color_key:1;
bool local_path:1;
bool transparency:1;
- bool activated:1;
bool enabled:1;
bool resume:1;
};
--
2.0.5
[PATCH v2 1/2] drm/exynos: mixer: move pixelformat defines
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Also add handling of RGB565 and exit if the pixelformat is not
supported.
Reviewed-by: Gustavo Padovan
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 3e07f04..9c398d5 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -44,6 +44,11 @@
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN 0
+#define MIXER_PIXELFORMAT_RGB565 4
+#define MIXER_PIXELFORMAT_ARGB1555 5
+#define MIXER_PIXELFORMAT_ARGB 6
+#define MIXER_PIXELFORMAT_ARGB 7
+
struct mixer_resources {
int irq;
void __iomem*mixer_regs;
@@ -536,31 +541,30 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
plane = >planes[win];
- #define RGB565 4
- #define ARGB1555 5
- #define ARGB 6
- #define ARGB 7
-
switch (plane->pixel_format) {
case DRM_FORMAT_ARGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
break;
case DRM_FORMAT_ARGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
break;
case DRM_FORMAT_XRGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 0;
break;
- default:
- fmt = ARGB;
+ case DRM_FORMAT_RGB565:
+ fmt = MIXER_PIXELFORMAT_RGB565;
blend = 0;
break;
+
+ default:
+ DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
+ return;
}
/* check if mixer supports requested scaling setup */
--
2.0.5
drm/exynos: two small fixes
Hello, I've dropped the remaining patches. Going to resend them once Gustavo's cleanups have landed. So this leaves just the small fry. Series is still based on [1]. With best wishes, Tobias [1] http://www.spinics.net/lists/linux-samsung-soc/msg43103.html P.S.: I'm not sure if the two remaining patches from [1] still apply cleanly to exynos-drm-next.
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On 04/15/2015 05:26 PM, Mario Kleiner wrote:
> A couple of questions to educate me and one review comment.
>
> On 04/15/2015 07:34 PM, Daniel Vetter wrote:
>> This was a bit too much cargo-culted, so lets make it solid:
>> - vblank->count doesn't need to be an atomic, writes are always done
>>under the protection of dev->vblank_time_lock. Switch to an unsigned
>>long instead and update comments. Note that atomic_read is just a
>>normal read of a volatile variable, so no need to audit all the
>>read-side access specifically.
>>
>> - The barriers for the vblank counter seqlock weren't complete: The
>>read-side was missing the first barrier between the counter read and
>>the timestamp read, it only had a barrier between the ts and the
>>counter read. We need both.
>>
>> - Barriers weren't properly documented. Since barriers only work if
>>you have them on boths sides of the transaction it's prudent to
>>reference where the other side is. To avoid duplicating the
>>write-side comment 3 times extract a little store_vblank() helper.
>>In that helper also assert that we do indeed hold
>>dev->vblank_time_lock, since in some cases the lock is acquired a
>>few functions up in the callchain.
>>
>> Spotted while reviewing a patch from Chris Wilson to add a fastpath to
>> the vblank_wait ioctl.
>>
>> v2: Add comment to better explain how store_vblank works, suggested by
>> Chris.
>>
>> v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the
>> implicit barrier in the spin_unlock. But that can only be proven by
>> auditing all callers and my point in extracting this little helper was
>> to localize all the locking into just one place. Hence I think that
>> additional optimization is too risky.
>>
>> Cc: Chris Wilson
>> Cc: Mario Kleiner
>> Cc: Ville Syrjälä
>> Cc: Michel Dänzer
>> Cc: Peter Hurley
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_irq.c | 95
>> +--
>> include/drm/drmP.h| 8 +++-
>> 2 files changed, 57 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index c8a34476570a..8694b77d0002 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -74,6 +74,36 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay,
>> int, 0600);
>> module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
>> 0600);
>> module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int,
>> 0600);
>>
>> +static void store_vblank(struct drm_device *dev, int crtc,
>> + unsigned vblank_count_inc,
>> + struct timeval *t_vblank)
>> +{
>> +struct drm_vblank_crtc *vblank = >vblank[crtc];
>> +u32 tslot;
>> +
>> +assert_spin_locked(>vblank_time_lock);
>> +
>> +if (t_vblank) {
>> +/* All writers hold the spinlock, but readers are serialized by
>> + * the latching of vblank->count below.
>> + */
>> +tslot = vblank->count + vblank_count_inc;
>> +vblanktimestamp(dev, crtc, tslot) = *t_vblank;
>> +}
>> +
>> +/*
>> + * vblank timestamp updates are protected on the write side with
>> + * vblank_time_lock, but on the read side done locklessly using a
>> + * sequence-lock on the vblank counter. Ensure correct ordering using
>> + * memory barrriers. We need the barrier both before and also after the
>> + * counter update to synchronize with the next timestamp write.
>> + * The read-side barriers for this are in drm_vblank_count_and_time.
>> + */
>> +smp_wmb();
>> +vblank->count += vblank_count_inc;
>> +smp_wmb();
>> +}
>> +
>> /**
>>* drm_update_vblank_count - update the master vblank counter
>>* @dev: DRM device
>> @@ -93,7 +123,7 @@ module_param_named(timestamp_monotonic,
>> drm_timestamp_monotonic, int, 0600);
>> static void drm_update_vblank_count(struct drm_device *dev, int crtc)
>> {
>> struct drm_vblank_crtc *vblank = >vblank[crtc];
>> -u32 cur_vblank, diff, tslot;
>> +u32 cur_vblank, diff;
>> bool rc;
>> struct timeval t_vblank;
>>
>> @@ -129,18 +159,12 @@ static void drm_update_vblank_count(struct drm_device
>> *dev, int crtc)
>> if (diff == 0)
>> return;
>>
>> -/* Reinitialize corresponding vblank timestamp if high-precision query
>> - * available. Skip this step if query unsupported or failed. Will
>> - * reinitialize delayed at next vblank interrupt in that case.
>> +/*
>> + * Only reinitialize corresponding vblank timestamp if high-precision
>> query
>> + * available and didn't fail. Will reinitialize delayed at next vblank
>> + * interrupt in that case.
>>*/
>> -if (rc) {
>> -tslot = atomic_read(>count) + diff;
>> -vblanktimestamp(dev, crtc, tslot) = t_vblank;
>> -}
>> -
>> -smp_mb__before_atomic();
>> -atomic_add(diff, >count);
>> -
[Bug 90042] Age of Wonders III gpu lockup
https://bugs.freedesktop.org/show_bug.cgi?id=90042 --- Comment #1 from dawide2211 at gmail.com --- Created attachment 115095 --> https://bugs.freedesktop.org/attachment.cgi?id=115095=edit glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/5010926f/attachment.html>
[Bug 96361] [Bisected, radeon]Non-infinite boot loop since v3.13
https://bugzilla.kernel.org/show_bug.cgi?id=96361 --- Comment #5 from servuswiegehtz at yahoo.de --- is there anything else I can provide? logs, try some modified kernels etc? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90042] Age of Wonders III gpu lockup
https://bugs.freedesktop.org/show_bug.cgi?id=90042 Bug ID: 90042 Summary: Age of Wonders III gpu lockup Product: Mesa Version: 10.5 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: dawide2211 at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 115094 --> https://bugs.freedesktop.org/attachment.cgi?id=115094=edit Journalctl I'm using an HD6750 on Arch Linux with the latest updates. The gpu lockup when I try to start a new game. The main menu and the intro to the missions seems to work fine, the lockup happens whenever the game try start a map. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/845ced9d/attachment-0001.html>
[Bug 96721] New: radeon: unable to handle kernel paging request with counter strike: go
https://bugzilla.kernel.org/show_bug.cgi?id=96721 Bug ID: 96721 Summary: radeon: unable to handle kernel paging request with counter strike: go Product: Drivers Version: 2.5 Kernel Version: 4.0 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: haagch.christoph at googlemail.com Regression: No Created attachment 174121 --> https://bugzilla.kernel.org/attachment.cgi?id=174121=edit dmesg Playing counter strike: global offensive with mesa git and PRIME on 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) After a while the graphical output froze with BUG: unable to handle kernel paging request at 8002a30769f8. IP: [] reservation_object_add_shared_fence+0x17b/0x2b0 Call Trace: [] ttm_eu_fence_buffer_objects+0x55/0xb0 [ttm] [] radeon_cs_parser_fini+0x20b/0x230 [radeon] [] radeon_cs_ioctl+0x3b1/0x810 [radeon] [] drm_ioctl+0x1df/0x680 [drm] [] radeon_drm_ioctl+0x4c/0x80 [radeon] [] radeon_kms_compat_ioctl+0x14/0x30 [radeon] [] compat_SyS_ioctl+0xf0/0x1250 [] ? compat_SyS_futex+0x84/0x1a0 [] ? __schedule+0x382/0xa00 [] sysenter_dispatch+0x7/0x25 Full dmesg attached. I don't think I have debug symbols here, so no further details at this time. It only happened after quite a while, so it's not easily reproducable. Just putting it here because I haven't seen a report like this. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile variable, so no need to audit all the
read-side access specifically.
- The barriers for the vblank counter seqlock weren't complete: The
read-side was missing the first barrier between the counter read and
the timestamp read, it only had a barrier between the ts and the
counter read. We need both.
- Barriers weren't properly documented. Since barriers only work if
you have them on boths sides of the transaction it's prudent to
reference where the other side is. To avoid duplicating the
write-side comment 3 times extract a little store_vblank() helper.
In that helper also assert that we do indeed hold
dev->vblank_time_lock, since in some cases the lock is acquired a
few functions up in the callchain.
Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.
v2: Add comment to better explain how store_vblank works, suggested by
Chris.
v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the
implicit barrier in the spin_unlock. But that can only be proven by
auditing all callers and my point in extracting this little helper was
to localize all the locking into just one place. Hence I think that
additional optimization is too risky.
Cc: Chris Wilson
Cc: Mario Kleiner
Cc: Ville Syrjälä
Cc: Michel Dänzer
Cc: Peter Hurley
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 95 +--
include/drm/drmP.h| 8 +++-
2 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c8a34476570a..8694b77d0002 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -74,6 +74,36 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay, int,
0600);
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
+static void store_vblank(struct drm_device *dev, int crtc,
+unsigned vblank_count_inc,
+struct timeval *t_vblank)
+{
+ struct drm_vblank_crtc *vblank = >vblank[crtc];
+ u32 tslot;
+
+ assert_spin_locked(>vblank_time_lock);
+
+ if (t_vblank) {
+ /* All writers hold the spinlock, but readers are serialized by
+* the latching of vblank->count below.
+*/
+ tslot = vblank->count + vblank_count_inc;
+ vblanktimestamp(dev, crtc, tslot) = *t_vblank;
+ }
+
+ /*
+* vblank timestamp updates are protected on the write side with
+* vblank_time_lock, but on the read side done locklessly using a
+* sequence-lock on the vblank counter. Ensure correct ordering using
+* memory barrriers. We need the barrier both before and also after the
+* counter update to synchronize with the next timestamp write.
+* The read-side barriers for this are in drm_vblank_count_and_time.
+*/
+ smp_wmb();
+ vblank->count += vblank_count_inc;
+ smp_wmb();
+}
+
/**
* drm_update_vblank_count - update the master vblank counter
* @dev: DRM device
@@ -93,7 +123,7 @@ module_param_named(timestamp_monotonic,
drm_timestamp_monotonic, int, 0600);
static void drm_update_vblank_count(struct drm_device *dev, int crtc)
{
struct drm_vblank_crtc *vblank = >vblank[crtc];
- u32 cur_vblank, diff, tslot;
+ u32 cur_vblank, diff;
bool rc;
struct timeval t_vblank;
@@ -129,18 +159,12 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
if (diff == 0)
return;
- /* Reinitialize corresponding vblank timestamp if high-precision query
-* available. Skip this step if query unsupported or failed. Will
-* reinitialize delayed at next vblank interrupt in that case.
+ /*
+* Only reinitialize corresponding vblank timestamp if high-precision
query
+* available and didn't fail. Will reinitialize delayed at next vblank
+* interrupt in that case.
*/
- if (rc) {
- tslot = atomic_read(>count) + diff;
- vblanktimestamp(dev, crtc, tslot) = t_vblank;
- }
-
- smp_mb__before_atomic();
- atomic_add(diff, >count);
- smp_mb__after_atomic();
+ store_vblank(dev, crtc, diff, rc ? _vblank : NULL);
}
/*
@@ -218,7 +242,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
*/
-
[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
> Hi Daniel,
>
> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
> > This was a bit too much cargo-culted, so lets make it solid:
> > - vblank->count doesn't need to be an atomic, writes are always done
> > under the protection of dev->vblank_time_lock. Switch to an unsigned
> > long instead and update comments. Note that atomic_read is just a
> > normal read of a volatile variable, so no need to audit all the
> > read-side access specifically.
> >
> > - The barriers for the vblank counter seqlock weren't complete: The
> > read-side was missing the first barrier between the counter read and
> > the timestamp read, it only had a barrier between the ts and the
> > counter read. We need both.
> >
> > - Barriers weren't properly documented. Since barriers only work if
> > you have them on boths sides of the transaction it's prudent to
> > reference where the other side is. To avoid duplicating the
> > write-side comment 3 times extract a little store_vblank() helper.
> > In that helper also assert that we do indeed hold
> > dev->vblank_time_lock, since in some cases the lock is acquired a
> > few functions up in the callchain.
> >
> > Spotted while reviewing a patch from Chris Wilson to add a fastpath to
> > the vblank_wait ioctl.
> >
> > Cc: Chris Wilson
> > Cc: Mario Kleiner
> > Cc: Ville Syrjälä
> > Cc: Michel Dänzer
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_irq.c | 92
> > ---
> > include/drm/drmP.h| 8 +++--
> > 2 files changed, 54 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index c8a34476570a..23bfbc61a494 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay,
> > int, 0600);
> > module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
> > 0600);
> > module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int,
> > 0600);
> >
> > +static void store_vblank(struct drm_device *dev, int crtc,
> > +unsigned vblank_count_inc,
> > +struct timeval *t_vblank)
> > +{
> > + struct drm_vblank_crtc *vblank = >vblank[crtc];
> > + u32 tslot;
> > +
> > + assert_spin_locked(>vblank_time_lock);
> > +
> > + if (t_vblank) {
> > + tslot = vblank->count + vblank_count_inc;
> > + vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> > + }
> > +
> > + /*
> > +* vblank timestamp updates are protected on the write side with
> > +* vblank_time_lock, but on the read side done locklessly using a
> > +* sequence-lock on the vblank counter. Ensure correct ordering using
> > +* memory barrriers. We need the barrier both before and also after the
> > +* counter update to synchronize with the next timestamp write.
> > +* The read-side barriers for this are in drm_vblank_count_and_time.
> > +*/
> > + smp_wmb();
> > + vblank->count += vblank_count_inc;
> > + smp_wmb();
>
> The comment and the code are each self-contradictory.
>
> If vblank->count writes are always protected by vblank_time_lock (something I
> did not verify but that the comment above asserts), then the trailing write
> barrier is not required (and the assertion that it is in the comment is
> incorrect).
>
> A spin unlock operation is always a write barrier.
Hm yeah. Otoh to me that's bordering on "code too clever for my own good".
That the spinlock is held I can assure. That no one goes around and does
multiple vblank updates (because somehow that code raced with the hw
itself) I can't easily assure with a simple assert or something similar.
It's not the case right now, but that can changes.
Also it's not contradictory here, since you'd need to audit all the
callers to be able to make the claim that the 2nd smp_wmb() is redundant.
I'll just add a comment about this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On Wed, Apr 15, 2015 at 07:34:43PM +0200, Daniel Vetter wrote: > This was a bit too much cargo-culted, so lets make it solid: > - vblank->count doesn't need to be an atomic, writes are always done > under the protection of dev->vblank_time_lock. Switch to an unsigned > long instead and update comments. Note that atomic_read is just a > normal read of a volatile variable, so no need to audit all the > read-side access specifically. > > - The barriers for the vblank counter seqlock weren't complete: The > read-side was missing the first barrier between the counter read and > the timestamp read, it only had a barrier between the ts and the > counter read. We need both. > > - Barriers weren't properly documented. Since barriers only work if > you have them on boths sides of the transaction it's prudent to > reference where the other side is. To avoid duplicating the > write-side comment 3 times extract a little store_vblank() helper. > In that helper also assert that we do indeed hold > dev->vblank_time_lock, since in some cases the lock is acquired a > few functions up in the callchain. > > Spotted while reviewing a patch from Chris Wilson to add a fastpath to > the vblank_wait ioctl. > > v2: Add comment to better explain how store_vblank works, suggested by > Chris. > > v3: Peter noticed that as-is the 2nd smp_wmb is redundant with the > implicit barrier in the spin_unlock. But that can only be proven by > auditing all callers and my point in extracting this little helper was > to localize all the locking into just one place. Hence I think that > additional optimization is too risky. > > Cc: Chris Wilson > Cc: Mario Kleiner > Cc: Ville Syrjälä > Cc: Michel Dänzer > Cc: Peter Hurley > Signed-off-by: Daniel Vetter Fwiw, there was no discernible difference in the time to query the vblank counter (on an ivb i7-3720QM). Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH v4 3/7] drm/tilcdc: Add support for external tda998x encoder
On 04/02/15 01:20, Russell King - ARM Linux wrote: > This is where the DRM model is weak - we don't really have a way to > say "this is the set of CRTCs which/can/ be associated with this > connector, can any of the CRTCs accept this mode?" and eliminate > modes which fail that check. > > This problem seems to be one which recurrs, so I wonder if it's > something which ought to be solved properly. > > It's made slightly more difficult because we don't really know which > connectors could be associated with which CRTCs - that information is > stored at the encoder level (with the encoders possible_crtcs), and > I'm not sure we have a way for generic DRM code to know which encoders > could be associated with which connectors. I agree that this is not the most elegant solution to the problem, but it works with Beaglebone-Black - which is AFAIK the only piece of HW that uses tda998x with tilcdc. I would like to get these patches merged and revisit the mode validation code once we have a better solution for it. Best regards, Jyri
Help on drmModeSetPlane
On Wed, Apr 15, 2015 at 02:24:14PM +, Xie, William wrote: > Oh, I tried it on BDW. > So we need to use other way to scale the video to full screen? Yes, unfortunately. > > William > > > -Original Message- > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com] > Sent: Wednesday, April 15, 2015 7:23 PM > To: Xie, William > Cc: DRI Development > Subject: Re: Help on drmModeSetPlane > > On Wed, Apr 15, 2015 at 08:49:39AM +, Xie, William wrote: > > To make it more specific, > > > > For example: > > 1: video frame size is 1280x720, > > 2: screen resolution is 3200x1800, > > > > How can I set crtc and src parameters? > > > > 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) > > 2: crtc (0, 0, 3200, 1800) src (0, 0, 1280<<16, 720<<16) > > > > Which one is correct? > > 2 is correct. > > What hardware are you trying this on? Do note that on HSW/BDW/VLV/CHV the > hardware lost the plane scaling ability. It's coming back on SKL. > > > > > William > > > > From: Xie, William > > Sent: Wednesday, April 15, 2015 3:55 PM > > To: DRI Development; DRI Development > > Subject: Help on drmModeSetPlane > > > > Question please, could someone share the meaning of the parameters for > > drmModeSetPlane in libdrm? > > > > int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, > > uint32_t fb_id, uint32_t flags, > > int32_t crtc_x, int32_t crtc_y, > > uint32_t crtc_w, uint32_t crtc_h, > > uint32_t src_x, uint32_t src_y, > > uint32_t src_w, uint32_t src_h) > > > > > > My problem is, whatever value I set, the video is not full screen > > mode, Anything I missed? > > > > Thanks > > William > > > > > > > > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- > Ville Syrjälä > Intel OTC -- Ville Syrjälä Intel OTC
[Bug 83274] XCom Enemy Unknown segfault at src/gallium/drivers/radeon/r600_texture.c:602
https://bugs.freedesktop.org/show_bug.cgi?id=83274 --- Comment #5 from nicolas --- I tried to modify the launch script xcom.sh like this : if [ -e "$GAMESCRIPT" ]; then # Launch the game echo "XCOM - Launching" valgrind --log-file=valgrindxcom.log "$GAMESCRIPT" $@ else The game launch and valgrind makes the log file but i'm not sure that valgrind works during execution of the game. here is the output of valgrind, that doesn't seems to help : ==5476== Memcheck, a memory error detector ==5476== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==5476== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info ==5476== Command: /home/nicolas/.steam/steam/SteamApps/common/XCom-Enemy-Unknown/binaries/linux/xcom.sh -arch=x86_64 ==5476== Parent PID: 5470 ==5476== ==5477== ==5477== HEAP SUMMARY: ==5477== in use at exit: 736,194 bytes in 27 blocks ==5477== total heap usage: 40 allocs, 13 frees, 998,962 bytes allocated ==5477== ==5477== LEAK SUMMARY: ==5477==definitely lost: 0 bytes in 0 blocks ==5477==indirectly lost: 0 bytes in 0 blocks ==5477== possibly lost: 0 bytes in 0 blocks ==5477==still reachable: 736,194 bytes in 27 blocks ==5477== suppressed: 0 bytes in 0 blocks ==5477== Rerun with --leak-check=full to see details of leaked memory ==5477== ==5477== For counts of detected and suppressed errors, rerun with: -v ==5477== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==5476== ==5476== HEAP SUMMARY: ==5476== in use at exit: 32 bytes in 1 blocks ==5476== total heap usage: 40 allocs, 39 frees, 998,962 bytes allocated ==5476== ==5476== LEAK SUMMARY: ==5476==definitely lost: 0 bytes in 0 blocks ==5476==indirectly lost: 0 bytes in 0 blocks ==5476== possibly lost: 0 bytes in 0 blocks ==5476==still reachable: 32 bytes in 1 blocks ==5476== suppressed: 0 bytes in 0 blocks ==5476== Rerun with --leak-check=full to see details of leaked memory ==5476== ==5476== For counts of detected and suppressed errors, rerun with: -v ==5476== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/f95d1a84/attachment.html>
[Intel-gfx] [PATCH 05/12] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
2015-04-15 14:15 GMT-03:00 Todd Previte :
> Displayport compliance test 4.2.2.6 requires that a source device be capable
> of
> detecting a corrupt EDID. The test specification states that the sink device
> sets up the EDID with an invalid checksum. To do this, the sink sets up an
> invalid EDID header, expecting the source device to generate the checksum and
> compare it to the value stored in the last byte of the block data.
>
> Unfortunately, the DRM EDID reading and parsing functions are actually too
> good
> in this case; the header is fixed before the checksum is computed and thus the
> code never sees the invalid checksum. This results in a failure to pass the
> compliance test.
>
> To correct this issue, a checksum is generated when the EDID header is
> detected
> as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
> logs the errors. In the case of a more seriously damaged header (fixup score
> less than the threshold) the code does not generate the checksum but does set
> the header_corrupt flag.
>
> V2:
> - Removed the static bool global
> - Added a bool to the drm_connector struct to reaplce the static one for
> holding the status of raw edid header corruption detection
> - Modified the function signature of the is_valid function to take an
> additional parameter to store the corruption detected value
> - Fixed the other callers of the above is_valid function
> V3:
> - Updated the commit message to be more clear about what and why this
> patch does what it does.
> - Added comment in code to clarify the operations there
> - Removed compliance variable and check_link_status update; those
> have been moved to a later patch
> - Removed variable assignment from the bottom of the test handler
> V4:
> - Removed i915 tag from subject line as the patch is not i915-specific
> V5:
> - Moved code causing a compilation error to this patch where the variable
> is actually declared
> - Maintained blank lines / spacing so as to not contaminate the patch
> V6:
> - Removed extra debug messages
> - Added documentation to for the added parameter on drm_edid_block_valid
> - Fixed more whitespace issues in check_link_status
> - Added a clear of the header_corrupt flag to the end of the test handler
> in intel_dp.c
> - Changed the usage of the new function prototype in several places to use
> NULL where it is not needed by compliance testing
> V7:
> - Updated to account for long_pulse flag propagation
>
> Signed-off-by: Todd Previte
> Cc: dri-devel at lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_edid.c | 30 ++
> drivers/gpu/drm/drm_edid_load.c | 7 +--
> drivers/gpu/drm/i915/intel_dp.c | 6 +-
> include/drm/drm_crtc.h | 8 +++-
> 4 files changed, 43 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 53bc7a6..1ed18f5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
> length)
> * @raw_edid: pointer to raw EDID block
> * @block: type of block to validate (0 for base, extension otherwise)
> * @print_bad_edid: if true, dump bad EDID blocks to the console
> + * @header_corrupt: if true, the header or checksum is invalid
> *
> * Validate a base or extension EDID block and optionally dump bad blocks to
> * the console.
> *
> * Return: True if the block is valid, false otherwise.
> */
> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
> + bool *header_corrupt)
> {
> u8 csum;
> struct edid *edid = (struct edid *)raw_edid;
> @@ -1062,9 +1064,25 @@ bool drm_edid_block_valid(u8 *raw_edid, int block,
> bool print_bad_edid)
> int score = drm_edid_header_is_valid(raw_edid);
> if (score == 8) ;
> else if (score >= edid_fixup) {
> + /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
> +* In order to properly generate the invalid checksum
> +* required for this test, it must be generated using
> +* the raw EDID data. Otherwise, the fix-up code here
> +* will correct the problem, the checksum is correct
> +* and the test fails
> +*/
> + csum = drm_edid_block_checksum(raw_edid);
> + if (csum) {
> + if (header_corrupt)
> + *header_corrupt = 1;
> + }
> DRM_DEBUG("Fixing EDID header, your hardware may be
> failing\n");
> memcpy(raw_edid, edid_header, sizeof(edid_header));
> } else {
> +
[RFC 6/6] drm/exynos: mixer: add more pixel formats
The mixer natively support RGB565, ARGB and ARGB1555
so expose these formats. Also, since being of 16-bit size,
these formats have a lower bandwidth requirement, making
them useful in situations where this is a bottleneck.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 512f7b3..7dec7c7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -127,6 +127,11 @@ static const u8 filter_cr_horiz_tap4[] = {
static const uint32_t mixer_formats[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB1555,
+ DRM_FORMAT_ARGB1555,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
};
static const uint32_t vp_formats[] = {
@@ -556,30 +561,32 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
unsigned int x_ratio = 0, y_ratio = 0;
unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
dma_addr_t dma_addr;
- unsigned int fmt, blend;
+ unsigned int fmt, blend = 0;
u32 val;
plane = >planes[win];
switch (plane->pixel_format) {
case DRM_FORMAT_ARGB:
- fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
+ case DRM_FORMAT_XRGB:
+ fmt = MIXER_PIXELFORMAT_ARGB;
break;
case DRM_FORMAT_ARGB:
- fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
- break;
-
case DRM_FORMAT_XRGB:
fmt = MIXER_PIXELFORMAT_ARGB;
- blend = 0;
+ break;
+
+ case DRM_FORMAT_ARGB1555:
+ blend = 1;
+ case DRM_FORMAT_XRGB1555:
+ fmt = MIXER_PIXELFORMAT_ARGB1555;
break;
case DRM_FORMAT_RGB565:
fmt = MIXER_PIXELFORMAT_RGB565;
- blend = 0;
break;
default:
--
2.0.5
[RFC 5/6] drm/exynos: mixer: use more general check for VP format
The mixer itself can't handle 'video' formats like NV12 or
NV21. It needs the VP (video processor) for this task.
With the previous patch we ensure that DRM planes with
a NV12 format can only be created when this setup is
supported. Hence the check now reduces to checking the
pixel format (currently only NV12).
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 50df981..512f7b3 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -133,6 +133,16 @@ static const uint32_t vp_formats[] = {
DRM_FORMAT_NV12,
};
+static inline bool is_vp_format(const struct mixer_context *ctx, unsigned int
win)
+{
+ switch (ctx->planes[win].pixel_format) {
+ case DRM_FORMAT_NV12:
+ return true;
+ default:
+ return false;
+ }
+}
+
static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
{
return readl(res->vp_regs + reg_id);
@@ -970,7 +980,7 @@ static void mixer_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
}
mutex_unlock(_ctx->mixer_mutex);
- if (win > 1 && mixer_ctx->vp_enabled)
+ if (is_vp_format(mixer_ctx, win))
vp_video_buffer(mixer_ctx, win);
else
mixer_graph_buffer(mixer_ctx, win);
--
2.0.5
[RFC 4/6] drm/exynos: remove global pixel format list
Currently the pixel formats that are supported by a plane
object are hard-coded to three entries.
This is not correct since depending on the particular
hardware block (DECON7, FIMD, VP, etc.) the supported
formats are different.
Let each block specify its own list of formats.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 7 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 ++
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 +++
drivers/gpu/drm/exynos/exynos_mixer.c | 18 ++
5 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ca70599..73788a1 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -42,6 +42,11 @@
#define WINDOWS_NR 2
+static const uint32_t decon_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
struct decon_context {
struct device *dev;
struct drm_device *drm_dev;
@@ -767,6 +772,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
}
plane_config.possible_crtcs = 1 << ctx->pipe;
+ plane_config.pixel_formats = decon_formats;
+ plane_config.num_pixel_formats = ARRAY_SIZE(decon_formats);
for (i = 0; i < WINDOWS_NR; i++) {
plane_config.type = (i == ctx->default_win) ?
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 93fbaa5..1db8db7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -144,6 +144,11 @@ static struct fimd_driver_data exynos5_fimd_driver_data = {
.has_vtsel = 1,
};
+static const uint32_t fimd_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
struct fimd_context {
struct device *dev;
struct drm_device *drm_dev;
@@ -1005,6 +1010,8 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
ctx->pipe = priv->pipe++;
plane_config.possible_crtcs = 1 << ctx->pipe;
+ plane_config.pixel_formats = fimd_formats;
+ plane_config.num_pixel_formats = ARRAY_SIZE(fimd_formats);
for (i = 0; i < WINDOWS_NR; i++) {
plane_config.type = (i == ctx->default_win) ?
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d24b32a..563d471 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -19,12 +19,6 @@
#include "exynos_drm_gem.h"
#include "exynos_drm_plane.h"
-static const uint32_t formats[] = {
- DRM_FORMAT_XRGB,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_NV12,
-};
-
/*
* This function is to get X or Y size shown via screen. This needs length and
* start position of CRTC.
@@ -212,8 +206,8 @@ int exynos_plane_init(struct drm_device *dev,
err = drm_universal_plane_init(dev, _plane->base,
config->possible_crtcs,
- _plane_funcs, formats,
- ARRAY_SIZE(formats), config->type);
+ _plane_funcs,
config->pixel_formats,
+ config->num_pixel_formats, config->type);
if (err) {
DRM_ERROR("failed to initialize plane\n");
return err;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index ca7cc8a..94d2e84 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -33,6 +33,11 @@
#define ctx_from_connector(c) container_of(c, struct vidi_context, \
connector)
+static const uint32_t vidi_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
struct vidi_context {
struct exynos_drm_display display;
struct platform_device *pdev;
@@ -470,6 +475,8 @@ static int vidi_bind(struct device *dev, struct device
*master, void *data)
vidi_ctx_initialize(ctx, drm_dev);
plane_config.possible_crtcs = 1 << ctx->pipe;
+ plane_config.pixel_formats = vidi_formats;
+ plane_config.num_pixel_formats = ARRAY_SIZE(vidi_formats);
for (i = 0; i < WINDOWS_NR; i++) {
plane_config.type = (i == ctx->default_win) ?
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 207d5c9..50df981 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -43,6 +43,7 @@
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN 0
+#define MIXER_VP_WIN
[RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
This struct encapsulates the configuration for a plane
object. The pixel format config is currently unused.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
7 files changed, 67 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 84a3638..ca70599 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
struct decon_context *ctx = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
- unsigned int zpos;
+ struct exynos_drm_plane_config plane_config = { 0 };
+ unsigned int i;
int ret;
ret = decon_ctx_initialize(ctx, drm_dev);
@@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct device
*master, void *data)
return ret;
}
- for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
- type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
- ret = exynos_plane_init(drm_dev, >planes[zpos],
- 1 << ctx->pipe, type, zpos);
+ plane_config.possible_crtcs = 1 << ctx->pipe;
+
+ for (i = 0; i < WINDOWS_NR; i++) {
+ plane_config.type = (i == ctx->default_win) ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ plane_config.zpos = i;
+
+ ret = exynos_plane_init(drm_dev, >planes[i],
_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 4c14a89..35698f3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -116,6 +116,25 @@ struct exynos_drm_plane {
};
/*
+ * Exynos DRM plane configuration structure.
+ *
+ * @possible_crtcs: bitfield describing the valid CRTCs
+ * for this plane.
+ * @type: plane type (primary, overlay, etc.)
+ * @zpos: z-position of the plane.
+ * @pixel_formats: supported pixel formats.
+ * @num_pixel_formats: number of elements in 'pixel_formats'.
+ */
+
+struct exynos_drm_plane_config {
+ unsigned long possible_crtcs;
+ enum drm_plane_type type;
+ unsigned int zpos;
+ const uint32_t *pixel_formats;
+ unsigned int num_pixel_formats;
+};
+
+/*
* Exynos DRM Display Structure.
* - this structure is common to analog tv, digital tv and lcd panel.
*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 589579f..93fbaa5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -997,18 +997,21 @@ static int fimd_bind(struct device *dev, struct device
*master, void *data)
struct drm_device *drm_dev = data;
struct exynos_drm_private *priv = drm_dev->dev_private;
struct exynos_drm_plane *exynos_plane;
- enum drm_plane_type type;
- unsigned int zpos;
+ struct exynos_drm_plane_config plane_config = { 0 };
+ unsigned int i;
int ret;
ctx->drm_dev = drm_dev;
ctx->pipe = priv->pipe++;
- for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
- type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
- DRM_PLANE_TYPE_OVERLAY;
- ret = exynos_plane_init(drm_dev, >planes[zpos],
- 1 << ctx->pipe, type, zpos);
+ plane_config.possible_crtcs = 1 << ctx->pipe;
+
+ for (i = 0; i < WINDOWS_NR; i++) {
+ plane_config.type = (i == ctx->default_win) ?
+ DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
+ plane_config.zpos = i;
+
+ ret = exynos_plane_init(drm_dev, >planes[i],
_config);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 043a6ba..d24b32a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -206,23 +206,23 @@ static void exynos_plane_attach_zpos_property(struct
drm_plane *plane,
int exynos_plane_init(struct
[RFC 2/6] drm/exynos: remove used 'activated' field from exynos_drm_plane
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6a849cf..4c14a89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -77,7 +77,6 @@ extern void exynos4412_qos(u8 tm, u8 ac);
* @color_key: color key on or off.
* @local_path: in case of lcd type, local path mode on or off.
* @transparency: transparency on or off.
- * @activated: activated or not.
* @enabled: enabled or not.
* @resume: to resume or not.
*
@@ -112,7 +111,6 @@ struct exynos_drm_plane {
bool color_key:1;
bool local_path:1;
bool transparency:1;
- bool activated:1;
bool enabled:1;
bool resume:1;
};
--
2.0.5
[RFC 1/6] drm/exynos: mixer: move pixelformat defines
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Also add handling of RGB565 and exit if the pixelformat is not
supported.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 3e07f04..9c398d5 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -44,6 +44,11 @@
#define MIXER_WIN_NR 3
#define MIXER_DEFAULT_WIN 0
+#define MIXER_PIXELFORMAT_RGB565 4
+#define MIXER_PIXELFORMAT_ARGB1555 5
+#define MIXER_PIXELFORMAT_ARGB 6
+#define MIXER_PIXELFORMAT_ARGB 7
+
struct mixer_resources {
int irq;
void __iomem*mixer_regs;
@@ -536,31 +541,30 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
plane = >planes[win];
- #define RGB565 4
- #define ARGB1555 5
- #define ARGB 6
- #define ARGB 7
-
switch (plane->pixel_format) {
case DRM_FORMAT_ARGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
break;
case DRM_FORMAT_ARGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 1;
break;
case DRM_FORMAT_XRGB:
- fmt = ARGB;
+ fmt = MIXER_PIXELFORMAT_ARGB;
blend = 0;
break;
- default:
- fmt = ARGB;
+ case DRM_FORMAT_RGB565:
+ fmt = MIXER_PIXELFORMAT_RGB565;
blend = 0;
break;
+
+ default:
+ DRM_DEBUG_KMS("pixelformat unsupported by mixer\n");
+ return;
}
/* check if mixer supports requested scaling setup */
--
2.0.5
[RFC] drm/exynos: improve pixel format handling
Hello, this is an attempt to somewhat improve the handling for supported pixel formats in the Exynos DRM. Currently DRM planes are always created with XRGB, ARGB and NV12 as supported formats, even though the formats depend on the 'consumer' (mixer, FIMD, video processor, etc.). This series is based on the remaining patches of this series: http://www.spinics.net/lists/linux-samsung-soc/msg43103.html With best wishes, Tobias
[RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
Hi Tobias,
2015-04-15 Tobias Jakobi :
> Hello Gustavo!
>
> Gustavo Padovan wrote:
> > Hi Tobias,
> >
> > 2015-04-15 Tobias Jakobi :
> >
> >> This struct encapsulates the configuration for a plane
> >> object. The pixel format config is currently unused.
> >>
> >> Signed-off-by: Tobias Jakobi
> >> ---
> >> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
> >> drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
> >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
> >> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
> >> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
> >> drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
> >> 7 files changed, 67 insertions(+), 37 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> >> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> >> index 84a3638..ca70599 100644
> >> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> >> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> >> @@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct
> >> device *master, void *data)
> >>struct decon_context *ctx = dev_get_drvdata(dev);
> >>struct drm_device *drm_dev = data;
> >>struct exynos_drm_plane *exynos_plane;
> >> - enum drm_plane_type type;
> >> - unsigned int zpos;
> >> + struct exynos_drm_plane_config plane_config = { 0 };
> >> + unsigned int i;
> >>int ret;
> >>
> >>ret = decon_ctx_initialize(ctx, drm_dev);
> >> @@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct
> >> device *master, void *data)
> >>return ret;
> >>}
> >>
> >> - for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> >> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> >> - DRM_PLANE_TYPE_OVERLAY;
> >> - ret = exynos_plane_init(drm_dev, >planes[zpos],
> >> - 1 << ctx->pipe, type, zpos);
> >> + plane_config.possible_crtcs = 1 << ctx->pipe;
> >> +
> >> + for (i = 0; i < WINDOWS_NR; i++) {
> >> + plane_config.type = (i == ctx->default_win) ?
> >> + DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
> >> + plane_config.zpos = i;
> >> +
> >> + ret = exynos_plane_init(drm_dev, >planes[i],
> >> _config);
> >>if (ret)
> >>return ret;
> >>}
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> >> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> >> index 4c14a89..35698f3 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> >> @@ -116,6 +116,25 @@ struct exynos_drm_plane {
> >> };
> >>
> >> /*
> >> + * Exynos DRM plane configuration structure.
> >> + *
> >> + * @possible_crtcs: bitfield describing the valid CRTCs
> >> + *for this plane.
> >> + * @type: plane type (primary, overlay, etc.)
> >> + * @zpos: z-position of the plane.
> >> + * @pixel_formats: supported pixel formats.
> >> + * @num_pixel_formats: number of elements in 'pixel_formats'.
> >> + */
> >> +
> >> +struct exynos_drm_plane_config {
> >> + unsigned long possible_crtcs;
> >> + enum drm_plane_type type;
> >> + unsigned int zpos;
> >> + const uint32_t *pixel_formats;
> >> + unsigned int num_pixel_formats;
> >> +};
> >
> > As a follow up of my atomic series I started cleaning up exynos drm a bit
> > more
> > and right now I'm removing most of struct exynos_drm_plane. Most of the
> > plane
> > information there is also present in plane->state thus I'm basically
> > removing
> > all the duplicated information there.
> Sounds like a good plan.
>
>
> > That said, I think we avoid creating exynos_drm_plane_config and stuff
> > everything directly in struct exynos_drm_plane, it will be quite small and
> > easier to manipulate.
> So that would imply that we then just have:
> int exynos_plane_init(struct drm_device *dev, struct exynos_drm_plane
> *exynos_plane);
>
> Correct?
Correct, passing exynos_drm_plane simplifies things a lot for us.
>
> Anyway, I'm going to wait then until the cleanups are posted and rebase
> this series onto it.
Right, I'll probably have that the next week or the other one, I'm currently
working on some testing scripts to speed up my testing and make sure I'm not
breaking anything.
Gustavo
[PATCH 2/2] dt-bindings: Add MSM eDP controller documentation
Signed-off-by: Hai Li
---
Documentation/devicetree/bindings/drm/msm/edp.txt | 61 +++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/msm/edp.txt
diff --git a/Documentation/devicetree/bindings/drm/msm/edp.txt
b/Documentation/devicetree/bindings/drm/msm/edp.txt
new file mode 100644
index 000..6e633aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/edp.txt
@@ -0,0 +1,61 @@
+Qualcomm Technologies Inc. adreno/snapdragon eDP output
+
+Required properties:
+- compatible:
+ * "qcom,mdss-edp"
+- reg: Physical base address and length of the registers of controller and PLL
+- reg-names: The names of register regions. The following regions are required:
+ * "edp"
+ * "pll_base"
+- interrupts: The interrupt signal from the eDP block.
+- power-domains: Should be < MDSS_GDSC>.
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
+- clock-names: the following clocks are required:
+ * "core_clk"
+ * "iface_clk"
+ * "mdp_core_clk"
+ * "pixel_clk"
+ * "link_clk"
+- #clock-cells: The value should be 1.
+- vdda-supply: phandle to vdda regulator device node
+- lvl-vdd-supply: phandle to regulator device node which is used to supply
power
+ to HPD receiving chip
+- panel-en-gpios: GPIO pin to supply power to panel.
+- panel-hpd-gpios: GPIO pin used for eDP hpd.
+
+
+Optional properties:
+- interrupt-parent: phandle to the MDP block if the interrupt signal is routed
+ through MDP block
+
+Example:
+ mdss_edp: qcom,mdss_edp at fd923400 {
+ compatible = "qcom,mdss-edp";
+ reg-names =
+ "edp",
+ "pll_base";
+ reg = <0xfd923400 0x700>,
+ <0xfd923a00 0xd4>;
+ interrupt-parent = <_mdp>;
+ interrupts = <12 0>;
+ power-domains = < MDSS_GDSC>;
+ clock-names =
+ "core_clk",
+ "pixel_clk",
+ "iface_clk",
+ "link_clk",
+ "mdp_core_clk";
+ clocks =
+ < MDSS_EDPAUX_CLK>,
+ < MDSS_EDPPIXEL_CLK>,
+ < MDSS_AHB_CLK>,
+ < MDSS_EDPLINK_CLK>,
+ < MDSS_MDP_CLK>;
+ #clock-cells = <1>;
+ vdda-supply = <_l12>;
+ lvl-vdd-supply = <_vreg>;
+ panel-en-gpios = < 137 0>;
+ panel-hpd-gpios = < 103 0>;
+ };
+
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH 1/2] dt-bindings: Add MSM DSI controller documentation
Signed-off-by: Hai Li
---
Documentation/devicetree/bindings/drm/msm/dsi.txt | 97 +++
1 file changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/msm/dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
new file mode 100644
index 000..b3cf325
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -0,0 +1,97 @@
+Qualcomm Technologies Inc. adreno/snapdragon DSI output
+
+Required properties:
+- compatible:
+ * "qcom,mdss-dsi-ctrl"
+- reg: Physical base address and length of the registers of controller, PLL,
+ PHY and PHY regulator
+- reg-names: The names of register regions. The following regions are required:
+ * "dsi_ctrl"
+ * "dsi_pll"
+ * "dsi_phy"
+ * "dsi_phy_regulator"
+- qcom,dsi-host-index: The ID of DSI controller hardware instance. This should
+ be 0 or 1, since we have 2 DSI controllers at most for now.
+- interrupts: The interrupt signal from the DSI block.
+- power-domains: Should be < MDSS_GDSC>.
+- clocks: device clocks
+ See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
+- clock-names: the following clocks are required:
+ * "bus_clk"
+ * "byte_clk"
+ * "core_clk"
+ * "core_mmss_clk"
+ * "iface_clk"
+ * "mdp_core_clk"
+ * "pixel_clk"
+- #clock-cells: The value should be 1.
+- vdd-supply: phandle to vdd regulator device node
+- vddio-supply: phandle to vdd-io regulator device node
+- vdda-supply: phandle to vdda regulator device node
+
+Optional properties:
+- panel at 0: Node of panel connected to this DSI controller.
+ See files in Documentation/devicetree/bindings/panel/ for each supported
+ panel.
+- qcom,dual-panel-mode: Boolean value indicating if the DSI controller is
+ driving a panel which needs 2 DSI links.
+- qcom,master-panel: Boolean value indicating if the DSI controller is driving
+ the master link of the 2-DSI panel.
+- qcom,sync-dual-panel: Boolean value indicating if the DSI controller is
+ driving a 2-DSI panel whose 2 links need receive command simultaneously.
+- interrupt-parent: phandle to the MDP block if the interrupt signal is routed
+ through MDP block
+
+Example:
+ mdss_dsi0: qcom,mdss_dsi at fd922800 {
+ compatible = "qcom,mdss-dsi-ctrl";
+ qcom,dsi-host-index = <0>;
+ interrupt-parent = <_mdp>;
+ interrupts = <4 0>;
+ reg-names =
+ "dsi_ctrl",
+ "dsi_pll",
+ "dsi_phy",
+ "dsi_phy_regulator",
+ reg = <0xfd922800 0x200>,
+ <0xfd922a00 0xd4>,
+ <0xfd922b00 0x2b0>,
+ <0xfd922d80 0x7b>,
+ <0xfd828000 0x108>;
+ power-domains = < MDSS_GDSC>;
+ clock-names =
+ "bus_clk",
+ "byte_clk",
+ "core_clk",
+ "core_mmss_clk",
+ "iface_clk",
+ "mdp_core_clk",
+ "pixel_clk";
+ clocks =
+ < MDSS_AXI_CLK>,
+ < MDSS_BYTE0_CLK>,
+ < MDSS_ESC0_CLK>,
+ < MMSS_MISC_AHB_CLK>,
+ < MDSS_AHB_CLK>,
+ < MDSS_MDP_CLK>,
+ < MDSS_PCLK0_CLK>;
+ #clock-cells = <1>;
+ vdda-supply = <_l2>;
+ vdd-supply = <_l22>;
+ vddio-supply = <_l12>;
+
+ qcom,dual-panel-mode;
+ qcom,master-panel;
+ qcom,sync-dual-panel;
+
+ panel: panel at 0 {
+ compatible = "sharp,lq101r1sx01";
+ reg = <0>;
+ link2 = <>;
+
+ power-supply = <...>;
+ backlight = <...>;
+ };
+ };
+
+
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[RFC 3/6] drm/exynos: introduce struct exynos_drm_plane_config
Hi Tobias,
2015-04-15 Tobias Jakobi :
> This struct encapsulates the configuration for a plane
> object. The pixel format config is currently unused.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
> drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 ++---
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 14 +++---
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 3 +--
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 17 ++---
> drivers/gpu/drm/exynos/exynos_mixer.c | 17 ++---
> 7 files changed, 67 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 84a3638..ca70599 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -756,8 +756,8 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> struct decon_context *ctx = dev_get_drvdata(dev);
> struct drm_device *drm_dev = data;
> struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
> - unsigned int zpos;
> + struct exynos_drm_plane_config plane_config = { 0 };
> + unsigned int i;
> int ret;
>
> ret = decon_ctx_initialize(ctx, drm_dev);
> @@ -766,11 +766,14 @@ static int decon_bind(struct device *dev, struct device
> *master, void *data)
> return ret;
> }
>
> - for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = (zpos == ctx->default_win) ? DRM_PLANE_TYPE_PRIMARY :
> - DRM_PLANE_TYPE_OVERLAY;
> - ret = exynos_plane_init(drm_dev, >planes[zpos],
> - 1 << ctx->pipe, type, zpos);
> + plane_config.possible_crtcs = 1 << ctx->pipe;
> +
> + for (i = 0; i < WINDOWS_NR; i++) {
> + plane_config.type = (i == ctx->default_win) ?
> + DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
> + plane_config.zpos = i;
> +
> + ret = exynos_plane_init(drm_dev, >planes[i],
> _config);
> if (ret)
> return ret;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 4c14a89..35698f3 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -116,6 +116,25 @@ struct exynos_drm_plane {
> };
>
> /*
> + * Exynos DRM plane configuration structure.
> + *
> + * @possible_crtcs: bitfield describing the valid CRTCs
> + * for this plane.
> + * @type: plane type (primary, overlay, etc.)
> + * @zpos: z-position of the plane.
> + * @pixel_formats: supported pixel formats.
> + * @num_pixel_formats: number of elements in 'pixel_formats'.
> + */
> +
> +struct exynos_drm_plane_config {
> + unsigned long possible_crtcs;
> + enum drm_plane_type type;
> + unsigned int zpos;
> + const uint32_t *pixel_formats;
> + unsigned int num_pixel_formats;
> +};
As a follow up of my atomic series I started cleaning up exynos drm a bit more
and right now I'm removing most of struct exynos_drm_plane. Most of the plane
information there is also present in plane->state thus I'm basically removing
all the duplicated information there.
That said, I think we avoid creating exynos_drm_plane_config and stuff
everything directly in struct exynos_drm_plane, it will be quite small and
easier to manipulate.
Gustavo
[PATCH 2/3] drm: Prevent invalid use of vblank_disable_immediate.
On 15.04.2015 02:41, Mario Kleiner wrote:
> For a kms driver to support immediate disable of vblank
> irq's reliably without introducing off by one errors or
> other mayhem for clients, it must not only support a
> hardware vblank counter query, but also high precision
> vblank timestamping, so vblank count and timestamp can be
> instantaneously reinitialzed to valid values. Additionally
> the exposed hardware counter must behave as if it is
> incrementing at leading edge of vblank to avoid off by
> one errors during reinitialization of the counter while
> the display happens to be inside or close to vblank.
>
> Check during drm_vblank_init that a driver which claims to
> be capable of vblank_disable_immediate at least supports
> high precision timestamping and prevent use of instant
> disable if that isn't present as a minimum requirement.
>
> Signed-off-by: Mario Kleiner
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
> Cc: Thierry Reding
> Cc: Dave Airlie
> ---
> drivers/gpu/drm/drm_irq.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index af9662e..6efe822 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -336,6 +336,12 @@ int drm_vblank_init(struct drm_device *dev, int
> num_crtcs)
> else
> DRM_INFO("No driver support for vblank timestamp query.\n");
>
> + /* Must have precise timestamping for reliable vblank instant disable */
> + if (dev->vblank_disable_immediate &&
> !dev->driver->get_vblank_timestamp) {
> + dev->vblank_disable_immediate = false;
> + DRM_ERROR("Set vblank_disable_immediate, but not supported.\n");
> + }
I think DRM_ERROR is kind of a bad compromise for this. If this is
considered a driver bug, something like WARN_ONCE would be better to
draw attention to the culprit. Otherwise, maybe something like
DRM_INFO("Setting vblank_disable_immediate to false because "
"get_vblank_timestamp == NULL\n");
would be both clearer and less alarming.
Other than that, looks good to me.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
[Bug 90034] account request for amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=90034 Alex Deucher changed: What|Removed |Added Component|DRM/AMDgpu |New Accounts Version|DRI git |unspecified Assignee|dri-devel at lists.freedesktop |sitewranglers at lists.freedes |.org|ktop.org Product|DRI |freedesktop.org -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/9e128c89/attachment.html>
[Bug 90034] account request for amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=90034 --- Comment #2 from Alex Deucher --- I approve this request as well. Jammy, please pick a user name as well. Jammy will need access to: drm-amd xorg/driver/xf86-video-amdgpu mesa/drm -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/68b5efc6/attachment.html>
[PATCH] Documentation/drm: Update rotation property with 90/270 and description
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Sonika Jindal
---
Documentation/DocBook/drm.tmpl |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f4976cd..266d50a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2853,9 +2853,12 @@ void intel_crt_init(struct drm_device *dev)
Plane
ârotationâ
BITMASK
- { 0, "rotate-0" }, { 2, "rotate-180" }
+ { 0, "rotate-0" }, { 1, "rotate-90" },
+ { 2, "rotate-180" }, { 3, "rotate-270" }
Plane
- TBD
+ To set plane HW rotation. This rotation property does
+ the plane rotation in counter clockwise direction which is
+ inline with the way XRandr works.
SDVO-TV
--
1.7.10.4
[RFC 2/6] drm/exynos: remove used 'activated' field from exynos_drm_plane
Hi Tobias, 2015-04-15 Tobias Jakobi : > Signed-off-by: Tobias Jakobi I think you mean "unused" in the commit subject. And would also be good to have some commit message as well. Other than that: Reviewed-by: Gustavo Padovan Gustavo
[RFC 1/6] drm/exynos: mixer: move pixelformat defines
Hi Tobias, 2015-04-15 Tobias Jakobi : > Move the defines for the pixelformats that the mixer supports out > of mixer_graph_buffer() to the top of the source. > Also add handling of RGB565 and exit if the pixelformat is not > supported. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 24 ++-- > 1 file changed, 14 insertions(+), 10 deletions(-) Reviewed-by: Gustavo Padovan Gustavo
[Bug 90040] Using VDPAU in radeon breaks suspend to RAM, and caused BSoD
https://bugs.freedesktop.org/show_bug.cgi?id=90040 Christian König changed: What|Removed |Added Attachment #115086|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/5a455d4f/attachment.html>
[PULL] drm-intel-next-fixes
Hi Dave - As promised, here's a batch of fixes for drm-next/4.1. BR, Jani. The following changes since commit 6e0aa8018f9c676b115b7ca6c20a056fc57c68a9: Merge tag 'v4.0-rc6' into drm-intel-next (2015-03-30 16:37:08 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-04-15 for you to fetch changes up to 37ef01ab5d24d1d520dc79f6a98099d451c2a901: drm/i915: Dont enable CS_PARSER_ERROR interrupts at all (2015-04-14 17:03:12 +0300) Ander Conselvan de Oliveira (1): drm/i915: Allocate connector state together with the connectors Clint Taylor (1): drm/i915/chv: Remove DPIO force latency causing interpair skew issue Daniel Vetter (3): drm/i915: Fix locking in DRRS flush/invalidate hooks drm/i915: Don't cancel DRRS worker synchronously for flush/invalidate drm/i915: Dont enable CS_PARSER_ERROR interrupts at all Tvrtko Ursulin (1): drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover drivers/gpu/drm/i915/i915_irq.c | 8 +--- drivers/gpu/drm/i915/intel_crt.c | 2 +- drivers/gpu/drm/i915/intel_ddi.c | 4 +- drivers/gpu/drm/i915/intel_display.c | 76 +--- drivers/gpu/drm/i915/intel_dp.c | 33 +--- drivers/gpu/drm/i915/intel_dp_mst.c | 2 +- drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 2 +- drivers/gpu/drm/i915/intel_hdmi.c| 7 +--- drivers/gpu/drm/i915/intel_lvds.c| 6 +++ drivers/gpu/drm/i915/intel_sdvo.c| 22 +-- drivers/gpu/drm/i915/intel_tv.c | 2 +- 13 files changed, 91 insertions(+), 77 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
https://bugs.freedesktop.org/show_bug.cgi?id=89971 --- Comment #12 from Adrian Gabor --- Added kernel and gdm-xorg logs as ver2 files. Please ignore kernel log posted in the comments. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/2bb93f98/attachment.html>
[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
https://bugs.freedesktop.org/show_bug.cgi?id=89971 --- Comment #11 from Adrian Gabor --- Created attachment 115089 --> https://bugs.freedesktop.org/attachment.cgi?id=115089=edit xorg log ver2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/c5c6fdcd/attachment.html>
[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
https://bugs.freedesktop.org/show_bug.cgi?id=89971 --- Comment #10 from Adrian Gabor --- Created attachment 115088 --> https://bugs.freedesktop.org/attachment.cgi?id=115088=edit dmesg ver2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/1f6d4ba4/attachment.html>
[PATCH 05/12] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
code never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, a checksum is generated when the EDID header is detected
as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
logs the errors. In the case of a more seriously damaged header (fixup score
less than the threshold) the code does not generate the checksum but does set
the header_corrupt flag.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
- Maintained blank lines / spacing so as to not contaminate the patch
V6:
- Removed extra debug messages
- Added documentation to for the added parameter on drm_edid_block_valid
- Fixed more whitespace issues in check_link_status
- Added a clear of the header_corrupt flag to the end of the test handler
in intel_dp.c
- Changed the usage of the new function prototype in several places to use
NULL where it is not needed by compliance testing
V7:
- Updated to account for long_pulse flag propagation
V8:
- Removed clearing of header_corrupt flag from the test handler in intel_dp.c
- Added clearing of header_corrupt flag in the drm_edid_block_valid function
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 35 +--
drivers/gpu/drm/drm_edid_load.c | 7 +--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
include/drm/drm_crtc.h | 8 +++-
4 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..6d037f9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
* @raw_edid: pointer to raw EDID block
* @block: type of block to validate (0 for base, extension otherwise)
* @print_bad_edid: if true, dump bad EDID blocks to the console
+ * @header_corrupt: if true, the header or checksum is invalid
*
* Validate a base or extension EDID block and optionally dump bad blocks to
* the console.
*
* Return: True if the block is valid, false otherwise.
*/
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *header_corrupt)
{
u8 csum;
struct edid *edid = (struct edid *)raw_edid;
@@ -1060,11 +1062,28 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid)
if (block == 0) {
int score = drm_edid_header_is_valid(raw_edid);
- if (score == 8) ;
- else if (score >= edid_fixup) {
+ if (score == 8) {
+ if (header_corrupt)
+ *header_corrupt = 0;
+ } else if (score >= edid_fixup) {
+ /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
+* In order to properly generate the invalid checksum
+* required for this test, it must be generated using
+* the raw EDID data. Otherwise, the fix-up code here
+* will correct the problem, the checksum is correct
+* and the test fails
+*/
+ csum = drm_edid_block_checksum(raw_edid);
+ if (csum) {
+ if (header_corrupt)
+ *header_corrupt = 1;
+ }
DRM_DEBUG("Fixing EDID header, your hardware may be
failing\n");
[Intel-gfx] [PATCH 05/12] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
On 4/15/2015 1:25 PM, Paulo Zanoni wrote:
> 2015-04-15 14:15 GMT-03:00 Todd Previte :
>> Displayport compliance test 4.2.2.6 requires that a source device be capable
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invalid checksum. To do this, the sink sets up an
>> invalid EDID header, expecting the source device to generate the checksum and
>> compare it to the value stored in the last byte of the block data.
>>
>> Unfortunately, the DRM EDID reading and parsing functions are actually too
>> good
>> in this case; the header is fixed before the checksum is computed and thus
>> the
>> code never sees the invalid checksum. This results in a failure to pass the
>> compliance test.
>>
>> To correct this issue, a checksum is generated when the EDID header is
>> detected
>> as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
>> logs the errors. In the case of a more seriously damaged header (fixup score
>> less than the threshold) the code does not generate the checksum but does set
>> the header_corrupt flag.
>>
>> V2:
>> - Removed the static bool global
>> - Added a bool to the drm_connector struct to reaplce the static one for
>>holding the status of raw edid header corruption detection
>> - Modified the function signature of the is_valid function to take an
>>additional parameter to store the corruption detected value
>> - Fixed the other callers of the above is_valid function
>> V3:
>> - Updated the commit message to be more clear about what and why this
>>patch does what it does.
>> - Added comment in code to clarify the operations there
>> - Removed compliance variable and check_link_status update; those
>>have been moved to a later patch
>> - Removed variable assignment from the bottom of the test handler
>> V4:
>> - Removed i915 tag from subject line as the patch is not i915-specific
>> V5:
>> - Moved code causing a compilation error to this patch where the variable
>>is actually declared
>> - Maintained blank lines / spacing so as to not contaminate the patch
>> V6:
>> - Removed extra debug messages
>> - Added documentation to for the added parameter on drm_edid_block_valid
>> - Fixed more whitespace issues in check_link_status
>> - Added a clear of the header_corrupt flag to the end of the test handler
>>in intel_dp.c
>> - Changed the usage of the new function prototype in several places to use
>>NULL where it is not needed by compliance testing
>> V7:
>> - Updated to account for long_pulse flag propagation
>>
>> Signed-off-by: Todd Previte
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> drivers/gpu/drm/drm_edid.c | 30 ++
>> drivers/gpu/drm/drm_edid_load.c | 7 +--
>> drivers/gpu/drm/i915/intel_dp.c | 6 +-
>> include/drm/drm_crtc.h | 8 +++-
>> 4 files changed, 43 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 53bc7a6..1ed18f5 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
>> length)
>>* @raw_edid: pointer to raw EDID block
>>* @block: type of block to validate (0 for base, extension otherwise)
>>* @print_bad_edid: if true, dump bad EDID blocks to the console
>> + * @header_corrupt: if true, the header or checksum is invalid
>>*
>>* Validate a base or extension EDID block and optionally dump bad blocks
>> to
>>* the console.
>>*
>>* Return: True if the block is valid, false otherwise.
>>*/
>> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
>> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
>> + bool *header_corrupt)
>> {
>> u8 csum;
>> struct edid *edid = (struct edid *)raw_edid;
>> @@ -1062,9 +1064,25 @@ bool drm_edid_block_valid(u8 *raw_edid, int block,
>> bool print_bad_edid)
>> int score = drm_edid_header_is_valid(raw_edid);
>> if (score == 8) ;
>> else if (score >= edid_fixup) {
>> + /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
>> +* In order to properly generate the invalid checksum
>> +* required for this test, it must be generated using
>> +* the raw EDID data. Otherwise, the fix-up code here
>> +* will correct the problem, the checksum is correct
>> +* and the test fails
>> +*/
>> + csum = drm_edid_block_checksum(raw_edid);
>> + if (csum) {
>> + if (header_corrupt)
>> + *header_corrupt = 1;
>> + }
>>
[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
https://bugs.freedesktop.org/show_bug.cgi?id=89971 --- Comment #9 from Adrian Gabor --- Comment on attachment 115000 --> https://bugs.freedesktop.org/attachment.cgi?id=115000 dmesg [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.19.3-3-ARCH (builduser at tobias) (gcc version 4.9.2 20150304 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Apr 8 14:10:00 CEST 2015 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=6a6fd79f-4e8c-49b9-baa9-7082b5525feb rw resume=UUID=3ae621d0-c7a4-4f67-8371-6f6fe25d01c0 quiet [0.00] tseg: 007f80 [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x7dec1fff] usable [0.00] BIOS-e820: [mem 0x7dec2000-0x7e047fff] reserved [0.00] BIOS-e820: [mem 0x7e048000-0x7e062fff] ACPI data [0.00] BIOS-e820: [mem 0x7e063000-0x7e3c9fff] ACPI NVS [0.00] BIOS-e820: [mem 0x7e3ca000-0x7ee80fff] reserved [0.00] BIOS-e820: [mem 0x7ee81000-0x7ee81fff] usable [0.00] BIOS-e820: [mem 0x7ee82000-0x7f084fff] ACPI NVS [0.00] BIOS-e820: [mem 0x7f085000-0x7f46efff] usable [0.00] BIOS-e820: [mem 0x7f46f000-0x7f7e] reserved [0.00] BIOS-e820: [mem 0x7f7f-0x7f7f] usable [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x00014eff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: ASUSTeK COMPUTER INC. X550DP/X550DP, BIOS 206 05/03/2013 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x14f000 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B write-through [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 7F80 mask FF80 uncachable [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00014f00 aka 5360M [0.00] PAT configuration [0-7]: WB WC UC- UC WB WC UC- UC [0.00] e820: update [mem 0x7f80-0x] usable ==> reserved [0.00] e820: last_pfn = 0x7f800 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fd840-0x000fd84f] mapped at [880fd840] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88098000] 98000 size 24576 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x01b32000, 0x01b32fff] PGTABLE [0.00] BRK [0x01b33000, 0x01b33fff] PGTABLE [0.00] BRK [0x01b34000, 0x01b34fff] PGTABLE [0.00] init_memory_mapping: [mem 0x14ee0-0x14eff] [0.00] [mem 0x14ee0-0x14eff] page 2M [0.00] BRK [0x01b35000, 0x01b35fff] PGTABLE [0.00] init_memory_mapping: [mem 0x14000-0x14edf] [0.00] [mem 0x14000-0x14edf] page 2M [0.00] init_memory_mapping: [mem 0x12000-0x13fff] [0.00] [mem 0x12000-0x13fff] page 2M [0.00] BRK [0x01b36000, 0x01b36fff] PGTABLE [0.00] init_memory_mapping: [mem 0x0010-0x7dec1fff] [0.00] [mem 0x0010-0x001f] page 4k [0.00] [mem 0x0020-0x7ddf] page 2M [0.00] [mem 0x7de0-0x7dec1fff] page 4k [0.00] init_memory_mapping: [mem 0x7ee81000-0x7ee81fff] [0.00] [mem 0x7ee81000-0x7ee81fff] page 4k [0.00] BRK [0x01b37000, 0x01b37fff] PGTABLE [0.00] init_memory_mapping: [mem
[Bug 90040] Using VDPAU in radeon breaks suspend to RAM, and caused BSoD
https://bugs.freedesktop.org/show_bug.cgi?id=90040 --- Comment #1 from Marco Trevisan (Treviño) --- Created attachment 115087 --> https://bugs.freedesktop.org/attachment.cgi?id=115087=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/64106d75/attachment.html>
[Bug 90040] Using VDPAU in radeon breaks suspend to RAM, and caused BSoD
https://bugs.freedesktop.org/show_bug.cgi?id=90040 Bug ID: 90040 Summary: Using VDPAU in radeon breaks suspend to RAM, and caused BSoD Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: mail at 3v1n0.net Created attachment 115086 --> https://bugs.freedesktop.org/attachment.cgi?id=115086=edit BSoD: [TTM] radeon failed to fill cached pool (r:-12)! If I use vdpau (both directly and via vdpau-va-driver), after that I watch some videos, my laptop hangs while suspending (and this happens always, after that I opened a certain number of videos). I'm using 3.0 Mesa 10.6.0-devel (10.6.0~git20150318) on kernel 3.16.0-34-generic. My radeon card is: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650] While generally this just leads to a frozen system, with no output, once I got a BSoD (really, on linux!??) as you can see in the attached picture, saying: [TTM] radeon :01:00.0: Failed to fill cached pool (r:-12)! :00:16.0: request_threaded_ir failed: irq = 43 returns -12 me async: error -12 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/d7d0d42c/attachment.html>
Help on drmModeSetPlane
Oh, I tried it on BDW. So we need to use other way to scale the video to full screen? William -Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Wednesday, April 15, 2015 7:23 PM To: Xie, William Cc: DRI Development Subject: Re: Help on drmModeSetPlane On Wed, Apr 15, 2015 at 08:49:39AM +, Xie, William wrote: > To make it more specific, > > For example: > 1: video frame size is 1280x720, > 2: screen resolution is 3200x1800, > > How can I set crtc and src parameters? > > 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) > 2: crtc (0, 0, 3200, 1800) src (0, 0, 1280<<16, 720<<16) > > Which one is correct? 2 is correct. What hardware are you trying this on? Do note that on HSW/BDW/VLV/CHV the hardware lost the plane scaling ability. It's coming back on SKL. > > William > > From: Xie, William > Sent: Wednesday, April 15, 2015 3:55 PM > To: DRI Development; DRI Development > Subject: Help on drmModeSetPlane > > Question please, could someone share the meaning of the parameters for > drmModeSetPlane in libdrm? > > int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, > uint32_t fb_id, uint32_t flags, > int32_t crtc_x, int32_t crtc_y, > uint32_t crtc_w, uint32_t crtc_h, > uint32_t src_x, uint32_t src_y, > uint32_t src_w, uint32_t src_h) > > > My problem is, whatever value I set, the video is not full screen > mode, Anything I missed? > > Thanks > William > > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC
Help on drmModeSetPlane
On Wed, Apr 15, 2015 at 08:49:39AM +, Xie, William wrote: > To make it more specific, > > For example: > 1: video frame size is 1280x720, > 2: screen resolution is 3200x1800, > > How can I set crtc and src parameters? > > 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) > 2: crtc (0, 0, 3200, 1800) src (0, 0, 1280<<16, 720<<16) > > Which one is correct? 2 is correct. What hardware are you trying this on? Do note that on HSW/BDW/VLV/CHV the hardware lost the plane scaling ability. It's coming back on SKL. > > William > > From: Xie, William > Sent: Wednesday, April 15, 2015 3:55 PM > To: DRI Development; DRI Development > Subject: Help on drmModeSetPlane > > Question please, could someone share the meaning of the parameters for > drmModeSetPlane in libdrm? > > int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, > uint32_t fb_id, uint32_t flags, > int32_t crtc_x, int32_t crtc_y, > uint32_t crtc_w, uint32_t crtc_h, > uint32_t src_x, uint32_t src_y, > uint32_t src_w, uint32_t src_h) > > > My problem is, whatever value I set, the video is not full screen mode, > Anything I missed? > > Thanks > William > > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC
[PULL] topic/drm-misc
Hi Dave,
One more drm-misch pull for 4.1 with mostly simple stuff and boring
refactoring. Even the cursor fix from Matt is just to make a really anal
igt happy.
Cheers, Daniel
The following changes since commit 502e95c6678505474f1056480310cd9382bacbac:
drm/vgem: implement virtual GEM (2015-04-02 09:21:48 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-04-15
for you to fetch changes up to 2b1193d5287004edfbf89407149a3159656f47f1:
drm: fix trivial typo mistake (2015-04-14 12:41:03 +0200)
Ander Conselvan de Oliveira (1):
drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros
Jani Nikula (11):
drm/exynos: constify all struct drm_*_helper funcs pointers
drm/mgag200: constify all struct drm_*_helper funcs pointers
drm/gma500: constify all struct drm_*_helper funcs pointers
drm/radeon: constify all struct drm_*_helper funcs pointers
drm/nouveau: constify all struct drm_*_helper funcs pointers
drm/qxl: constify all struct drm_*_helper funcs pointers
drm/drm: constify all struct drm_*_helper funcs pointers
drm/edid: add #defines for ELD versions
drm/radeon: constify more struct drm_*_helper funcs pointers
drm/armada: constify struct drm_encoder_helper_funcs pointer
drm: make crtc/encoder/connector/plane helper_private a const pointer
John Hunter (2):
drm: Fix some typos
drm: fix trivial typo mistake
Maarten Lankhorst (1):
drm: Use kref_put_mutex in drm_gem_object_unreference_unlocked
Matt Roper (1):
drm: Make integer overflow checking cover universal cursor updates (v2)
drivers/gpu/drm/armada/armada_output.h | 2 +-
drivers/gpu/drm/drm_atomic.c| 66 ++-
drivers/gpu/drm/drm_atomic_helper.c | 253 +++-
drivers/gpu/drm/drm_crtc.c | 22 +--
drivers/gpu/drm/drm_crtc_helper.c | 24 +--
drivers/gpu/drm/drm_fb_helper.c | 8 +-
drivers/gpu/drm/drm_plane_helper.c | 4 +-
drivers/gpu/drm/drm_probe_helper.c | 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c| 2 +-
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 2 +-
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +-
drivers/gpu/drm/gma500/gma_display.c| 10 +-
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +-
drivers/gpu/drm/gma500/mdfld_intel_display.c| 2 +-
drivers/gpu/drm/gma500/oaktrail_crtc.c | 2 +-
drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 +-
drivers/gpu/drm/gma500/psb_intel_display.c | 2 +-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +-
drivers/gpu/drm/nouveau/dispnv04/dac.c | 4 +-
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 4 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 6 +-
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 4 +-
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +-
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 20 +-
drivers/gpu/drm/radeon/radeon_dp_mst.c | 2 +-
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +-
include/drm/drm_atomic.h| 24 +++
include/drm/drm_crtc.h | 10 +-
include/drm/drm_crtc_helper.h | 6 +-
include/drm/drm_edid.h | 2 +
include/drm/drm_gem.h | 14 +-
include/drm/drm_plane_helper.h | 2 +-
37 files changed, 213 insertions(+), 314 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/2] drm: Shortcircuit vblank queries
On 14.04.2015 23:21, Chris Wilson wrote: > On Tue, Apr 14, 2015 at 06:42:03PM +0900, Michel Dänzer wrote: >> Also, the two patches should have different and more specific shortlogs. > > Second patch: > > drm: Query vblank counters directly for known accurate state > > ? Sounds good to me. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile variable, so no need to audit all the
read-side access specifically.
- The barriers for the vblank counter seqlock weren't complete: The
read-side was missing the first barrier between the counter read and
the timestamp read, it only had a barrier between the ts and the
counter read. We need both.
- Barriers weren't properly documented. Since barriers only work if
you have them on boths sides of the transaction it's prudent to
reference where the other side is. To avoid duplicating the
write-side comment 3 times extract a little store_vblank() helper.
In that helper also assert that we do indeed hold
dev->vblank_time_lock, since in some cases the lock is acquired a
few functions up in the callchain.
Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.
v2: Add comment to better explain how store_vblank works, suggested by
Chris.
Cc: Chris Wilson
Cc: Mario Kleiner
Cc: Ville Syrjälä
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 95 +--
include/drm/drmP.h| 8 +++-
2 files changed, 57 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c8a34476570a..8694b77d0002 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -74,6 +74,36 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay, int,
0600);
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
+static void store_vblank(struct drm_device *dev, int crtc,
+unsigned vblank_count_inc,
+struct timeval *t_vblank)
+{
+ struct drm_vblank_crtc *vblank = >vblank[crtc];
+ u32 tslot;
+
+ assert_spin_locked(>vblank_time_lock);
+
+ if (t_vblank) {
+ /* All writers hold the spinlock, but readers are serialized by
+* the latching of vblank->count below.
+*/
+ tslot = vblank->count + vblank_count_inc;
+ vblanktimestamp(dev, crtc, tslot) = *t_vblank;
+ }
+
+ /*
+* vblank timestamp updates are protected on the write side with
+* vblank_time_lock, but on the read side done locklessly using a
+* sequence-lock on the vblank counter. Ensure correct ordering using
+* memory barrriers. We need the barrier both before and also after the
+* counter update to synchronize with the next timestamp write.
+* The read-side barriers for this are in drm_vblank_count_and_time.
+*/
+ smp_wmb();
+ vblank->count += vblank_count_inc;
+ smp_wmb();
+}
+
/**
* drm_update_vblank_count - update the master vblank counter
* @dev: DRM device
@@ -93,7 +123,7 @@ module_param_named(timestamp_monotonic,
drm_timestamp_monotonic, int, 0600);
static void drm_update_vblank_count(struct drm_device *dev, int crtc)
{
struct drm_vblank_crtc *vblank = >vblank[crtc];
- u32 cur_vblank, diff, tslot;
+ u32 cur_vblank, diff;
bool rc;
struct timeval t_vblank;
@@ -129,18 +159,12 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
if (diff == 0)
return;
- /* Reinitialize corresponding vblank timestamp if high-precision query
-* available. Skip this step if query unsupported or failed. Will
-* reinitialize delayed at next vblank interrupt in that case.
+ /*
+* Only reinitialize corresponding vblank timestamp if high-precision
query
+* available and didn't fail. Will reinitialize delayed at next vblank
+* interrupt in that case.
*/
- if (rc) {
- tslot = atomic_read(>count) + diff;
- vblanktimestamp(dev, crtc, tslot) = t_vblank;
- }
-
- smp_mb__before_atomic();
- atomic_add(diff, >count);
- smp_mb__after_atomic();
+ store_vblank(dev, crtc, diff, rc ? _vblank : NULL);
}
/*
@@ -218,7 +242,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
*/
- vblcount = atomic_read(>count);
+ vblcount = vblank->count;
diff_ns = timeval_to_ns() -
timeval_to_ns((dev, crtc, vblcount));
@@ -234,17 +258,8 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
* available. In that case we can't account for this and just
*
[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On Wed, Apr 15, 2015 at 09:17:03AM +0100, Chris Wilson wrote:
> On Wed, Apr 15, 2015 at 09:17:02AM +0200, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index c8a34476570a..23bfbc61a494 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay,
> > int, 0600);
> > module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
> > 0600);
> > module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int,
> > 0600);
> >
> > +static void store_vblank(struct drm_device *dev, int crtc,
> > +unsigned vblank_count_inc,
> > +struct timeval *t_vblank)
> > +{
> > + struct drm_vblank_crtc *vblank = >vblank[crtc];
> > + u32 tslot;
> > +
> > + assert_spin_locked(>vblank_time_lock);
> > +
> > + if (t_vblank) {
> > + tslot = vblank->count + vblank_count_inc;
> > + vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> > + }
>
> It is not obvious this updates the right tslot in all circumstances.
> Care to explain?
Writers are synchronized with vblank_time_lock, so there shouldn't be any
races. Mario also has a patch to clear the ts slot if we don't have
anything to set it too (that one will conflict ofc).
Or what exactly do you mean?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On Wed, Apr 15, 2015 at 11:25:00AM +0200, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 09:17:03AM +0100, Chris Wilson wrote:
> > On Wed, Apr 15, 2015 at 09:17:02AM +0200, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index c8a34476570a..23bfbc61a494 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay,
> > > drm_vblank_offdelay, int, 0600);
> > > module_param_named(timestamp_precision_usec, drm_timestamp_precision,
> > > int, 0600);
> > > module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int,
> > > 0600);
> > >
> > > +static void store_vblank(struct drm_device *dev, int crtc,
> > > + unsigned vblank_count_inc,
> > > + struct timeval *t_vblank)
> > > +{
> > > + struct drm_vblank_crtc *vblank = >vblank[crtc];
> > > + u32 tslot;
> > > +
> > > + assert_spin_locked(>vblank_time_lock);
> > > +
> > > + if (t_vblank) {
> > > + tslot = vblank->count + vblank_count_inc;
> > > + vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> > > + }
> >
> > It is not obvious this updates the right tslot in all circumstances.
> > Care to explain?
>
> Writers are synchronized with vblank_time_lock, so there shouldn't be any
> races. Mario also has a patch to clear the ts slot if we don't have
> anything to set it too (that one will conflict ofc).
>
> Or what exactly do you mean?
I was staring at vblank->count and reading backwards from the smp_wmb().
Just something like:
if (t_vblank) {
/* All writers hold the spinlock, but readers are serialized by
* the latching of vblank->count below.
*/
u32 tslot = vblank->count + vblank_count_inc;
...
would help me understand the relationship better.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v5 04/12] drm/exynos: dsi: rename pll_clk to sclk_clk
On 2015ë
04ì 10ì¼ 14:55, Hyungwon Hwang wrote:
> This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
> is actually not the pll input clock for dsi. The pll input clock comes
> from the board's oscillator directly.
>
> Signed-off-by: Hyungwon Hwang
> ---
> Changes for v3:
> - Newly added
>
> Changes for v4:
> - None
>
> Changes for v5:
> - None
> .../devicetree/bindings/video/exynos_dsim.txt | 7 ++---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c| 31
> --
> 2 files changed, 15 insertions(+), 23 deletions(-)
>
...snip...
> @@ -1350,7 +1341,7 @@ static void exynos_dsi_poweroff(struct exynos_dsi *dsi)
>
> phy_power_off(dsi->phy);
>
> - clk_disable_unprepare(dsi->pll_clk);
> + clk_disable_unprepare(dsi->sclk_clk);
> clk_disable_unprepare(dsi->bus_clk);
>
> ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
> @@ -1713,10 +1704,10 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> return -EPROBE_DEFER;
> }
>
> - dsi->pll_clk = devm_clk_get(dev, "pll_clk");
> - if (IS_ERR(dsi->pll_clk)) {
> - dev_info(dev, "failed to get dsi pll input clock\n");
> - ret = PTR_ERR(dsi->pll_clk);
> + dsi->sclk_clk = devm_clk_get(dev, "sclk_mipi");
As I mentioned before, this patch makes existing device tree to be
broken so this cannot be merged even though you posted an another patch
which resolves the dt broken issue. That is because each patch shouldn't
incur any problem on working. So it'd be better to integrate this patch
and patch 9.
Thanks,
Inki Dae
> + if (IS_ERR(dsi->sclk_clk)) {
> + dev_info(dev, "failed to get dsi sclk clock\n");
> + ret = PTR_ERR(dsi->sclk_clk);
> goto err_del_component;
> }
>
>
[PATCH 05/12] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
code never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, a checksum is generated when the EDID header is detected
as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
logs the errors. In the case of a more seriously damaged header (fixup score
less than the threshold) the code does not generate the checksum but does set
the header_corrupt flag.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
- Maintained blank lines / spacing so as to not contaminate the patch
V6:
- Removed extra debug messages
- Added documentation to for the added parameter on drm_edid_block_valid
- Fixed more whitespace issues in check_link_status
- Added a clear of the header_corrupt flag to the end of the test handler
in intel_dp.c
- Changed the usage of the new function prototype in several places to use
NULL where it is not needed by compliance testing
V7:
- Updated to account for long_pulse flag propagation
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 30 ++
drivers/gpu/drm/drm_edid_load.c | 7 +--
drivers/gpu/drm/i915/intel_dp.c | 6 +-
include/drm/drm_crtc.h | 8 +++-
4 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..1ed18f5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
* @raw_edid: pointer to raw EDID block
* @block: type of block to validate (0 for base, extension otherwise)
* @print_bad_edid: if true, dump bad EDID blocks to the console
+ * @header_corrupt: if true, the header or checksum is invalid
*
* Validate a base or extension EDID block and optionally dump bad blocks to
* the console.
*
* Return: True if the block is valid, false otherwise.
*/
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *header_corrupt)
{
u8 csum;
struct edid *edid = (struct edid *)raw_edid;
@@ -1062,9 +1064,25 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid)
int score = drm_edid_header_is_valid(raw_edid);
if (score == 8) ;
else if (score >= edid_fixup) {
+ /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
+* In order to properly generate the invalid checksum
+* required for this test, it must be generated using
+* the raw EDID data. Otherwise, the fix-up code here
+* will correct the problem, the checksum is correct
+* and the test fails
+*/
+ csum = drm_edid_block_checksum(raw_edid);
+ if (csum) {
+ if (header_corrupt)
+ *header_corrupt = 1;
+ }
DRM_DEBUG("Fixing EDID header, your hardware may be
failing\n");
memcpy(raw_edid, edid_header, sizeof(edid_header));
} else {
+ if (header_corrupt) {
+ DRM_DEBUG_DRIVER("Invalid EDID header\n");
+ *header_corrupt = 1;
+ }
goto bad;
}
}
@@
[Bug 90034] account request for amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=90034 --- Comment #1 from Christian König --- You need to attach the PGP as file, not inline in the bug report. Please see http://www.freedesktop.org/wiki/AccountRequests/ as well. Apart from that we obviously support this request. Regards, Christian. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/bb60b427/attachment.html>
[PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Stefan, > -Original Message- > From: Stefan Agner [mailto:stefan at agner.ch] > Sent: Wednesday, April 08, 2015 3:57 PM > To: Wang Jianwei-B52261 > Cc: Wood Scott-B07421; airlied at linux.ie; dri-devel at > lists.freedesktop.org; > devicetree at vger.kernel.org; Xiubo Li; Wang Huan-B18965; linux- > kernel at vger.kernel.org; Jin Zhengxiong-R64188; linux-arm- > kernel at lists.infradead.org > Subject: RE: [PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM driver > > On 2015-04-08 09:17, Jianwei.Wang at freescale.com wrote: > > Hi Stefan, > > > >> -Original Message- > >> From: Stefan Agner [mailto:stefan at agner.ch] > >> Sent: Tuesday, April 07, 2015 8:12 PM > >> To: Wang Jianwei-B52261 > >> Cc: Wood Scott-B07421; airlied at linux.ie; dri- > devel at lists.freedesktop.org; > >> devicetree at vger.kernel.org; Xiubo Li; Wang Huan-B18965; linux- > >> kernel at vger.kernel.org; Jin Zhengxiong-R64188; linux-arm- > >> kernel at lists.infradead.org > >> Subject: RE: [PATCH v3 1/4] drm/layerscape: Add Freescale DCU DRM > driver > >> > >> Hi Jianwei, > >> > >> On 2015-04-07 08:44, Jianwei.Wang at freescale.com wrote: > >> > Hi Stefan, > >> > > >> > Thank you for your review and testing on Vybrid F610 device. This > driver > >> > just implement the basic functions and it only support the exported > >> > framebuffer access. Some DRM interfaces are not implemented now. So > your > >> > test result is normal. I will implement these interfaces with patches > >> soon > >> > afterwards. I don't plan to add new features for the initial version > >> driver, > >> > otherwise it will be a long term for this version. > >> > > >> > I tested on ls1021a using TFT panel, there are no flickers on the > screen > >> > when inserting a USB HID device. I will do more test if time permits. > >> > > >> > By the way, could please give me some guidance on how X-Server use > DRM > >> > Interface directly? Do you have some papers or webpage about this? > >> > >> I'm using the modesetting X.org driver. Lots of distributions ship that > >> driver as a package (e.g. xserver-xorg-video-modesetting in Debian, or > >> xf86-video-modesetting in OpenEmbedded). Since 1.17 this driver has > even > >> been included into the main source tree of Xorg X-Server > >> > (http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/drivers/modesett > >> ing) > >> > >> This driver is using KMS/DRM interface and should work well for > >> un-accelerated graphic devices. This is a a much nicer way to use X.org > >> on top of a DRM driver, since it avoids going through the legacy fbdev > >> interface. The man page shows how to use it: > >> http://linux.die.net/man/4/modesetting > >> > >> So, when the driver is installed, it is just choosing that driver in > >> xorg.conf: > >> > >> Section "Device" > >> Identifier "dcu" > >> Driver "modesetting" > >> EndSection > >> > > > > Thank you for your guidance. > > > >> Some more comments below... > >> > >> > > >> > My reply below... > >> > > >> >> > >> >> Hi Jianwei, > >> >> > >> >> The driver worked on a Vybrid VF610 device using the exported > >> >> framebuffer. However, when using X-Server through the DRM interface > >> >> directly (by using the modesetting driver) I get just a black screen > so > >> >> far, still investigating the reason. What user-space interfaces did > you > >> >> test? > >> >> > >> >> When using the FB device and insert a USB HID device, I get some > >> >> flickers on the screen. I didn't had those on the dcufb driver, did > you > >> >> notice something like this too? Probably related to the resolution, > I'm > >> >> using VGA resolution. > >> >> > >> >> Some comments below. > >> >> > >> >> > >> >> On 2015-03-26 06:37, Jianwei Wang wrote: > >> >> > This patch add support for Two Dimensional Animation and > Compositing > >> >> > Engine (2D-ACE) on the Freescale SoCs. > >> >> > > >> >> > 2D-ACE is a Freescale display controller. 2D-ACE describes > >> >> > the functionality of the module extremely well its name is a value > >> >> > that cannot be used as a token in programming languages. > >> >> > Instead the valid token "DCU" is used to tag the register names > and > >> >> > function names. > >> >> > > >> >> > The Display Controller Unit (DCU) module is a system master that > >> >> > fetches graphics stored in internal or external memory and > displays > >> >> > them on a TFT LCD panel. A wide range of panel sizes is supported > >> >> > and the timing of the interface signals is highly configurable. > >> >> > Graphics are read directly from memory and then blended in real- > time, > >> >> > which allows for dynamic content creation with minimal CPU > >> >> > intervention. > >> >> > > >> >> > The features: > >> >> > (1) Full RGB888 output to TFT LCD panel. > >> >> > (2) For the current LCD panel, WQVGA "480x272" is supported. > >> >> > (3) Blending of each pixel using up to 4 source layers > >> >> > dependent on size of panel. > >> >> > >> >> modetest
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On Wed, Apr 15, 2015 at 09:17:02AM +0200, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8a34476570a..23bfbc61a494 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay,
> int, 0600);
> module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
> 0600);
> module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
>
> +static void store_vblank(struct drm_device *dev, int crtc,
> + unsigned vblank_count_inc,
> + struct timeval *t_vblank)
> +{
> + struct drm_vblank_crtc *vblank = >vblank[crtc];
> + u32 tslot;
> +
> + assert_spin_locked(>vblank_time_lock);
> +
> + if (t_vblank) {
> + tslot = vblank->count + vblank_count_inc;
> + vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> + }
It is not obvious this updates the right tslot in all circumstances.
Care to explain?
Otherwise the rest looks consistent with seqlock, using the
vblank->count as the latch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile variable, so no need to audit all the
read-side access specifically.
- The barriers for the vblank counter seqlock weren't complete: The
read-side was missing the first barrier between the counter read and
the timestamp read, it only had a barrier between the ts and the
counter read. We need both.
- Barriers weren't properly documented. Since barriers only work if
you have them on boths sides of the transaction it's prudent to
reference where the other side is. To avoid duplicating the
write-side comment 3 times extract a little store_vblank() helper.
In that helper also assert that we do indeed hold
dev->vblank_time_lock, since in some cases the lock is acquired a
few functions up in the callchain.
Spotted while reviewing a patch from Chris Wilson to add a fastpath to
the vblank_wait ioctl.
Cc: Chris Wilson
Cc: Mario Kleiner
Cc: Ville Syrjälä
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 92 ---
include/drm/drmP.h| 8 +++--
2 files changed, 54 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index c8a34476570a..23bfbc61a494 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay, int,
0600);
module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
0600);
module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
+static void store_vblank(struct drm_device *dev, int crtc,
+unsigned vblank_count_inc,
+struct timeval *t_vblank)
+{
+ struct drm_vblank_crtc *vblank = >vblank[crtc];
+ u32 tslot;
+
+ assert_spin_locked(>vblank_time_lock);
+
+ if (t_vblank) {
+ tslot = vblank->count + vblank_count_inc;
+ vblanktimestamp(dev, crtc, tslot) = *t_vblank;
+ }
+
+ /*
+* vblank timestamp updates are protected on the write side with
+* vblank_time_lock, but on the read side done locklessly using a
+* sequence-lock on the vblank counter. Ensure correct ordering using
+* memory barrriers. We need the barrier both before and also after the
+* counter update to synchronize with the next timestamp write.
+* The read-side barriers for this are in drm_vblank_count_and_time.
+*/
+ smp_wmb();
+ vblank->count += vblank_count_inc;
+ smp_wmb();
+}
+
/**
* drm_update_vblank_count - update the master vblank counter
* @dev: DRM device
@@ -93,7 +120,7 @@ module_param_named(timestamp_monotonic,
drm_timestamp_monotonic, int, 0600);
static void drm_update_vblank_count(struct drm_device *dev, int crtc)
{
struct drm_vblank_crtc *vblank = >vblank[crtc];
- u32 cur_vblank, diff, tslot;
+ u32 cur_vblank, diff;
bool rc;
struct timeval t_vblank;
@@ -129,18 +156,12 @@ static void drm_update_vblank_count(struct drm_device
*dev, int crtc)
if (diff == 0)
return;
- /* Reinitialize corresponding vblank timestamp if high-precision query
-* available. Skip this step if query unsupported or failed. Will
-* reinitialize delayed at next vblank interrupt in that case.
+ /*
+* Only reinitialize corresponding vblank timestamp if high-precision
query
+* available and didn't fail. Will reinitialize delayed at next vblank
+* interrupt in that case.
*/
- if (rc) {
- tslot = atomic_read(>count) + diff;
- vblanktimestamp(dev, crtc, tslot) = t_vblank;
- }
-
- smp_mb__before_atomic();
- atomic_add(diff, >count);
- smp_mb__after_atomic();
+ store_vblank(dev, crtc, diff, rc ? _vblank : NULL);
}
/*
@@ -218,7 +239,7 @@ static void vblank_disable_and_save(struct drm_device *dev,
int crtc)
/* Compute time difference to stored timestamp of last vblank
* as updated by last invocation of drm_handle_vblank() in vblank irq.
*/
- vblcount = atomic_read(>count);
+ vblcount = vblank->count;
diff_ns = timeval_to_ns() -
timeval_to_ns((dev, crtc, vblcount));
@@ -234,17 +255,8 @@ static void vblank_disable_and_save(struct drm_device
*dev, int crtc)
* available. In that case we can't account for this and just
* hope for the best.
*/
- if (vblrc && (abs64(diff_ns) > 100)) {
- /* Store new timestamp in ringbuffer. */
- vblanktimestamp(dev, crtc, vblcount + 1) = tvblank;
-
- /*
[PATCH] drm/vblank: Fixup and document timestamp update/read barriers
Hi Daniel,
On 04/15/2015 03:17 AM, Daniel Vetter wrote:
> This was a bit too much cargo-culted, so lets make it solid:
> - vblank->count doesn't need to be an atomic, writes are always done
> under the protection of dev->vblank_time_lock. Switch to an unsigned
> long instead and update comments. Note that atomic_read is just a
> normal read of a volatile variable, so no need to audit all the
> read-side access specifically.
>
> - The barriers for the vblank counter seqlock weren't complete: The
> read-side was missing the first barrier between the counter read and
> the timestamp read, it only had a barrier between the ts and the
> counter read. We need both.
>
> - Barriers weren't properly documented. Since barriers only work if
> you have them on boths sides of the transaction it's prudent to
> reference where the other side is. To avoid duplicating the
> write-side comment 3 times extract a little store_vblank() helper.
> In that helper also assert that we do indeed hold
> dev->vblank_time_lock, since in some cases the lock is acquired a
> few functions up in the callchain.
>
> Spotted while reviewing a patch from Chris Wilson to add a fastpath to
> the vblank_wait ioctl.
>
> Cc: Chris Wilson
> Cc: Mario Kleiner
> Cc: Ville Syrjälä
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c | 92
> ---
> include/drm/drmP.h| 8 +++--
> 2 files changed, 54 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8a34476570a..23bfbc61a494 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay,
> int, 0600);
> module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
> 0600);
> module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
>
> +static void store_vblank(struct drm_device *dev, int crtc,
> + unsigned vblank_count_inc,
> + struct timeval *t_vblank)
> +{
> + struct drm_vblank_crtc *vblank = >vblank[crtc];
> + u32 tslot;
> +
> + assert_spin_locked(>vblank_time_lock);
> +
> + if (t_vblank) {
> + tslot = vblank->count + vblank_count_inc;
> + vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> + }
> +
> + /*
> + * vblank timestamp updates are protected on the write side with
> + * vblank_time_lock, but on the read side done locklessly using a
> + * sequence-lock on the vblank counter. Ensure correct ordering using
> + * memory barrriers. We need the barrier both before and also after the
> + * counter update to synchronize with the next timestamp write.
> + * The read-side barriers for this are in drm_vblank_count_and_time.
> + */
> + smp_wmb();
> + vblank->count += vblank_count_inc;
> + smp_wmb();
The comment and the code are each self-contradictory.
If vblank->count writes are always protected by vblank_time_lock (something I
did not verify but that the comment above asserts), then the trailing write
barrier is not required (and the assertion that it is in the comment is
incorrect).
A spin unlock operation is always a write barrier.
Regards,
Peter Hurley
> +}
> +
> /**
> * drm_update_vblank_count - update the master vblank counter
> * @dev: DRM device
> @@ -93,7 +120,7 @@ module_param_named(timestamp_monotonic,
> drm_timestamp_monotonic, int, 0600);
> static void drm_update_vblank_count(struct drm_device *dev, int crtc)
> {
> struct drm_vblank_crtc *vblank = >vblank[crtc];
> - u32 cur_vblank, diff, tslot;
> + u32 cur_vblank, diff;
> bool rc;
> struct timeval t_vblank;
>
> @@ -129,18 +156,12 @@ static void drm_update_vblank_count(struct drm_device
> *dev, int crtc)
> if (diff == 0)
> return;
>
> - /* Reinitialize corresponding vblank timestamp if high-precision query
> - * available. Skip this step if query unsupported or failed. Will
> - * reinitialize delayed at next vblank interrupt in that case.
> + /*
> + * Only reinitialize corresponding vblank timestamp if high-precision
> query
> + * available and didn't fail. Will reinitialize delayed at next vblank
> + * interrupt in that case.
>*/
> - if (rc) {
> - tslot = atomic_read(>count) + diff;
> - vblanktimestamp(dev, crtc, tslot) = t_vblank;
> - }
> -
> - smp_mb__before_atomic();
> - atomic_add(diff, >count);
> - smp_mb__after_atomic();
> + store_vblank(dev, crtc, diff, rc ? _vblank : NULL);
> }
>
> /*
> @@ -218,7 +239,7 @@ static void vblank_disable_and_save(struct drm_device
> *dev, int crtc)
> /* Compute time difference to stored timestamp of last vblank
>* as updated by last invocation of drm_handle_vblank() in vblank irq.
>*/
>
Help on drmModeSetPlane
I tried crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) but get a crash, How can I enable scaling on overlay for video frame? William From: Xie, William Sent: Wednesday, April 15, 2015 4:49 PM To: DRI Development; DRI Development Subject: RE: Help on drmModeSetPlane To make it more specific, For example: 1: video frame size is 1280x720, 2: screen resolution is 3200x1800, How can I set crtc and src parameters? 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) 2: crtc (0, 0, 3200, 1800) src (0, 0, 1280<<16, 720<<16) Which one is correct? William From: Xie, William Sent: Wednesday, April 15, 2015 3:55 PM To: DRI Development; DRI Development Subject: Help on drmModeSetPlane Question please, could someone share the meaning of the parameters for drmModeSetPlane in libdrm? int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, int32_t crtc_x, int32_t crtc_y, uint32_t crtc_w, uint32_t crtc_h, uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h) My problem is, whatever value I set, the video is not full screen mode, Anything I missed? Thanks William -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/04b27062/attachment-0001.html>
Help on drmModeSetPlane
To make it more specific, For example: 1: video frame size is 1280x720, 2: screen resolution is 3200x1800, How can I set crtc and src parameters? 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16) 2: crtc (0, 0, 3200, 1800) src (0, 0, 1280<<16, 720<<16) Which one is correct? William From: Xie, William Sent: Wednesday, April 15, 2015 3:55 PM To: DRI Development; DRI Development Subject: Help on drmModeSetPlane Question please, could someone share the meaning of the parameters for drmModeSetPlane in libdrm? int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, int32_t crtc_x, int32_t crtc_y, uint32_t crtc_w, uint32_t crtc_h, uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h) My problem is, whatever value I set, the video is not full screen mode, Anything I missed? Thanks William -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/ac48b60e/attachment.html>
[PATCH 10/10] drm: Fix the 'native defer' message in drm_dp_i2c_do_msg()
The debug message is missing a newline at the end and it makes the
logs hard to read when a device defers a lot. Simple 2-character fix
adds the newline at the end.
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Paulo Zanoni
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 7f0356e..80a02a4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -466,7 +466,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
return -EREMOTEIO;
case DP_AUX_NATIVE_REPLY_DEFER:
- DRM_DEBUG_KMS("native defer");
+ DRM_DEBUG_KMS("native defer\n");
/*
* We could check for I2C bit rate capabilities and if
* available adjust this interval. We could also be
--
1.9.1
[PATCH 08/10] drm: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
since there are native defers interspersed with the I2C defers which
results in less than 7 EDID read attempts.
The solution is to add the numer of defers to the retry counter when an I2C
DEFER is returned such that another read attempt will be made. This situation
should normally only occur in compliance testing, however, as a worse case
real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C
defers) for a single transaction to complete. The net result is a slightly
slower response to an EDID read that shouldn't significantly impact overall
performance.
V2:
- Added a check on the number of I2C Defers to limit the number
of times that the retries variable will be decremented. This
is to address review feedback regarding possible infinite loops
from misbehaving sink devices.
V3:
- Fixed the limit value to 7 instead of 8 to get the correct retry
count.
- Combined the increment of the defer count into the if-statement
V4:
- Removed i915 tag from subject as the patch is not i915-specific
V5:
- Updated the for-loop to add the number of i2c defers to the retry
counter such that the correct number of retry attempts will be
made
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_dp_helper.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 71dcbc6..7f0356e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -432,7 +432,7 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter
*adapter)
*/
static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg
*msg)
{
- unsigned int retry;
+ unsigned int retry, defer_i2c;
int ret;
/*
@@ -440,7 +440,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
* is required to retry at least seven times upon receiving AUX_DEFER
* before giving up the AUX transaction.
*/
- for (retry = 0; retry < 7; retry++) {
+ for (retry = 0, defer_i2c = 0; retry < (7 + defer_i2c); retry++) {
mutex_lock(>hw_mutex);
ret = aux->transfer(aux, msg);
mutex_unlock(>hw_mutex);
@@ -499,7 +499,13 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
case DP_AUX_I2C_REPLY_DEFER:
DRM_DEBUG_KMS("I2C defer\n");
+ /* DP Compliance Test 4.2.2.5 Requirement:
+* Must have at least 7 retries for I2C defers on the
+* transaction to pass this test
+*/
aux->i2c_defer_count++;
+ if (defer_i2c < 7)
+ defer_i2c++;
usleep_range(400, 500);
continue;
--
1.9.1
[PATCH 05/10] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
code never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, a checksum is generated when the EDID header is detected
as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
logs the errors. In the case of a more seriously damaged header (fixup score
less than the threshold) the code does not generate the checksum but does set
the header_corrupt flag.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
- Maintained blank lines / spacing so as to not contaminate the patch
V6:
- Removed extra debug messages
- Added documentation to for the added parameter on drm_edid_block_valid
- Fixed more whitespace issues in check_link_status
- Added a clear of the header_corrupt flag to the end of the test handler
in intel_dp.c
- Changed the usage of the new function prototype in several places to use
NULL where it is not needed by compliance testing
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c | 30 ++
drivers/gpu/drm/drm_edid_load.c | 7 +--
drivers/gpu/drm/i915/intel_dp.c | 6 +-
include/drm/drm_crtc.h | 8 +++-
4 files changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..1ed18f5 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1041,13 +1041,15 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
* @raw_edid: pointer to raw EDID block
* @block: type of block to validate (0 for base, extension otherwise)
* @print_bad_edid: if true, dump bad EDID blocks to the console
+ * @header_corrupt: if true, the header or checksum is invalid
*
* Validate a base or extension EDID block and optionally dump bad blocks to
* the console.
*
* Return: True if the block is valid, false otherwise.
*/
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *header_corrupt)
{
u8 csum;
struct edid *edid = (struct edid *)raw_edid;
@@ -1062,9 +1064,25 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid)
int score = drm_edid_header_is_valid(raw_edid);
if (score == 8) ;
else if (score >= edid_fixup) {
+ /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
+* In order to properly generate the invalid checksum
+* required for this test, it must be generated using
+* the raw EDID data. Otherwise, the fix-up code here
+* will correct the problem, the checksum is correct
+* and the test fails
+*/
+ csum = drm_edid_block_checksum(raw_edid);
+ if (csum) {
+ if (header_corrupt)
+ *header_corrupt = 1;
+ }
DRM_DEBUG("Fixing EDID header, your hardware may be
failing\n");
memcpy(raw_edid, edid_header, sizeof(edid_header));
} else {
+ if (header_corrupt) {
+ DRM_DEBUG_DRIVER("Invalid EDID header\n");
+ *header_corrupt = 1;
+ }
goto bad;
}
}
@@ -1129,7 +1147,7 @@ bool drm_edid_is_valid(struct edid *edid)
[PATCH 2/2] drm: Shortcircuit vblank queries
On Tue, Apr 14, 2015 at 08:43:12PM +0200, Mario Kleiner wrote:
> On 04/05/2015 05:40 PM, Chris Wilson wrote:
> >Bypass all the spinlocks and return the last timestamp and counter from
> >the last vblank if the driver delcares that it is accurate (and stable
> >across on/off), and the vblank is currently enabled.
> >
> >Signed-off-by: Chris Wilson
> >Cc: Ville Syrjälä
> >Cc: Daniel Vetter
> >Cc: Michel Dänzer
> >Cc: Laurent Pinchart
> >Cc: Dave Airlie ,
> >Cc: Mario Kleiner
> >---
> > drivers/gpu/drm/drm_irq.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >index ba80b51b4b00..be9c210bb22e 100644
> >--- a/drivers/gpu/drm/drm_irq.c
> >+++ b/drivers/gpu/drm/drm_irq.c
> >@@ -1538,6 +1538,17 @@ err_put:
> > return ret;
> > }
> >
> >+static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
> >+{
> >+if (vblwait->request.sequence)
> >+return false;
> >+
> >+return _DRM_VBLANK_RELATIVE ==
> >+(vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
> >+ _DRM_VBLANK_EVENT |
> >+ _DRM_VBLANK_NEXTONMISS));
> >+}
> >+
> > /*
> > * Wait for VBLANK.
> > *
> >@@ -1587,6 +1598,21 @@ int drm_wait_vblank(struct drm_device *dev, void
> >*data,
> >
> > vblank = >vblank[crtc];
> >
> >+/* If the counter is currently enabled and accurate, short-circuit
> >queries
> >+ * to return the cached timestamp of the last vblank.
> >+ */
>
> Maybe somehow stress in the comment that this location in drm_wait_vblank is
> really the only place where it is ok'ish to call
> drm_vblank_count_and_time() without wrapping it into a drm_vblank_get/put(),
> so nobody thinks this approach is ok anywhere else.
>
> >+if (dev->vblank_disable_immediate &&
> >+drm_wait_vblank_is_query(vblwait) &&
> >+vblank->enabled) {
>
> You should also check for (drm_vblank_offdelay != 0) whenever checking for
> dev->vblank_disable_immediate. This is so one can override all the
> vblank_disable_immediate related logic via the drm vblankoffdelay module
> parameter, both for debugging and as a safety switch for desparate users in
> case some driver+gpu combo screws up wrt. immediate disable and that makes
> it into distro kernels.
>
> The other thing i'm not sure is if it wouldn't be a good idea to have some
> kind of write memory barrier in vblank_disable_and_save() after setting
> vblank->enabled = false; and some read memory barrier here before your check
> for vblank->enabled? I don't have a feeling for how much time can pass
> between one core executing the disable and the other core receiving the news
> that vblank->enabled is no longer true if those bits run on different cores?
>
> I've run your patches through my standard tests on x86_64 and they don't
> seem to introduce errors or more skipped frames. Normally it would be so
> wrong to do this without drm_vblank_get/put(), but i think here potential
> errors introduced wouldn't be worse than what a userspace client would see
> due to preemption or other execution delays at the wrong moment, so it's
> probably ok. But i don't know if lack of memory barriers etc. could
> introduce large delays and trouble on other architectures?
Barriers don't reduce that latency but only enforce ordering. And you
always need two of them, one on the sending side of some piece of data and
the other on the receiving side. From that pov drm_vblank_count_and_time
is broken since it doesn't fully braket the timestamp read against the
counter update (you'd need a barrier both before and after), and the
barrier on the write side is missing. And then it's also too heavy, as
long as we only have 1 updater we don't need atomics for the counter.
I think I'll review this properly and then write a patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Help on drmModeSetPlane
Question please, could someone share the meaning of the parameters for drmModeSetPlane in libdrm? int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id, uint32_t fb_id, uint32_t flags, int32_t crtc_x, int32_t crtc_y, uint32_t crtc_w, uint32_t crtc_h, uint32_t src_x, uint32_t src_y, uint32_t src_w, uint32_t src_h) My problem is, whatever value I set, the video is not full screen mode, Anything I missed? Thanks William -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/da829596/attachment.html>
what does the glob array mean in DRM?
Hi.
It's a generic interface for stuff that needs to be global across all
devices. Currently I think it's only used for
ttm memory accounting.
Thanks,
Thomas
On 04/15/2015 07:13 AM, z f wrote:
> hi, I am start reading the DRM code in Linux.
> drm_core_init() -> drm_global_init()
> the later does something like this:
>
> struct drm_global_item {
> struct mutex mutex;
> void *object;
> int refcount;
> };
>
> static struct drm_global_item glob[DRM_GLOBAL_NUM];
>
> void drm_global_init(void)
> {
> int i;
>
> for (i = 0; i < DRM_GLOBAL_NUM; ++i) {
> struct drm_global_item *item = [i];
> mutex_init(>mutex);
> item->object = NULL;
> item->refcount = 0;
> }
> }
>
> what's the glob array used for?
> sorry for asking question so sample, because I cant find great
> acticles to learn DRM.
[Bug 90034] account request for amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=90034 Bug ID: 90034 Summary: account request for amdgpu Product: DRI Version: DRI git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: jammy.zhou at aliyun.com Created attachment 115074 --> https://bugs.freedesktop.org/attachment.cgi?id=115074=edit SSH key Hi, I'd like to request a FDO account for development of the new amdgpu driver. The ssh key is attached. And the gpg key is given below. -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQENBFUt/J0BCACbEv63d0j0nIG/JEltNFSyDKrBUJoeUsx8+creQ7YFMeqA02Cq V+H6IUCT5+zBqW5HBzwPQHz4+znmrPP6jpYUpBvzg6q0Ws5UQads96CMTHnlR4D6 RL6F/COYl/Tlfb1snNgLPwi+J+XAhrwA83nDskdv+eWDr7hjvA6x2mlPk7QSyTe3 odTxBuB/E9vJFrVq1BrX1WZGir/QVCwMOl2yhTLAlSGGAPQAzqbesfvGIQuxe5LI DKzdhzY/EptomqECni1ZhAuwroVLlnEVKigs5Rfx3mT6JD26ZfVjXxNleSDIuTs1 R1ikdhhajmuxAmIrN5N75EVLJZRlA5RTSniPABEBAAG0H0phbW15IFpob3UgPEph bW15Llpob3VAYW1kLmNvbT6JATgEEwECACIFAlUt/J0CGwMGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJEOk5puvXJyEOmbEH/iHGpFvjeWtfPq7rZFch/zeYCerT Y1JqeqxfpoApL+9g6Nz6h+BaeOkD434BMaw6riVfP+Kj/bHyDUBWyOyEX4ZWW1Eo seh3PoGMXhimob29SA8mtqrfYmU+WYOvzfpsDG25w6aMcbnU1oklOtMazZFrGbvX pCmpPuhuDIDuofzk1ZmmNwERDQOWmlkxLoqiY7b1Pq9huSZ8K1eTz9jqvtVP8u1N G6n2B97KKsDjm0NCOBvy72XdukHIWARXhEg4JWxsSs8A5+9noo1MH6qSG4LZV9xw izUiEjVvVZiBo7dhKpPKRMScxV2KbsC4J/qmPeUxSwqe2Ki7+EA/7jPR0Zy5AQ0E VS38nQEIANSaFavLty7fGiSuWurhByk00P03F8howP5jXJntNcwnK/8OR5Ye7Pq7 4JjAnxRti+Z8epljOUe1Xdexp3m6hhz8pKKxO33Yv1uVVIUljemMbqIxrdkz4uQy MHtak8JDSd88RKIPJqVOUI46ZHJRsCi40wjrI8Z4eU5jEaXSnzLKA8fafTVE1orA HswzLa10gtKtqQYT54vLWJtCm1eRfxp97YABPNdd/mtnZlMPWOVyqDN+6DIYtejI 6uLkkb+My3fyubyndK0vcvb+vUKiaar+sqAI28j8cg6ulxZd74bPNn28I+np01bR 9y77s4xFqraRcGi3Ig14tkiyUs1DUR0AEQEAAYkBHwQYAQIACQUCVS38nQIbDAAK CRDpOabr1ychDhJRB/4yWgea12BrQmyQypbjFbJuMzOIkFJfhEwXqxkyj13SNRZN RJj68ggbOXJyCuKdF8MVJ0LWnDL7+WGx0Xkmp4KcUmuGYEYwHAYXnmIH0Me/efv1 uK1mxP+BOsaI1p8GySJrsEAVXFFdC7+kfga/5gbkBhY/LLMojsYwDRFl1mLI7C/N c+ySHR/Z45Fby2LMwXAdTIC3K+fZ2cTvFj/YPebdFkjO1HYtGAfwl27KKGxeTZhV O9Z4NRxWXsCtnS7utIBf10m96rnSViLpwDyxRYx40da2WkLz4f6xqCigfXmkvClf BqqWCDkOklVupL0IlKk3OPII1Ge3ct1Mzg3wZS2Q =usKI -END PGP PUBLIC KEY BLOCK- Thanks! Jammy -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/779661c6/attachment.html>
[Bug 89829] [bisected] radeonsi, commit 2cf48c creates artefacts in some applications (worst being Flash animations that are garbage)
https://bugs.freedesktop.org/show_bug.cgi?id=89829 Alexandre Demers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Alexandre Demers --- Retested with last weekend code and it was still problematic. So today I intended to investigate the bug. I had narrowed it to the create/generate buffer. Then, I synced my code to today's commits, commented out the part where we were creating/generating buffers so only dummy buffers would be used and tested it again, and it was fine. Finally, I reverted any changes I had made, rebuilt, installed it along a new pepper-flash plugin and this time everything is fine. Because I updated both mesa to the latest git code at the same time as the pepper-flash plugin, I can't tell which one was problematic, but it is now fixed. Closing this bug -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/3420ba08/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #47 from Laurent carlier --- Please test, i cannot reproduce lockup with mesa-git 69411.05a1d84 and llvm-libs-svn 234894 (played 20 minutes) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/46749d31/attachment.html>
[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
https://bugs.freedesktop.org/show_bug.cgi?id=89971 --- Comment #8 from Michel Dänzer --- (In reply to Adrian Gabor from comment #4) > The following is all the logs I could get after plugging the tv in: I mean the logs from the kernel driver initializing and Xorg starting while the TV is plugged in. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/89f283a8/attachment.html>
[Bug 83274] XCom Enemy Unknown segfault at src/gallium/drivers/radeon/r600_texture.c:602
https://bugs.freedesktop.org/show_bug.cgi?id=83274 --- Comment #4 from Michel Dänzer --- (In reply to nicolas from comment #3) > Can you explain me what parameters i have to use with valgrind ( i have > installed it) so that it can makes a useful output for you? For a start, just prepend valgrind to the final command line invoked for starting the game. I don't know offhand how to do that for XCOM, hopefully someone else can help you with that if needed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/f2e9fd1b/attachment.html>
[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)
https://bugs.freedesktop.org/show_bug.cgi?id=89980 Michel Dänzer changed: What|Removed |Added CC||maraeo at gmail.com --- Comment #6 from Michel Dänzer --- (In reply to falaca from comment #4) > 4a5519f1e019dbf1103e4f3abe0a695637a87518 is the first bad commit > commit 4a5519f1e019dbf1103e4f3abe0a695637a87518 > Author: Marek Olšák > Date: Mon Feb 10 01:25:54 2014 +0100 > > r600g,radeonsi: set correct initial domain for shared resources Weird. Marek, any ideas? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/3f7cd281/attachment.html>
[PATCH] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
On 04/02/2015 01:34 PM, Chris Wilson wrote:
> On vblank instant-off systems, we can get into a situation where the cost
> of enabling and disabling the vblank IRQ around a drmWaitVblank query
> dominates. However, we know that if the user wants the current vblank
> counter, they are also very likely to immediately queue a vblank wait
> and so we can keep the interrupt around and only turn it off if we have
> no further vblank requests in the interrupt interval.
>
> After vblank event delivery there is a shadow of one vblank where the
> interrupt is kept alive for the user to query and queue another vblank
> event. Similarly, if the user is using blocking drmWaitVblanks, the
> interrupt will be disabled on the IRQ following the wait completion.
> However, if the user is simply querying the current vblank counter and
> timestamp, the interrupt will be disabled after every IRQ and the user
> will enabled it again on the first query following the IRQ.
>
> Testcase: igt/kms_vblank
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Michel Dänzer
> Cc: Laurent Pinchart
> Cc: Dave Airlie ,
> Cc: Mario Kleiner
> ---
> drivers/gpu/drm/drm_irq.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8a34476570a..6f5dc18779e2 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1091,9 +1091,9 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> if (atomic_dec_and_test(>refcount)) {
> if (drm_vblank_offdelay == 0)
> return;
> - else if (dev->vblank_disable_immediate || drm_vblank_offdelay <
> 0)
> + else if (drm_vblank_offdelay < 0)
> vblank_disable_fn((unsigned long)vblank);
> - else
> + else if (!dev->vblank_disable_immediate)
> mod_timer(>disable_timer,
> jiffies + ((drm_vblank_offdelay * HZ)/1000));
> }
> @@ -1697,6 +1697,17 @@ bool drm_handle_vblank(struct drm_device *dev, int
> crtc)
>
> spin_lock_irqsave(>event_lock, irqflags);
>
You could move the code before the spin_lock_irqsave(>event_lock,
irqflags); i think it doesn't need that lock?
> + if (dev->vblank_disable_immediate && !atomic_read(>refcount)) {
Also check for (drm_vblank_offdelay > 0) to make sure we have a way out
of instant disable here, and the same meaning of of drm_vblank_offdelay
like we have in the current implementation.
This hunk ...
> + unsigned long vbl_lock_irqflags;
> +
> + spin_lock_irqsave(>vbl_lock, vbl_lock_irqflags);
> + if (atomic_read(>refcount) == 0 && vblank->enabled) {
> + DRM_DEBUG("disabling vblank on crtc %d\n", crtc);
> + vblank_disable_and_save(dev, crtc);
> + }
> + spin_unlock_irqrestore(>vbl_lock, vbl_lock_irqflags);
... is the same as a call to vblank_disable_fn((unsigned long) vblank);
Maybe replace by that call?
You could also return here already, as the code below will just take a
lock, realize vblanks are now disabled and then release the locks and exit.
> + }
> +
> /* Need timestamp lock to prevent concurrent execution with
>* vblank enable/disable, as this would cause inconsistent
>* or corrupted timestamps and vblank counts.
>
I think the logic itself is fine and at least basic testing of the patch
on a Intel HD Ironlake didn't show problems, so with the above taken
into account it would have my slightly uneasy reviewed-by.
One thing that worries me a little bit about the disable inside vblank
irq are the potential races between the disable code and the display
engine which could cause really bad off-by-one errors for clients on a
imperfect driver. These races can only happen if vblank enable or
disable happens close to or inside the vblank. This approach lets the
instant disable happen exactly inside vblank when there is the highest
chance of triggering that condition.
This doesn't seem to be a problem for intel kms, but other drivers don't
have instant disable yet, so we don't know how well we could do it
there. Additionally things like dynamic power management tend to operate
inside vblank, sometimes with "funny" side effects to other stuff, e.g.,
dpm on AMD, as i remember from some long debug session with Michel and
Alex last summer where dpm played a role. Therefore it seems more safe
to me to avoid actions inside vblank that could be done outside. E.g.,
instead of doing the disable inside the vblank irq one could maybe just
schedule an exact timer to do the disable a few milliseconds later in
the middle of active scanout to avoid these potential issues?
-mario
[PATCH] drm/radeon: use 0-255 rather than 0-100 for pwm fan range
On 13/04/2015 02:42, Alex Deucher wrote:
> On Sat, Apr 11, 2015 at 5:52 AM, Martin Peres wrote:
>> On 05/02/2015 11:49, Christian König wrote:
>>> Am 04.02.2015 um 23:27 schrieb Alex Deucher:
0-255 seems to be the preferred range for the pwm interface.
Signed-off-by: Alex Deucher
>>> Yeah, using 100 on a 8bit pwm timer sounds rather obviously wrong.
>>>
>>> Patch is Reviewed-by: Christian König
>>>
---
drivers/gpu/drm/radeon/radeon_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 91e1bd2..9f758d3 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -585,7 +585,7 @@ static ssize_t radeon_hwmon_set_pwm1_enable(struct
device *dev,
if (err)
return err;
-switch(value) {
+ switch (value) {
case 1: /* manual, percent-based */
rdev->asic->dpm.fan_ctrl_set_mode(rdev,
FDO_PWM_MODE_STATIC);
break;
@@ -608,7 +608,7 @@ static ssize_t radeon_hwmon_get_pwm1_max(struct
device *dev,
struct device_attribute *attr,
char *buf)
{
- return sprintf(buf, "%i\n", 100); /* pwm uses percent-based
fan-control */
+ return sprintf(buf, "%i\n", 255);
}
>>
>> This is not a standard name as it is not documented in
>> https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
>>
>> Apparently, the pwm value should always have been exposed as 0-255 and I
>> screwed it up in nouveau by having it be 0-100...
>>
>> Maybe we should ask pwm*_max to be defined so as new applications could do
>> the right thing while not having nouveau change its ABI. I guess it is ok to
>> change it for radeon as there are so few users currently but the interface
>> has been in nouveau for multiple years already!
>>
> IIRC, I changed it in the same kernel as the original patch went in.
>
> Alex
Wonderful!
[PATCH 06/13] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
On 4/13/15 3:18 PM, Paulo Zanoni wrote:
> 2015-04-13 11:53 GMT-03:00 Todd Previte :
>> Displayport compliance test 4.2.2.6 requires that a source device be capable
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invalid checksum. To do this, the sink sets up an
>> invalid EDID header, expecting the source device to generate the checksum and
>> compare it to the value stored in the last byte of the block data.
>>
>> Unfortunately, the DRM EDID reading and parsing functions are actually too
>> good
>> in this case; the header is fixed before the checksum is computed and thus
>> the
>> code never sees the invalid checksum. This results in a failure to pass the
>> compliance test.
>>
>> To correct this issue, a checksum is generated when the EDID header is
>> detected
>> as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
>> logs the errors. In the case of a more seriously damaged header (fixup score
>> less than the threshold) the code does not generate the checksum but does set
>> the header_corrupt flag.
>>
>> V2:
>> - Removed the static bool global
>> - Added a bool to the drm_connector struct to reaplce the static one for
>>holding the status of raw edid header corruption detection
>> - Modified the function signature of the is_valid function to take an
>>additional parameter to store the corruption detected value
>> - Fixed the other callers of the above is_valid function
>> V3:
>> - Updated the commit message to be more clear about what and why this
>>patch does what it does.
>> - Added comment in code to clarify the operations there
>> - Removed compliance variable and check_link_status update; those
>>have been moved to a later patch
>> - Removed variable assignment from the bottom of the test handler
>> V4:
>> - Removed i915 tag from subject line as the patch is not i915-specific
>> V5:
>> - Moved code causing a compilation error to this patch where the variable
>>is actually declared
>>
>> Signed-off-by: Todd Previte
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>> drivers/gpu/drm/drm_edid.c| 31 ++-
>> drivers/gpu/drm/drm_edid_load.c | 7 +--
>> drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
>> drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> include/drm/drm_crtc.h| 8 +++-
>> 5 files changed, 41 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 53bc7a6..12e5be7 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1005,7 +1005,6 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
>> for (i = 0; i < sizeof(edid_header); i++)
>> if (raw_edid[i] == edid_header[i])
>> score++;
>> -
>> return score;
>> }
>> EXPORT_SYMBOL(drm_edid_header_is_valid);
> Bad chunk...
Fixed
>
>> @@ -1047,7 +1046,8 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
>> length)
>>*
>>* Return: True if the block is valid, false otherwise.
>>*/
>> -bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
>> +bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
>> + bool *header_corrupt)
> Need to add the new parameter description to the documentation above.
Done.
>
>> {
>> u8 csum;
>> struct edid *edid = (struct edid *)raw_edid;
>> @@ -1062,9 +1062,27 @@ bool drm_edid_block_valid(u8 *raw_edid, int block,
>> bool print_bad_edid)
>> int score = drm_edid_header_is_valid(raw_edid);
>> if (score == 8) ;
>> else if (score >= edid_fixup) {
>> + /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
>> +* In order to properly generate the invalid checksum
>> +* required for this test, it must be generated using
>> +* the raw EDID data. Otherwise, the fix-up code here
>> +* will correct the problem, the checksum is then
>> correct
>> +* and the test fails
>> +*/
>> + csum = drm_edid_block_checksum(raw_edid);
>> + if (csum) {
>> + DRM_DEBUG_DRIVER("Invalid EDID header, score
>> = %d\n", score);
>> + DRM_DEBUG_DRIVER("Invalid EDID checksum
>> %d\n", csum);
> No one on this file uses DRM_DEBUG_DRIVER (you use 2 calls here and one
> below).
>
> Also, during "normal operation" we try to calculate the checksum based
> on the fixed EDID header, so if we also print these messages here
> we're always going to have a message complaining about invalid
> checksum: either this one or the other that's already there. My
> bikeshed would be to just remove the messages you added here and below
> to not
