[PATCH v2] drm/exynos: release unhandled page flip events at postclose.
This patch resolves a dead lock issue that could be incurred when
exynos_drm_crtc_dpms function was called.
The exynos_drm_crtc_dpms function waits for the completion of pended
page flip events. However, preclose callback - this releases all unhandled
page flip events - is called prior to the exynos_drm_crtc_dpms function call
when drm is closed. So at this time, this will make the exynos_drm_crtc_dpms
to wait infiniately for the completion of the page flip events.
This patch releases the unhandled page flip events at postclose instead
of preclose so that exynos_drm_crtc_dpms function can be waked up.
Changelog v2:
- fix a memory leak when drm is closed.
. it has a memory leak when a requeste page flip is handled after
drm_events_release() is called and before drm_fb_release()
is called. At this time, a drm_pending_event will not be freed.
So also this chage releases the drm_pending_event at postclose().
And it calls drm_vblank_put() for pair if there is any unhandled page
flip event.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 35 +++
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index bb82ef7..1851860 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -173,28 +173,37 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
{
+ exynos_drm_subdrv_close(dev, file);
+}
+
+static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
+{
struct exynos_drm_private *private = dev->dev_private;
- struct drm_pending_vblank_event *e, *t;
+ struct drm_pending_vblank_event *v, *vt;
+ struct drm_pending_event *e, *et;
unsigned long flags;
- /* release events of current file */
+ if (!file->driver_priv)
+ return;
+
+ /* Release all events not unhandled by page flip handler. */
spin_lock_irqsave(&dev->event_lock, flags);
- list_for_each_entry_safe(e, t, &private->pageflip_event_list,
+ list_for_each_entry_safe(v, vt, &private->pageflip_event_list,
base.link) {
- if (e->base.file_priv == file) {
- list_del(&e->base.link);
- e->base.destroy(&e->base);
+ if (v->base.file_priv == file) {
+ list_del(&v->base.link);
+ drm_vblank_put(dev, v->pipe);
+ v->base.destroy(&v->base);
}
}
- spin_unlock_irqrestore(&dev->event_lock, flags);
- exynos_drm_subdrv_close(dev, file);
-}
+ /* Release all events handled by page flip handler but not freed. */
+ list_for_each_entry_safe(e, et, &file->event_list, link) {
+ list_del(&e->link);
+ e->destroy(e);
+ }
+ spin_unlock_irqrestore(&dev->event_lock, flags);
-static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
-{
- if (!file->driver_priv)
- return;
kfree(file->driver_priv);
file->driver_priv = NULL;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #139 from Bryan Quigley --- > Does it hang the entire system as soon as you load the driver, or only when > you start X or something like that? Hangs on driver load. > As for debugging, you can try disabling rv6xx_dpm_set_power_state() by > returning early (see the patch below). This doesn't work.. actually it seems to fail a bit faster now.. previously it would display kernel messages for a bit, not it goes off after extracting the kernel. I tried exiting early out of a few other functions like rv6xx_dpm_init, but haven't had any better results. I put a printk statement in _init, which never got printed.. Could we never make it there? I couldn't find anything that comes before _init... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
> -Original Message-
> From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
> ow...@vger.kernel.org] On Behalf Of Tomasz Figa
> Sent: Monday, September 30, 2013 8:13 AM
> To: Sylwester Nawrocki
> Cc: Inki Dae; Rahul Sharma; devicet...@vger.kernel.org; linux-samsung-soc;
> sw0312.kim; sunil joshi; dri-devel; kgene.kim; Shirish S; Sylwester
> Nawrocki; Rahul Sharma; Stephen Warren; Mark Rutland; Kumar Gala; Pawel
> Moll; Rob Herring; Sean Paul
> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
>
> On Monday 30 of September 2013 00:08:46 Sylwester Nawrocki wrote:
> > On 09/28/2013 06:10 PM, Inki Dae wrote:
> > >> Any opinion from Device-Tree folks?
> > >>
> > >> IMO, we should have same consensus on Shirish patches before
> > >> proceeding.>
> > > Rahul, it seems that DT people have no interest in this issue. So
> > > let's
> > > have a consensus about this issue internally.
> > >
> > > To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
> > > How about keeping hdmiphy config data in each board dts file?
> >
> > Please don't use HTML and quote only relevant part of e-mails. Otherwise
> > there are good chances your messages end up in people's spam box.
> >
> > It often helps to Cc a DT binding maintainer directly.
> >
> > Then, you consider moving the HDMI phy configuration to the device tree.
> > As Sean suggested in this thread:
> >
> > ">> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
>
> I'd like to only add that patches introducing or modifying a device tree
> binding need to be acked by at least one DT binding maintainer to be
> merged.
>
> > >> + {
> > >> + .pixel_clock = 2700,
> > >> + .conf = {
> > >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
> > >> 0x40,
> > >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
> > >> 0x87,
> > >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
> > >> 0xE0,
> > >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
> > >> 0x00,
> > >> + },
> > >> + },
> >
> > [trimmed couple more entries]
> >
> > >> +};
> > >
> > > Are you aware of the effort to move these to dt? Since these are
> > > board-specific values, it seems incorrect to apply them universally.
> > > Shirish has uploaded a patch to the chromium review site to push these
> > > into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
> > > you can work that into your patch set?"
> >
> > The configuration data is 64 bytes of the register values IIUC. Would it
> > be possible to figure out exact meaning of each byte ?
>
> This is definitely something that I would go for. Then for board specific
> data appropriate device tree properties could be defined, not just a
> binary blob.
>
Agree. Thanks for your opinion.
Thanks,
Inki Dae
> Best regards,
> Tomasz
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
> -Original Message-
> From: Sylwester Nawrocki [mailto:sylvester.nawro...@gmail.com]
> Sent: Monday, September 30, 2013 7:09 AM
> To: Inki Dae
> Cc: Rahul Sharma; devicet...@vger.kernel.org; linux-samsung-soc;
> sw0312.kim; sunil joshi; dri-devel; kgene.kim; Shirish S; Sylwester
> Nawrocki; Rahul Sharma; Stephen Warren; Mark Rutland; Kumar Gala; Pawel
> Moll; Rob Herring; Sean Paul
> Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
> driver
>
> On 09/28/2013 06:10 PM, Inki Dae wrote:
> >> Any opinion from Device-Tree folks?
> >>
> >> IMO, we should have same consensus on Shirish patches before
proceeding.
> >
> > Rahul, it seems that DT people have no interest in this issue. So let's
> > have a consensus about this issue internally.
> >
> > To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
> > How about keeping hdmiphy config data in each board dts file?
>
> Please don't use HTML and quote only relevant part of e-mails. Otherwise
> there are good chances your messages end up in people's spam box.
>
Ah, I missed checking text mode. Sorry about this. :)
> It often helps to Cc a DT binding maintainer directly.
>
Good idea.
> Then, you consider moving the HDMI phy configuration to the device tree.
> As Sean suggested in this thread:
>
Right.
> ">> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
> >> + {
> >> + .pixel_clock = 2700,
> >> + .conf = {
> >> + 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> >> + 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> >> + 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> >> + 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> >> + },
> >> + },
> [trimmed couple more entries]
> >> +};
> >>
> > Are you aware of the effort to move these to dt? Since these are
> > board-specific values, it seems incorrect to apply them universally.
> > Shirish has uploaded a patch to the chromium review site to push these
> > into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
> > you can work that into your patch set?"
>
> The configuration data is 64 bytes of the register values IIUC. Would it
> be
> possible to figure out exact meaning of each byte ? Do all of these bytes
Right, but the user manual doesn't describe that enough so we might need to
inquire for what it means to design team.
> need to be changed per board ? Perhaps we can have per SoC static tables
> in
> the PHY driver and be overwriting only some of the bytes with values read
> from device tree ?
>
> AFAIR firmware-like binary blobs (register address/value pairs) are not
> supposed to be stored in DT.
>
> If there is no detailed documentation for theese PHY configuration tables
> I guess there is no choice but to put these raw 64 bytes in DT. Presumably
> this should be a an required property defined only by board dts, since
> those
> values are PCB design dependent.
>
> However, if not all boards need tweaking this configuration data, then it
> could make sense to define recommended per-SoC tables in the driver and
> overwrite from DT only if it is specified there for a specific board.
> If we can come up with universal configuration for a SoC and selected
> pixel
> clock frequency then it could likely be better to store that in the driver
> rather than in DT.
>
Thanks you your opinion. However, we need to make sure how we take care of
the PHY configuration values. So I will have two steps to merge this pages
set.
To Rahul,
Could you post only your patch set regardless of Shirish's patch? I will
merge your patch set first because as is, Exynos drm hdmi driver is broken.
And, we need more discussions about Shirish patch. So I will not merge this
patch until we have a consensus about it.
To Shirish,
For your patch, it seems that you need to make sure to figure out exact
meaning of each byte of the PHY configuration values first. Maybe you need
to inquire for that to hardware or design team. And please separate the
values into common and specific parts if needed.
Thanks,
Inki Dae
> --
> Thanks,
> Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60639] RV635: Kernel displays black screen when monitor is connect via DisplayPort
https://bugzilla.kernel.org/show_bug.cgi?id=60639 --- Comment #12 from douglas_pe...@yahoo.com --- Has there been any progress on this? I am very near throwing money at the problem and buying an NVidea card. At least then I can plug in whichever brand currently has working drivers. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #10 from Alexandre Demers --- Just to be sure: vddc is associated only to sclk and vddci to mclk, right? Also, how are a new freq and a new voltage applied to the card? Are they applied simultanously or sequentially? In the second case, we must be sure to raise voltage before frequency when pushing the performances up, while we should low the frequency before lowering the voltage when we are slowing down. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69723] Computer freezes with kernel 3.11.0 / 3.12-rc1 (with bug 68235's patches applied) when dpm=1 on r600g (Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=69723 --- Comment #9 from Alexandre Demers --- Created attachment 86889 --> https://bugs.freedesktop.org/attachment.cgi?id=86889&action=edit dmesg with 3.12.0-rc3 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in Firefox and World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #5 from Jos van Wolput --- (In reply to comment #3) > Startng icedove/firefox with... This should be read 'Startng iceweasel' (Debian's Firefox), not icedove (Debian's Thunderbird). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in Firefox and World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Jos van Wolput changed: What|Removed |Added CC||wol...@onsneteindhoven.nl Summary|[r600g, bisected] Screen|[r600g, bisected] Screen |corruption in World of |corruption in Firefox and |Warcraft and Firefox|World of Warcraft -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in World of Warcraft and Firefox
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Jos van Wolput changed: What|Removed |Added Severity|major |critical Priority|high|medium -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in World of Warcraft and Firefox
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Jos van Wolput changed: What|Removed |Added Severity|normal |major -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in World of Warcraft and Firefox
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #4 from Jos van Wolput --- Created attachment 86888 --> https://bugs.freedesktop.org/attachment.cgi?id=86888&action=edit Xorg.log with errors -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in World of Warcraft and Firefox
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Jos van Wolput changed: What|Removed |Added Priority|medium |high Summary|[r600g, bisected] Screen|[r600g, bisected] Screen |corruption in World of |corruption in World of |Warcraft|Warcraft and Firefox --- Comment #3 from Jos van Wolput --- Startng icedove/firefox with OpenGL renderer string: Gallium 0.4 on AMD RS780 OpenGL version string: 2.1 Mesa 9.3.0-devel commit mesa-68f6dec32ed5eede361f76c8dbdf897652659baf (bisected) is causing a completely corrupted screen and xorg errors, making mesa unusable. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69942] driver fails to provide latency information
https://bugs.freedesktop.org/show_bug.cgi?id=69942 --- Comment #5 from fritz...@gmail.com --- $ uname -a Linux mythtv 3.11.2-1-ARCH #1 SMP PREEMPT Fri Sep 27 07:35:36 CEST 2013 x86_64 GNU/Linux Thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69942] driver fails to provide latency information
https://bugs.freedesktop.org/show_bug.cgi?id=69942 --- Comment #4 from fritz...@gmail.com --- Created attachment 86886 --> https://bugs.freedesktop.org/attachment.cgi?id=86886&action=edit xrandr --verbose output -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69942] driver fails to provide latency information
https://bugs.freedesktop.org/show_bug.cgi?id=69942 --- Comment #3 from fritz...@gmail.com --- Created attachment 86885 --> https://bugs.freedesktop.org/attachment.cgi?id=86885&action=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69942] driver fails to provide latency information
https://bugs.freedesktop.org/show_bug.cgi?id=69942 --- Comment #2 from fritz...@gmail.com --- Created attachment 86884 --> https://bugs.freedesktop.org/attachment.cgi?id=86884&action=edit dmesg output -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm/i915/dp: use drm_edid_duplicate
Did you compile or boot this? I get a warning since you are using edid
uninitialised, I guess you meant to duplicate intel_connector->edid.
Dave.
> drivers/gpu/drm/i915/intel_dp.c |8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 95a3159..aed9d67 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2920,18 +2920,12 @@ intel_dp_get_edid(struct drm_connector *connector,
> struct i2c_adapter *adapter)
> /* use cached edid if we have one */
> if (intel_connector->edid) {
> struct edid *edid;
> - int size;
>
> /* invalid edid */
> if (IS_ERR(intel_connector->edid))
> return NULL;
>
> - size = (intel_connector->edid->extensions + 1) * EDID_LENGTH;
> - edid = kmemdup(intel_connector->edid, size, GFP_KERNEL);
> - if (!edid)
> - return NULL;
> -
> - return edid;
> + return drm_edid_duplicate(edid);
> }
>
> return drm_get_edid(connector, adapter);
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/dpm: disable multiple UVD states
Always use the regular UVD state for now. This fixes
a performance regression with UVD playback on certain APUs.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_pm.c | 3 +++
drivers/gpu/drm/radeon/radeon_uvd.c | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index ac07ad1..4f6b7fc 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -945,6 +945,8 @@ void radeon_dpm_enable_uvd(struct radeon_device *rdev, bool
enable)
if (enable) {
mutex_lock(&rdev->pm.mutex);
rdev->pm.dpm.uvd_active = true;
+ /* disable this for now */
+#if 0
if ((rdev->pm.dpm.sd == 1) && (rdev->pm.dpm.hd == 0))
dpm_state = POWER_STATE_TYPE_INTERNAL_UVD_SD;
else if ((rdev->pm.dpm.sd == 2) && (rdev->pm.dpm.hd ==
0))
@@ -954,6 +956,7 @@ void radeon_dpm_enable_uvd(struct radeon_device *rdev, bool
enable)
else if ((rdev->pm.dpm.sd == 0) && (rdev->pm.dpm.hd ==
2))
dpm_state = POWER_STATE_TYPE_INTERNAL_UVD_HD2;
else
+#endif
dpm_state = POWER_STATE_TYPE_INTERNAL_UVD;
rdev->pm.dpm.state = dpm_state;
mutex_unlock(&rdev->pm.mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index a0f1185..4f2e73f 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -798,7 +798,8 @@ void radeon_uvd_note_usage(struct radeon_device *rdev)
(rdev->pm.dpm.hd != hd)) {
rdev->pm.dpm.sd = sd;
rdev->pm.dpm.hd = hd;
- streams_changed = true;
+ /* disable this for now */
+ /*streams_changed = true;*/
}
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #2 from Chris Rankin --- This is with a HD4890 (RV790). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] [r600g, bisected] Screen corruption in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=69983 --- Comment #1 from Chris Rankin --- Created attachment 86877 --> https://bugs.freedesktop.org/attachment.cgi?id=86877&action=edit screenshot attempting to show problem The corruption is of a flickering nature, which has made it difficult to capture. But you can hopefully see at least two little black squares which are definitely not supposed to be there. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69983] New: [r600g, bisected] Screen corruption in World of Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=69983 Priority: medium Bug ID: 69983 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g, bisected] Screen corruption in World of Warcraft Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ranki...@googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa This commit is causing a patchy line of tiny little squares across one of the main diagonals on the screen (bottom-left to top-right): 68f6dec32ed5eede361f76c8dbdf897652659baf is the first bad commit commit 68f6dec32ed5eede361f76c8dbdf897652659baf Author: Marek Olšák Date: Sun Sep 22 21:45:23 2013 +0200 r600g: move aux_context and r600_screen_clear_buffer to drivers/radeon This will be used in the next commit. :04 04 9aa99663b074853ed4d88a5229ff88dfe2e8a0c4 f55eac99d036675f814a0465bf4c8f1e368054bd Msrc -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/i915: destroy connector sysfs files earlier
On Thu, Sep 26, 2013 at 08:05:59PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> For some reason, every single time I try to run module_reload
> something tries to read the connector sysfs files. This happens
> after we destroy the encoders and before we destroy the connectors, so
> when the sysfs read triggers the connector detect() function,
> intel_conector->encoder points to memory that was already freed.
>
> The bad backtrace is just:
> [] dump_stack+0x54/0x74
> [] intel_dp_detect+0x1e/0x4b0 [i915]
> [] status_show+0x3d/0x80 [drm]
> [] dev_attr_show+0x20/0x60
> [] ? sysfs_read_file+0x80/0x1b0
> [] sysfs_read_file+0xa9/0x1b0
> [] vfs_read+0x9e/0x170
> [] SyS_read+0x4c/0xa0
> [] system_call_fastpath+0x16/0x1b
>
> But if you add tons of memory checking debug options to your Kernel
> you'll also see:
> - general protection fault:
> - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten
> - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915]
> - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915]
> Among a bunch of other error messages.
>
> So this commit just destroys the sysfs files before both the encoder
> and connectors are freed.
>
> Signed-off-by: Paulo Zanoni
Queued for -next, thanks for the patch. I'm unsure what to do with the
first patch, maybe Ville can take a look. For the next three patches to
wire up bind/unbind hooks I think the right approach would be to just
disallow the vgaconsole once drm/i915 is loaded:
- We don't want to even tighter integrate with the locking madness that is
fbcon.
- We want to kick out the vgacon anyway, even when e.g. fbcon isn't
loaded.
David Herrmann might have an idea how to solve this.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_crt.c | 1 -
> drivers/gpu/drm/i915/intel_display.c | 5 +
> drivers/gpu/drm/i915/intel_dp.c | 1 -
> drivers/gpu/drm/i915/intel_dsi.c | 1 -
> drivers/gpu/drm/i915/intel_dvo.c | 1 -
> drivers/gpu/drm/i915/intel_hdmi.c| 1 -
> drivers/gpu/drm/i915/intel_lvds.c| 1 -
> drivers/gpu/drm/i915/intel_sdvo.c| 7 +--
> drivers/gpu/drm/i915/intel_tv.c | 1 -
> 9 files changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_crt.c
> b/drivers/gpu/drm/i915/intel_crt.c
> index 0263629..942b9ac 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -677,7 +677,6 @@ intel_crt_detect(struct drm_connector *connector, bool
> force)
>
> static void intel_crt_destroy(struct drm_connector *connector)
> {
> - drm_sysfs_connector_remove(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 065ffed..793061f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10726,6 +10726,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc;
> + struct drm_connector *connector;
>
> /*
>* Interrupts and polling as the first thing to avoid creating havoc.
> @@ -10768,6 +10769,10 @@ void intel_modeset_cleanup(struct drm_device *dev)
> /* destroy backlight, if any, before the connectors */
> intel_panel_destroy_backlight(dev);
>
> + /* destroy the sysfs files before encoders/connectors */
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head)
> + drm_sysfs_connector_remove(connector);
> +
> drm_mode_config_cleanup(dev);
>
> intel_cleanup_overlay(dev);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 95a3159..7bdbb36 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3139,7 +3139,6 @@ intel_dp_connector_destroy(struct drm_connector
> *connector)
> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> intel_panel_fini(&intel_connector->panel);
>
> - drm_sysfs_connector_remove(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 674fd49..9a2fdd2 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -504,7 +504,6 @@ static void intel_dsi_destroy(struct drm_connector
> *connector)
>
> DRM_DEBUG_KMS("\n");
> intel_panel_fini(&intel_connector->panel);
> - drm_sysfs_connector_remove(connector);
> drm_connector_cleanup(connector);
> kfree(connector);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 91287d1..1b64145 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -367,7 +367,6 @@ static int intel_dvo_get_modes(struct drm_connecto
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #138 from Alex Deucher ---
(In reply to comment #137)
> Nope definitely not reliably, but I did have it work one more time doing the
> above (booting with modeset=0) after about 10 or so reboots. When it fails
> I've never been able to get any debug information..
>
> Any suggestions of other ways to get more debug information?
Does it hang the entire system as soon as you load the driver, or only when you
start X or something like that?
As for debugging, you can try disabling rv6xx_dpm_set_power_state() by
returning early (see the patch below). If that works, move the the return
statement further and further down in the function until you can identify at
which point in rv6xx_dpm_set_power_state() the hang occurs. Once we pin point
that, we can debug further.
diff --git a/drivers/gpu/drm/radeon/rv6xx_dpm.c
b/drivers/gpu/drm/radeon/rv6xx_dpm.c
index 5811d27..bfa2922 100644
--- a/drivers/gpu/drm/radeon/rv6xx_dpm.c
+++ b/drivers/gpu/drm/radeon/rv6xx_dpm.c
@@ -1670,6 +1670,8 @@ int rv6xx_dpm_set_power_state(struct radeon_device *rdev)
struct radeon_ps *old_ps = rdev->pm.dpm.current_ps;
int ret;
+ return 0;
+
pi->restricted_levels = 0;
rv6xx_set_uvd_clock_before_set_eng_clock(rdev, new_ps, old_ps);
@@ -2094,6 +2096,8 @@ int rv6xx_dpm_force_performance_level(struct
radeon_device *rdev,
{
struct rv6xx_power_info *pi = rv6xx_get_pi(rdev);
+ return 0;
+
if (level == RADEON_DPM_FORCED_LEVEL_HIGH) {
pi->restricted_levels = 3;
} else if (level == RADEON_DPM_FORCED_LEVEL_LOW) {
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space
Am 30.09.2013 14:19, schrieb Daniel Vetter: > On Mon, Sep 30, 2013 at 2:04 PM, Dieter N?tzel > wrote: >> Even so, I have no xorg.conf only /etc/X11/xorg.conf.d/ files. >> Which one should I create/change for testing, this? > > Just add the snippet I've pasted into a new file in xorg.conf.d and X > should pick it up and integrate it into the autodetected config. You > can check in the Xorg.log whether it worked out. > -Daniel OK, I guessed that... ...and put it in /etc/X11/xorg.conf.d/99-vblank.conf X picked it up [-] [43.333] (==) No Layout section. Using the first Screen section. [43.333] (**) |-->Screen "igd" (0) [43.333] (**) | |-->Monitor "" [43.338] (==) No monitor specified for screen "igd" [-] [43.583] (II) RADEON(0): Creating default Display subsection in Screen section "igd" for depth/fbbpp 24/32 [43.583] (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 [43.583] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [43.583] (==) RADEON(0): Default visual is TrueColor [43.588] (==) RADEON(0): RGB weight 888 [43.588] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [43.588] (--) RADEON(0): Chipset: "ATI Radeon HD 4600 Series" (ChipID = 0x9495) [-] But that didn't help, here. I've fiddled around with patching libvdpau-0.6 (the /etc/vdpau_wrapper.cfg thing, changing 'libflashplayer' to 'libgcflashplayer' from 2012, which is the only one that works a little with hardware acceleration on SSE1 systems), but that didn't help, here neither ;-((( Fu.. you ADOBE! Thanks, Dieter -- next part -- An embedded and charset-unspecified text was scrubbed... Name: Xorg.0.log URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130930/d5fa0127/attachment-0001.ksh>
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #137 from Bryan Quigley --- > (In reply to comment #135) > Seems like you just got lucky this time. Does it work reliably if you > disable radeon and boot into a non-X runlevel, then manually load radeon? Nope definitely not reliably, but I did have it work one more time doing the above (booting with modeset=0) after about 10 or so reboots. When it fails I've never been able to get any debug information.. Any suggestions of other ways to get more debug information? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/i915: Plane rotation support
On Mon, Sep 30, 2013 at 08:21:33PM +0200, Daniel Vetter wrote: > On Mon, Sep 30, 2013 at 7:46 PM, Rob Clark wrote: > > I guess the main thing I care about is that we don't advertise things > > to userspace that we can't actually do. I'm not sure what other hw > > out there supports rotation in hw in some form or another, but it > > might be a good time to hear from 'em about whether these property > > values work for them or not. > > Hm, I've thought the plan was to let userspace figure that out with a > dry-run flag, and if a certain configuration doesn't work it needs to > fall back to rendering-based compositioning for the given surface. I > don't think there's really much more we can do for fully generic > compositors. Yeah, if no one comes up with anything better, the trial and error approach is the plan in my mind. But in case the hardware never ever supports certain property/value I think we shouldn't expose it. Like 90/270 degree rotation in case of intel hardware. > Tha might leave strange hw in the dust where planes aren't symmetric > in capabilities and hence a simple linear walk over surfaces/planes, > ordered by bw-savings or so, yields extermely bad surface->plane > assignements. But my impression is that hw is moving to unified > stacks of planes so I hope we can punt on solving this in a generic > way (and resort to quick platform hacks in userspace where it's really > needed to hit e.g. video playback power targets). Right. If someone has really specific needs I think they can just go and write their own compositor (or plugin if the compositor in question has such things). -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/i915: Plane rotation support
On Mon, Sep 30, 2013 at 01:46:11PM -0400, Rob Clark wrote: > On Mon, Sep 30, 2013 at 1:09 PM, Ville Syrjälä > wrote: > > On Mon, Sep 30, 2013 at 12:15:06PM -0400, Rob Clark wrote: > >> On Mon, Sep 30, 2013 at 10:44 AM, wrote: > >> > Recently some people from inside Intel have showed some interest in 180 > >> > degree plane rotation. To avoid a huge mess, I decided that I should > >> > implement the feature properly. > >> > > >> > So I snatched the rotation property from omapdrm, and moved some of the > >> > code into drm_crtc.c, added a bunch of helper stuff to drm_crtc/rect > >> > and implemented the relevant bits in i915. I didn't touch cursor or > >> > primary planes at all. I'm sort of hoping we might do the drm_plane > >> > conversion sometime soonish and then we'd avoid adding a bunch of > >> > plane properties to the crtc. > >> > >> fwiw, I was leaning towards introducing primary-plane's visible to > >> userspace after we have atomic modeset (or really, the > >> propertyification associated with atomic modeset). > > > > Less burden of maintaining all the crtc properties if we convert to > > drm_plane first. > > > >> > >> But that should be independent of drm_plane conversion. You probably > >> still want to do something like what I did in omapdrm where you attach > >> plane properties on the crtc as well for benefit of old userspace. > > > > Dunno. There's no old userspace that would use this. There are some > > folks inside Intel who apparently want rotation for some thing, but > > I was thinking I'd let them add the properties on the crtc and not > > upstream any of that. > > for properties that aren't actually handled by the crtc, just make > your crtc_set_prop() call: > > intel_plane_set_property(intel_crtc->plane, property, val) > > (or something roughly like that) Sure it's doable, but I tend to think it's rather pointless since we don't have any legacy userspace to worry about yet. > >> > >> > One thing I don't really like is the current way of stuffing the bit > >> > number into the enum_list resulting in DRM_ROTATE_FOO being just the bit > >> > number. I'd prefer to make DRM_ROTATE_FOO the shifted bitmask. But I'm > >> > not sure if changing that would cause grief to userspace, so I left it > >> > alone for now. > >> > >> I think this shouldn't be visible to userspace. If I remember > >> correctly, I just did it this way to make it easier to prevent users > >> of bitmask property from doing the wrong thing (setting multiple bits, > >> overlapping bitmask values, etc). > > > > Well setting multiple bits should be allowed. If it's not we need to fix > > it since rotation+reflection sure needs it. Or did you mean users as in > > driver code in the kernel which registers the bitmask prop? > > yeah, setting multiple bits is allowed.. this is why it isn't an enum > property ;-) > > I meant users as in driver code rather than userspace. I guess that > was worded a bit confusingly. I blame the cough syrup. Right. > > > I also just had an idea to expose color keys, bg colors, etc. as bitmask > > props where each channel is represented by a multi-bit mask, and the > > whole thing is just one bitmask prop. That would expose some structure > > to userspace w/o need a new prop type. But maybe we want a specialized > > type for color props for extra clarty. > > hmm.. should the values be interpreted in terms of current attached fb format? My current thinking is to go with a fixed 16 bits per channel, and just throw away any low bits you don't need. > > >> > >> Anyways, from a really quick look, the core and omapdrm parts look good. > >> > >> The drm_rotation_simplify() might be overkill.. or at least userspace > >> should see what are the supported bitmask flags and not try to ask for > >> something that is not supported. Or am I missing something? > > > > My main idea was that, for example if the hardware support X and Y > > reflection, > > we can expose both 0 and 180 angles and X and Y reflection, and the driver > > code can then do the simplification to elimnate the 180 degree case. So it's > > just a convenience tool for the driver authors to eliminate the redundant > > information. I didn't actually end up using it in i915 since we really > > don't support anything but 0 and 180 cases, and advertising anything > > else to userspace would be a bad idea. > > oh, right.. we do have some redundancy in rotation values. Maybe we > should have stuck with xyflip/yinvert/xinvert (which was how the omap > hw worked.. but seemed a bit too hw specific). That's omap4 or omap5 i take it. Omap3 had 0,90,180,270 + x mirror for DMA rotation, and 0+90+180+270 + y mirror for VRFB. The mismatch was interesting since omap angle was clockwise, randr counter-clockwise, and omap mirroring was post-rotation, randr pre-rotation. Also the xyflip/etc. is just confusing to me, so I'm happy you went with randr compatible specification rather than whatever your hw had. > I guess the main thing I ca
Re: [PATCH 0/9] drm/i915: Plane rotation support
On Mon, Sep 30, 2013 at 7:46 PM, Rob Clark wrote: > I guess the main thing I care about is that we don't advertise things > to userspace that we can't actually do. I'm not sure what other hw > out there supports rotation in hw in some form or another, but it > might be a good time to hear from 'em about whether these property > values work for them or not. Hm, I've thought the plan was to let userspace figure that out with a dry-run flag, and if a certain configuration doesn't work it needs to fall back to rendering-based compositioning for the given surface. I don't think there's really much more we can do for fully generic compositors. Tha might leave strange hw in the dust where planes aren't symmetric in capabilities and hence a simple linear walk over surfaces/planes, ordered by bw-savings or so, yields extermely bad surface->plane assignements. But my impression is that hw is moving to unified stacks of planes so I hope we can punt on solving this in a generic way (and resort to quick platform hacks in userspace where it's really needed to hit e.g. video playback power targets). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/i915: Plane rotation support
On Mon, Sep 30, 2013 at 1:09 PM, Ville Syrjälä wrote: > On Mon, Sep 30, 2013 at 12:15:06PM -0400, Rob Clark wrote: >> On Mon, Sep 30, 2013 at 10:44 AM, wrote: >> > Recently some people from inside Intel have showed some interest in 180 >> > degree plane rotation. To avoid a huge mess, I decided that I should >> > implement the feature properly. >> > >> > So I snatched the rotation property from omapdrm, and moved some of the >> > code into drm_crtc.c, added a bunch of helper stuff to drm_crtc/rect >> > and implemented the relevant bits in i915. I didn't touch cursor or >> > primary planes at all. I'm sort of hoping we might do the drm_plane >> > conversion sometime soonish and then we'd avoid adding a bunch of >> > plane properties to the crtc. >> >> fwiw, I was leaning towards introducing primary-plane's visible to >> userspace after we have atomic modeset (or really, the >> propertyification associated with atomic modeset). > > Less burden of maintaining all the crtc properties if we convert to > drm_plane first. > >> >> But that should be independent of drm_plane conversion. You probably >> still want to do something like what I did in omapdrm where you attach >> plane properties on the crtc as well for benefit of old userspace. > > Dunno. There's no old userspace that would use this. There are some > folks inside Intel who apparently want rotation for some thing, but > I was thinking I'd let them add the properties on the crtc and not > upstream any of that. for properties that aren't actually handled by the crtc, just make your crtc_set_prop() call: intel_plane_set_property(intel_crtc->plane, property, val) (or something roughly like that) >> >> > One thing I don't really like is the current way of stuffing the bit >> > number into the enum_list resulting in DRM_ROTATE_FOO being just the bit >> > number. I'd prefer to make DRM_ROTATE_FOO the shifted bitmask. But I'm >> > not sure if changing that would cause grief to userspace, so I left it >> > alone for now. >> >> I think this shouldn't be visible to userspace. If I remember >> correctly, I just did it this way to make it easier to prevent users >> of bitmask property from doing the wrong thing (setting multiple bits, >> overlapping bitmask values, etc). > > Well setting multiple bits should be allowed. If it's not we need to fix > it since rotation+reflection sure needs it. Or did you mean users as in > driver code in the kernel which registers the bitmask prop? yeah, setting multiple bits is allowed.. this is why it isn't an enum property ;-) I meant users as in driver code rather than userspace. I guess that was worded a bit confusingly. I blame the cough syrup. > I also just had an idea to expose color keys, bg colors, etc. as bitmask > props where each channel is represented by a multi-bit mask, and the > whole thing is just one bitmask prop. That would expose some structure > to userspace w/o need a new prop type. But maybe we want a specialized > type for color props for extra clarty. hmm.. should the values be interpreted in terms of current attached fb format? >> >> Anyways, from a really quick look, the core and omapdrm parts look good. >> >> The drm_rotation_simplify() might be overkill.. or at least userspace >> should see what are the supported bitmask flags and not try to ask for >> something that is not supported. Or am I missing something? > > My main idea was that, for example if the hardware support X and Y reflection, > we can expose both 0 and 180 angles and X and Y reflection, and the driver > code can then do the simplification to elimnate the 180 degree case. So it's > just a convenience tool for the driver authors to eliminate the redundant > information. I didn't actually end up using it in i915 since we really > don't support anything but 0 and 180 cases, and advertising anything > else to userspace would be a bad idea. oh, right.. we do have some redundancy in rotation values. Maybe we should have stuck with xyflip/yinvert/xinvert (which was how the omap hw worked.. but seemed a bit too hw specific). I guess the main thing I care about is that we don't advertise things to userspace that we can't actually do. I'm not sure what other hw out there supports rotation in hw in some form or another, but it might be a good time to hear from 'em about whether these property values work for them or not. BR, -R > -- > Ville Syrjälä > Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 6/6] drm/nouveau: use MSI interrupts
On 09/03/2013 09:45 PM, Ben Skeggs wrote:
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach wrote:
Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/nouveau/core/include/subdev/mc.h | 1 +
drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+ bool use_msi;
};
static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
*/
#include
+#include
static irqreturn_t
nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
+ if (pmc->use_msi)
+ nv_wr08(pmc->base.base.parent, 0x00088068, 0xff);
Register not present everywhere.
At the very least, the enabling of MSI should be disallowed on the
earlier chipsets where it's not supported. Though, it's perhaps
possible that the pci_enable_msi() call will fail in all of these
cases anyway.. I'm not certain.
MSIs are required property for everything doing PCIe. So the only cases
where this should fail is plain PCI/AGP devices. I don't really have a
test system for those old cards set up.
But I remember Ilia having some legacy things plugged in, so maybe he
could test this patch and see how it goes?
Sure, let me know what you need -- I have nv18 PCI, nv34 PCIe (note
that it's not native PCIe, but some sort of bridge thing IIRC),
Cases like the nv34 here (i think there's some nv4x that aren't native
pcie too) are what I'm wondering about primarily.
And rightly so. With the NV18 PCI, NV34 PCIe, NV42 PCIe plugged in,
with "AutoAddGPU" disabled the NV18 and NV42 seem fine. However merely
starting X (not xinit, not startx, not [gkx]dm) on the NV34 and ^C'ing
it (with no clients connecting to said X), causes a "failed to idle
channel" message in dmesg, which apparently never rectifies itself, so
X is hung forever. FTR, there were no displays connected either, but I
tried the exact same procedure without the MSI patch and it worked
fine. Here is the init sequence with the MSI patch:
I don't suppose bashing 0x1868 instead of 0x88068 works here? If not,
Should that work on the NV42 as well?
I believe so. NV4x has both the 0x18xx and 0x88xxx apertures I believe.
next thing would be to mmiotrace the binary driver and see if you can
make it enable+use MSI on it. I doubt the current legacy driver does
it by default, but there was some magic to enable it that you can
probably find if you google around.
I've yet to set up the legacy driver... I bet it doesn't compile on
3.11, so I'll have to patch it to nuke procfs/i2c...
[ 307.049812] nouveau [ DEVICE][:04:00.0] BOOT0 : 0x034a00b1
[ 307.049815] nouveau [ DEVICE][:04:00.0] Chipset: NV34 (NV34)
[ 307.049819] nouveau [ DEVICE][:04:00.0] Family : NV30
[ 307.050648] nouveau [ VBIOS][:04:00.0] checking PRAMIN for image...
[ 307.050652] nouveau [ VBIOS][:04:00.0] ... signature not found
[ 307.050653] nouveau [ VBIOS][:04:00.0] checking PROM for image...
[ 307.195201] nouveau [ VBIOS][:04:00.0] ... appears to be valid
[ 307.195205] nouveau [ VBIOS][:04:00.0] using image from PROM
[ 307.195209] nouveau [ VBIOS][:04:00.0] BMP version 5.29
[ 307.195429] nouveau [ VBIOS][:04:00.0] version 04.34.20.79.00
[ 307.195971] nouveau [ DEVINIT][:04:00.0] adaptor not initialised
[ 307.195979] nouveau [ VBIOS][:04:00.0] running init tables
[ 307.209253] nouveau :04
[Bug 67111] [radeonsi] GPU lockup while playing Serious Sam 3
https://bugs.freedesktop.org/show_bug.cgi?id=67111 Vladimir Ysikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Vladimir Ysikov --- I checked several times and gpu lockup does not happen again. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/i915: Plane rotation support
On Mon, Sep 30, 2013 at 12:15:06PM -0400, Rob Clark wrote: > On Mon, Sep 30, 2013 at 10:44 AM, wrote: > > Recently some people from inside Intel have showed some interest in 180 > > degree plane rotation. To avoid a huge mess, I decided that I should > > implement the feature properly. > > > > So I snatched the rotation property from omapdrm, and moved some of the > > code into drm_crtc.c, added a bunch of helper stuff to drm_crtc/rect > > and implemented the relevant bits in i915. I didn't touch cursor or > > primary planes at all. I'm sort of hoping we might do the drm_plane > > conversion sometime soonish and then we'd avoid adding a bunch of > > plane properties to the crtc. > > fwiw, I was leaning towards introducing primary-plane's visible to > userspace after we have atomic modeset (or really, the > propertyification associated with atomic modeset). Less burden of maintaining all the crtc properties if we convert to drm_plane first. > > But that should be independent of drm_plane conversion. You probably > still want to do something like what I did in omapdrm where you attach > plane properties on the crtc as well for benefit of old userspace. Dunno. There's no old userspace that would use this. There are some folks inside Intel who apparently want rotation for some thing, but I was thinking I'd let them add the properties on the crtc and not upstream any of that. > > > One thing I don't really like is the current way of stuffing the bit > > number into the enum_list resulting in DRM_ROTATE_FOO being just the bit > > number. I'd prefer to make DRM_ROTATE_FOO the shifted bitmask. But I'm > > not sure if changing that would cause grief to userspace, so I left it > > alone for now. > > I think this shouldn't be visible to userspace. If I remember > correctly, I just did it this way to make it easier to prevent users > of bitmask property from doing the wrong thing (setting multiple bits, > overlapping bitmask values, etc). Well setting multiple bits should be allowed. If it's not we need to fix it since rotation+reflection sure needs it. Or did you mean users as in driver code in the kernel which registers the bitmask prop? I also just had an idea to expose color keys, bg colors, etc. as bitmask props where each channel is represented by a multi-bit mask, and the whole thing is just one bitmask prop. That would expose some structure to userspace w/o need a new prop type. But maybe we want a specialized type for color props for extra clarty. > > Anyways, from a really quick look, the core and omapdrm parts look good. > > The drm_rotation_simplify() might be overkill.. or at least userspace > should see what are the supported bitmask flags and not try to ask for > something that is not supported. Or am I missing something? My main idea was that, for example if the hardware support X and Y reflection, we can expose both 0 and 180 angles and X and Y reflection, and the driver code can then do the simplification to elimnate the 180 degree case. So it's just a convenience tool for the driver authors to eliminate the redundant information. I didn't actually end up using it in i915 since we really don't support anything but 0 and 180 cases, and advertising anything else to userspace would be a bad idea. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] drm/i915: Plane rotation support
On Mon, Sep 30, 2013 at 10:44 AM, wrote: > Recently some people from inside Intel have showed some interest in 180 > degree plane rotation. To avoid a huge mess, I decided that I should > implement the feature properly. > > So I snatched the rotation property from omapdrm, and moved some of the > code into drm_crtc.c, added a bunch of helper stuff to drm_crtc/rect > and implemented the relevant bits in i915. I didn't touch cursor or > primary planes at all. I'm sort of hoping we might do the drm_plane > conversion sometime soonish and then we'd avoid adding a bunch of > plane properties to the crtc. fwiw, I was leaning towards introducing primary-plane's visible to userspace after we have atomic modeset (or really, the propertyification associated with atomic modeset). But that should be independent of drm_plane conversion. You probably still want to do something like what I did in omapdrm where you attach plane properties on the crtc as well for benefit of old userspace. > One thing I don't really like is the current way of stuffing the bit > number into the enum_list resulting in DRM_ROTATE_FOO being just the bit > number. I'd prefer to make DRM_ROTATE_FOO the shifted bitmask. But I'm > not sure if changing that would cause grief to userspace, so I left it > alone for now. I think this shouldn't be visible to userspace. If I remember correctly, I just did it this way to make it easier to prevent users of bitmask property from doing the wrong thing (setting multiple bits, overlapping bitmask values, etc). Anyways, from a really quick look, the core and omapdrm parts look good. The drm_rotation_simplify() might be overkill.. or at least userspace should see what are the supported bitmask flags and not try to ask for something that is not supported. Or am I missing something? BR, -R > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69942] driver fails to provide latency information
https://bugs.freedesktop.org/show_bug.cgi?id=69942 Alex Deucher changed: What|Removed |Added Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon --- Comment #1 from Alex Deucher --- Please attach your xorg log, xrandr --verbose output and dmesg output. Also what kernel are you using? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #21 from Alex Deucher --- (In reply to comment #19) > > Subject: [PATCH 3/3] drm/radeon: use hw generated CTS/N values for audio > > Just checking: What N value does the Hw use in that mode? The ones written > in by the driver, some hardcoded N or does it select one on its own? Though > it doesn't really matter much (since any reasonable N should work as long as > CTS is correct), except that if it uses the driver-set value we better not > remove the write to the N register :) It's my understanding that the hw generates the CTS and N values directly, but I would need to double check with the hw teams. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 Alex Deucher changed: What|Removed |Added Attachment #86739|0 |1 is obsolete|| --- Comment #20 from Alex Deucher --- Created attachment 86856 --> https://bugs.freedesktop.org/attachment.cgi?id=86856&action=edit patch 1/3 Updated 1/3. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/i915: Add rotation property for sprites
From: Ville Syrjälä
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_sprite.c | 42 -
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08e96a8..48d4d5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1356,6 +1356,7 @@ typedef struct drm_i915_private {
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+ struct drm_property *rotation_property;
bool hw_contexts_disabled;
uint32_t hw_context_size;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 028a979..49f8238 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1033,6 +1033,30 @@ out_unlock:
return ret;
}
+static int intel_plane_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct drm_i915_private *dev_priv = plane->dev->dev_private;
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ uint64_t old_val;
+ int ret = -ENOENT;
+
+ if (prop == dev_priv->rotation_property) {
+ /* exactly one rotation angle please */
+ if (hweight32(val & 0xf) != 1)
+ return -EINVAL;
+
+ old_val = intel_plane->rotation;
+ intel_plane->rotation = val;
+ ret = intel_plane_restore(plane);
+ if (ret)
+ intel_plane->rotation = old_val;
+ }
+
+ return ret;
+}
+
int intel_plane_restore(struct drm_plane *plane)
{
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -1059,6 +1083,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = intel_update_plane,
.disable_plane = intel_disable_plane,
.destroy = intel_destroy_plane,
+ .set_property = intel_plane_set_property,
};
static uint32_t ilk_plane_formats[] = {
@@ -1095,6 +1120,7 @@ static uint32_t vlv_plane_formats[] = {
int
intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_plane *intel_plane;
unsigned long possible_crtcs;
const uint32_t *plane_formats;
@@ -1168,8 +1194,22 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe,
int plane)
&intel_plane_funcs,
plane_formats, num_plane_formats,
false);
- if (ret)
+ if (ret) {
kfree(intel_plane);
+ goto out;
+ }
+
+ if (!dev_priv->rotation_property)
+ dev_priv->rotation_property =
+ drm_mode_create_rotation_property(dev,
+ BIT(DRM_ROTATE_0) |
+ BIT(DRM_ROTATE_180));
+
+ if (dev_priv->rotation_property)
+ drm_object_attach_property(&intel_plane->base.base,
+ dev_priv->rotation_property,
+ intel_plane->rotation);
+ out:
return ret;
}
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/i915: Make intel_plane_restore() return an error
From: Ville Syrjälä
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 89282d5..bfa558a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -818,7 +818,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob);
int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
void intel_flush_display_plane(struct drm_i915_private *dev_priv,
enum plane plane);
-void intel_plane_restore(struct drm_plane *plane);
+int intel_plane_restore(struct drm_plane *plane);
void intel_plane_disable(struct drm_plane *plane);
int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c0081f0..028a979 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1033,18 +1033,18 @@ out_unlock:
return ret;
}
-void intel_plane_restore(struct drm_plane *plane)
+int intel_plane_restore(struct drm_plane *plane)
{
struct intel_plane *intel_plane = to_intel_plane(plane);
if (!plane->crtc || !plane->fb)
- return;
+ return 0;
- intel_update_plane(plane, plane->crtc, plane->fb,
- intel_plane->crtc_x, intel_plane->crtc_y,
- intel_plane->crtc_w, intel_plane->crtc_h,
- intel_plane->src_x, intel_plane->src_y,
- intel_plane->src_w, intel_plane->src_h);
+ return intel_update_plane(plane, plane->crtc, plane->fb,
+ intel_plane->crtc_x, intel_plane->crtc_y,
+ intel_plane->crtc_w, intel_plane->crtc_h,
+ intel_plane->src_x, intel_plane->src_y,
+ intel_plane->src_w, intel_plane->src_h);
}
void intel_plane_disable(struct drm_plane *plane)
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] drm/i915: Add 180 degree sprite rotation support
From: Ville Syrjälä
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_sprite.c | 34 ++
3 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96fd2ce..ca5cc60 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3518,6 +3518,7 @@
#define DVS_YUV_ORDER_UYVY (1<<16)
#define DVS_YUV_ORDER_YVYU (2<<16)
#define DVS_YUV_ORDER_VYUY (3<<16)
+#define DVS_ROTATE_180 (1<<15)
#define DVS_DEST_KEY (1<<2)
#define DVS_TRICKLE_FEED_DISABLE (1<<14)
#define DVS_TILED(1<<10)
@@ -3588,6 +3589,7 @@
#define SPRITE_YUV_ORDER_UYVY(1<<16)
#define SPRITE_YUV_ORDER_YVYU(2<<16)
#define SPRITE_YUV_ORDER_VYUY(3<<16)
+#define SPRITE_ROTATE_180(1<<15)
#define SPRITE_TRICKLE_FEED_DISABLE (1<<14)
#define SPRITE_INT_GAMMA_ENABLE (1<<13)
#define SPRITE_TILED (1<<10)
@@ -3661,6 +3663,7 @@
#define SP_YUV_ORDER_UYVY(1<<16)
#define SP_YUV_ORDER_YVYU(2<<16)
#define SP_YUV_ORDER_VYUY(3<<16)
+#define SP_ROTATE_180(1<<15)
#define SP_TILED (1<<10)
#define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
#define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9364d98..89282d5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -370,6 +370,7 @@ struct intel_plane {
unsigned int crtc_w, crtc_h;
uint32_t src_x, src_y;
uint32_t src_w, src_h;
+ unsigned int rotation;
/* Since we need to change the watermarks before/after
* enabling/disabling the planes, we need to store the parameters here
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f86caba..c0081f0 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -60,6 +60,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc
*crtc,
sprctl &= ~SP_PIXFORMAT_MASK;
sprctl &= ~SP_YUV_BYTE_ORDER_MASK;
sprctl &= ~SP_TILED;
+ sprctl &= ~SP_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_YUYV:
@@ -128,6 +129,14 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc
*crtc,
fb->pitches[0]);
linear_offset -= sprsurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ sprctl |= SP_ROTATE_180;
+
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w * pixel_size;
+ }
+
if (obj->tiling_mode != I915_TILING_NONE)
I915_WRITE(SPTILEOFF(pipe, plane), (y << 16) | x);
else
@@ -233,6 +242,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
sprctl &= ~SPRITE_RGB_ORDER_RGBX;
sprctl &= ~SPRITE_YUV_BYTE_ORDER_MASK;
sprctl &= ~SPRITE_TILED;
+ sprctl &= ~SPRITE_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_XBGR:
@@ -304,6 +314,14 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
pixel_size, fb->pitches[0]);
linear_offset -= sprsurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ sprctl |= SPRITE_ROTATE_180;
+
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w * pixel_size;
+ }
+
/* HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
* register */
if (IS_HASWELL(dev))
@@ -429,6 +447,7 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
dvscntr &= ~DVS_RGB_ORDER_XBGR;
dvscntr &= ~DVS_YUV_BYTE_ORDER_MASK;
dvscntr &= ~DVS_TILED;
+ dvscntr &= ~DVS_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_XBGR:
@@ -482,6 +501,14 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
pixel_size, fb->pitches[0]);
linear_offset -= dvssurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ dvscntr |= DVS_ROTATE_180;
+
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w * pixel_size;
+ }
+
[PATCH 2/9] drm: Add support_bits parameter to drm_property_create_bitmask()
From: Ville Syrjälä
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 6 +-
include/drm/drm_crtc.h | 3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d7a8370..2087fe2 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2883,7 +2883,8 @@ EXPORT_SYMBOL(drm_property_create_enum);
struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
int flags, const char *name,
const struct drm_prop_enum_list *props,
-int num_values)
+int num_values,
+unsigned int supported_bits)
{
struct drm_property *property;
int i, ret;
@@ -2895,6 +2896,9 @@ struct drm_property *drm_property_create_bitmask(struct
drm_device *dev,
return NULL;
for (i = 0; i < num_values; i++) {
+ if (!(supported_bits & (1 << i)))
+ continue;
+
ret = drm_property_add_enum(property, i,
props[i].type,
props[i].name);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7aec9f4..196b795 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1041,7 +1041,8 @@ extern struct drm_property
*drm_property_create_enum(struct drm_device *dev, int
struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
int flags, const char *name,
const struct drm_prop_enum_list *props,
-int num_values);
+int num_values,
+unsigned int supported_bits);
struct drm_property *drm_property_create_range(struct drm_device *dev, int
flags,
const char *name,
uint64_t min, uint64_t max);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm: Add drm_mode_create_rotation_property()
From: Ville Syrjälä
Add a function to create a standards compliant rotation property.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 18 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2087fe2..0218681 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4088,3 +4088,21 @@ void drm_mode_config_cleanup(struct drm_device *dev)
idr_destroy(&dev->mode_config.crtc_idr);
}
EXPORT_SYMBOL(drm_mode_config_cleanup);
+
+struct drm_property *drm_mode_create_rotation_property(struct drm_device *dev,
+ unsigned int
supported_rotations)
+{
+ static const struct drm_prop_enum_list props[] = {
+ { DRM_ROTATE_0, "rotate-0" },
+ { DRM_ROTATE_90, "rotate-90" },
+ { DRM_ROTATE_180, "rotate-180" },
+ { DRM_ROTATE_270, "rotate-270" },
+ { DRM_REFLECT_X, "reflect-x" },
+ { DRM_REFLECT_Y, "reflect-y" },
+ };
+
+ return drm_property_create_bitmask(dev, 0, "rotation",
+ props, ARRAY_SIZE(props),
+ supported_rotations);
+}
+EXPORT_SYMBOL(drm_mode_create_rotation_property);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 196b795..d25ba84 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1152,5 +1152,7 @@ extern int drm_format_plane_cpp(uint32_t format, int
plane);
extern int drm_format_horz_chroma_subsampling(uint32_t format);
extern int drm_format_vert_chroma_subsampling(uint32_t format);
extern const char *drm_get_format_name(uint32_t format);
+extern struct drm_property *drm_mode_create_rotation_property(struct
drm_device *dev,
+ unsigned int
supported_rotations);
#endif /* __DRM_CRTC_H__ */
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
From: Ville Syrjälä
Use the new drm_mode_create_rotation_property() in omapdrm.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/omapdrm/omap_plane.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 046d5e6..fee8f35 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -300,16 +300,13 @@ void omap_plane_install_properties(struct drm_plane
*plane,
if (priv->has_dmm) {
prop = priv->rotation_prop;
if (!prop) {
- const struct drm_prop_enum_list props[] = {
- { DRM_ROTATE_0, "rotate-0" },
- { DRM_ROTATE_90, "rotate-90" },
- { DRM_ROTATE_180, "rotate-180" },
- { DRM_ROTATE_270, "rotate-270" },
- { DRM_REFLECT_X, "reflect-x" },
- { DRM_REFLECT_Y, "reflect-y" },
- };
- prop = drm_property_create_bitmask(dev, 0, "rotation",
- props, ARRAY_SIZE(props));
+ prop = drm_mode_create_rotation_property(dev,
+
BIT(DRM_ROTATE_0) |
+
BIT(DRM_ROTATE_90) |
+
BIT(DRM_ROTATE_180) |
+
BIT(DRM_ROTATE_270) |
+
BIT(DRM_REFLECT_X) |
+
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv->rotation_prop = prop;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm: Move DRM_ROTATE bits out of omapdrm into drm_crtc.h
From: Ville Syrjälä
The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/omapdrm/omap_drv.h | 7 ---
include/drm/drm_crtc.h | 8
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
b/drivers/gpu/drm/omapdrm/omap_drv.h
index 30b95b7..dfe0beb 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.h
+++ b/drivers/gpu/drm/omapdrm/omap_drv.h
@@ -119,13 +119,6 @@ struct omap_drm_private {
struct omap_drm_irq error_handler;
};
-/* this should probably be in drm-core to standardize amongst drivers */
-#define DRM_ROTATE_0 0
-#define DRM_ROTATE_90 1
-#define DRM_ROTATE_180 2
-#define DRM_ROTATE_270 3
-#define DRM_REFLECT_X 4
-#define DRM_REFLECT_Y 5
#ifdef CONFIG_DEBUG_FS
int omap_debugfs_init(struct drm_minor *minor);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 50cedad..7aec9f4 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -64,6 +64,14 @@ struct drm_object_properties {
uint64_t values[DRM_OBJECT_MAX_PROPERTY];
};
+/* rotation property bits */
+#define DRM_ROTATE_0 0
+#define DRM_ROTATE_90 1
+#define DRM_ROTATE_180 2
+#define DRM_ROTATE_270 3
+#define DRM_REFLECT_X 4
+#define DRM_REFLECT_Y 5
+
/*
* Note on terminology: here, for brevity and convenience, we refer to
connector
* control chips as 'CRTCs'. They can control any type of connector, VGA,
LVDS,
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/9] drm: Add drm_rotation_simplify()
From: Ville Syrjälä
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope is
that this identity transform will eliminate the unsupported flags.
Of course that might not result in any more supported rotation, so
the caller is still responsible for checking the result afterwards.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 30 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0218681..665b807 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3976,6 +3976,36 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
/**
+ * drm_rotation_simplify() - Try to simplify the rotation
+ * @rotation: Rotation to be simplified
+ * @supported_rotations: Supported rotations
+ *
+ * Attempt to simplify the rotation to a form that is supported.
+ * Eg. if the hardware supports everything except DRM_REFLECT_X
+ * one could call this function like this:
+ *
+ * drm_rotation_simplify(rotation, BIT(DRM_ROTATE_0) |
+ * BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_180) |
+ * BIT(DRM_ROTATE_270) | BIT(DRM_REFLECT_Y));
+ *
+ * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
+ * transforms the hardware supports, this function may not
+ * be able to produce a supported transform, so the caller should
+ * check the result afterwards.
+ */
+unsigned int drm_rotation_simplify(unsigned int rotation,
+ unsigned int supported_rotations)
+{
+ if (rotation & ~supported_rotations) {
+ rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
+ rotation = (rotation & ~0xf) | BIT((ffs(rotation & 0xf) + 1) %
4);
+ }
+
+ return rotation;
+}
+EXPORT_SYMBOL(drm_rotation_simplify);
+
+/**
* drm_mode_config_init - initialize DRM mode_configuration structure
* @dev: DRM device
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index d25ba84..b97b367 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1154,5 +1154,7 @@ extern int drm_format_vert_chroma_subsampling(uint32_t
format);
extern const char *drm_get_format_name(uint32_t format);
extern struct drm_property *drm_mode_create_rotation_property(struct
drm_device *dev,
unsigned int
supported_rotations);
+extern unsigned int drm_rotation_simplify(unsigned int rotation,
+ unsigned int supported_rotations);
#endif /* __DRM_CRTC_H__ */
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/9] drm/i915: Plane rotation support
Recently some people from inside Intel have showed some interest in 180 degree plane rotation. To avoid a huge mess, I decided that I should implement the feature properly. So I snatched the rotation property from omapdrm, and moved some of the code into drm_crtc.c, added a bunch of helper stuff to drm_crtc/rect and implemented the relevant bits in i915. I didn't touch cursor or primary planes at all. I'm sort of hoping we might do the drm_plane conversion sometime soonish and then we'd avoid adding a bunch of plane properties to the crtc. One thing I don't really like is the current way of stuffing the bit number into the enum_list resulting in DRM_ROTATE_FOO being just the bit number. I'd prefer to make DRM_ROTATE_FOO the shifted bitmask. But I'm not sure if changing that would cause grief to userspace, so I left it alone for now. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] drm: Add drm_rect rotation functions
From: Ville Syrjälä
Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 140 +
include/drm/drm_rect.h | 6 ++
2 files changed, 146 insertions(+)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 7047ca0..631f5af 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -293,3 +293,143 @@ void drm_rect_debug_print(const struct drm_rect *r, bool
fixed_point)
DRM_DEBUG_KMS("%dx%d%+d%+d\n", w, h, r->x1, r->y1);
}
EXPORT_SYMBOL(drm_rect_debug_print);
+
+/**
+ * drm_rect_rotate - Rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation to be applied
+ *
+ * Apply @rotation to the coordinates of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the untransformed coordinate
+ * space.
+ */
+void drm_rect_rotate(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+ struct drm_rect tmp;
+
+ if (rotation & (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+ tmp = *r;
+
+ if (rotation & BIT(DRM_REFLECT_X)) {
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ }
+
+ if (rotation & BIT(DRM_REFLECT_Y)) {
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ }
+ }
+
+ switch (rotation & 0xf) {
+ case BIT(DRM_ROTATE_0):
+ break;
+ case BIT(DRM_ROTATE_90):
+ tmp = *r;
+ r->x1 = tmp.y1;
+ r->x2 = tmp.y2;
+ r->y1 = width - tmp.x2;
+ r->y2 = width - tmp.x1;
+ break;
+ case BIT(DRM_ROTATE_180):
+ tmp = *r;
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ break;
+ case BIT(DRM_ROTATE_270):
+ tmp = *r;
+ r->x1 = height - tmp.y2;
+ r->x2 = height - tmp.y1;
+ r->y1 = tmp.x1;
+ r->y2 = tmp.x2;
+ break;
+ default:
+ break;
+ }
+}
+EXPORT_SYMBOL(drm_rect_rotate);
+
+/**
+ * drm_rect_rotate_inv - Inverse rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation whose inverse is to be applied
+ *
+ * Apply the inverse of @rotation to the coordinates
+ * of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the original untransformed
+ * coordinate space, so that you never have to flip
+ * them when doing a rotatation and its inverse.
+ * That is, if you do:
+ *
+ * drm_rotate(&r, width, height, rotation);
+ * drm_rotate_inv(&r, width, height, rotation);
+ *
+ * you will always get back the original rectangle.
+ */
+void drm_rect_rotate_inv(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+ struct drm_rect tmp;
+
+ switch (rotation & 0xf) {
+ case BIT(DRM_ROTATE_0):
+ break;
+ case BIT(DRM_ROTATE_90):
+ tmp = *r;
+ r->x1 = width - tmp.y2;
+ r->x2 = width - tmp.y1;
+ r->y1 = tmp.x1;
+ r->y2 = tmp.x2;
+ break;
+ case BIT(DRM_ROTATE_180):
+ tmp = *r;
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ break;
+ case BIT(DRM_ROTATE_270):
+ tmp = *r;
+ r->x1 = tmp.y1;
+ r->x2 = tmp.y2;
+ r->y1 = height - tmp.x2;
+ r->y2 = height - tmp.x1;
+ break;
+ default:
+ break;
+ }
+
+ if (rotation & (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+ tmp = *r;
+
+ if (rotation & BIT(DRM_REFLECT_X)) {
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ }
+
+ if (rotation & BIT(DRM_REFLECT_Y)) {
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ }
+ }
+}
+E
[Bug 69961] Regression: Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=69961 Alex Deucher changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Alex Deucher --- Sorry, issue is there there. You need to enable Xv when you build glamor. E.g., pass --enable-xv when you configure glamor. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69961] Regression: Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=69961 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alex Deucher --- Fixed in git. http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=cbb99f659ee7b18ded0008a606e41ded38c1a194 http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=2d791370dfc5570eb74d7a1fb3baf4d4c8ecf243 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730
Am 30.09.2013 10:47, schrieb Grigori Goronzy: On 30.09.2013 10:06, Michel Dänzer wrote: On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote: after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with my RV730 (AGP). Same problem on PALM. Bisection shows that it is caused by commit 68f6dec32. The initialization order seems to be wrong, the check for UVD is done too early. I'll send a patch in a minute. Best regards Grigori Thank you Grigori and Marek (AMD!) ;-) -Dieter That probably means you lost UVD support for some reason. Assuming UVD is still enabled in the kernel, can you bisect which Mesa change caused the problem for you? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] [media] core: Don't use i2c_client->driver
On 09/29/2013 10:51 AM, Lars-Peter Clausen wrote:
> The 'driver' field of the i2c_client struct is redundant and is going to be
> removed. The results of the expressions 'client->driver.driver->field' and
> 'client->dev.driver->field' are identical, so replace all occurrences of the
> former with the later.
>
> Signed-off-by: Lars-Peter Clausen
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/v4l2-core/tuner-core.c | 6 +++---
> drivers/media/v4l2-core/v4l2-common.c | 10 +-
> include/media/v4l2-common.h | 2 +-
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/tuner-core.c
> b/drivers/media/v4l2-core/tuner-core.c
> index ddc9379..4133af0 100644
> --- a/drivers/media/v4l2-core/tuner-core.c
> +++ b/drivers/media/v4l2-core/tuner-core.c
> @@ -43,7 +43,7 @@
>
> #define UNSET (-1U)
>
> -#define PREFIX (t->i2c->driver->driver.name)
> +#define PREFIX (t->i2c->dev.driver->name)
>
> /*
> * Driver modprobe parameters
> @@ -452,7 +452,7 @@ static void set_type(struct i2c_client *c, unsigned int
> type,
> }
>
> tuner_dbg("%s %s I2C addr 0x%02x with type %d used for 0x%02x\n",
> - c->adapter->name, c->driver->driver.name, c->addr << 1, type,
> + c->adapter->name, c->dev.driver->name, c->addr << 1, type,
> t->mode_mask);
> return;
>
> @@ -556,7 +556,7 @@ static void tuner_lookup(struct i2c_adapter *adap,
> int mode_mask;
>
> if (pos->i2c->adapter != adap ||
> - strcmp(pos->i2c->driver->driver.name, "tuner"))
> + strcmp(pos->i2c->dev.driver->name, "tuner"))
> continue;
>
> mode_mask = pos->mode_mask;
> diff --git a/drivers/media/v4l2-core/v4l2-common.c
> b/drivers/media/v4l2-core/v4l2-common.c
> index 037d7a5..433d6d7 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -236,14 +236,14 @@ void v4l2_i2c_subdev_init(struct v4l2_subdev *sd,
> struct i2c_client *client,
> v4l2_subdev_init(sd, ops);
> sd->flags |= V4L2_SUBDEV_FL_IS_I2C;
> /* the owner is the same as the i2c_client's driver owner */
> - sd->owner = client->driver->driver.owner;
> + sd->owner = client->dev.driver->owner;
> sd->dev = &client->dev;
> /* i2c_client and v4l2_subdev point to one another */
> v4l2_set_subdevdata(sd, client);
> i2c_set_clientdata(client, sd);
> /* initialize name */
> snprintf(sd->name, sizeof(sd->name), "%s %d-%04x",
> - client->driver->driver.name, i2c_adapter_id(client->adapter),
> + client->dev.driver->name, i2c_adapter_id(client->adapter),
> client->addr);
> }
> EXPORT_SYMBOL_GPL(v4l2_i2c_subdev_init);
> @@ -274,11 +274,11 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct
> v4l2_device *v4l2_dev,
> loaded. This delay-load mechanism doesn't work if other drivers
> want to use the i2c device, so explicitly loading the module
> is the best alternative. */
> - if (client == NULL || client->driver == NULL)
> + if (client == NULL || client->dev.driver == NULL)
> goto error;
>
> /* Lock the module so we can safely get the v4l2_subdev pointer */
> - if (!try_module_get(client->driver->driver.owner))
> + if (!try_module_get(client->dev.driver->owner))
> goto error;
> sd = i2c_get_clientdata(client);
>
> @@ -287,7 +287,7 @@ struct v4l2_subdev *v4l2_i2c_new_subdev_board(struct
> v4l2_device *v4l2_dev,
> if (v4l2_device_register_subdev(v4l2_dev, sd))
> sd = NULL;
> /* Decrease the module use count to match the first try_module_get. */
> - module_put(client->driver->driver.owner);
> + module_put(client->dev.driver->owner);
>
> error:
> /* If we have a client but no subdev, then something went wrong and
> diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
> index 16550c4..a707529 100644
> --- a/include/media/v4l2-common.h
> +++ b/include/media/v4l2-common.h
> @@ -35,7 +35,7 @@
> printk(level "%s %d-%04x: " fmt, name, i2c_adapter_id(adapter), addr ,
> ## arg)
>
> #define v4l_client_printk(level, client, fmt, arg...)
> \
> - v4l_printk(level, (client)->driver->driver.name, (client)->adapter, \
> + v4l_printk(level, (client)->dev.driver->name, (client)->adapter, \
> (client)->addr, fmt , ## arg)
>
> #define v4l_err(client, fmt, arg...) \
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/3] drm: Sync the DRM_SET_CLIENT_CAP ioctl definition
v2: SET_CAP -> SET_CLIENT_CAP renaming
Signed-off-by: Damien Lespiau
---
include/drm/drm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f400642..725bf51 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -618,6 +618,21 @@ struct drm_get_cap {
__u64 value;
};
+/**
+ * DRM_CLIENT_CAP_STEREO_3D
+ *
+ * if set to 1, the DRM core will expose the stereo 3D capabilities of the
+ * monitor by advertising the supported 3D layouts in the flags of struct
+ * drm_mode_modeinfo.
+ */
+#define DRM_CLIENT_CAP_STEREO_3D 1
+
+/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
+struct drm_set_client_cap {
+ __u64 capability;
+ __u64 value;
+};
+
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
@@ -650,6 +665,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_GEM_FLINKDRM_IOWR(0x0a, struct drm_gem_flink)
#define DRM_IOCTL_GEM_OPEN DRM_IOWR(0x0b, struct drm_gem_open)
#define DRM_IOCTL_GET_CAP DRM_IOWR(0x0c, struct drm_get_cap)
+#define DRM_IOCTL_SET_CLIENT_CAP DRM_IOW( 0x0d, struct
drm_set_client_cap)
#define DRM_IOCTL_SET_UNIQUE DRM_IOW( 0x10, struct drm_unique)
#define DRM_IOCTL_AUTH_MAGIC DRM_IOW( 0x11, struct drm_auth)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 3/3] drm: Introduce a drmSetClientCap() wrapper
That wraps around the new DRM_SET_CLIENT_CAP ioctl.
v2: SET_CAP -> SET_CLIENT_CAP renaming
Signed-off-by: Damien Lespiau
---
xf86drm.c | 7 +++
xf86drm.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/xf86drm.c b/xf86drm.c
index 4791a05..720952f 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -823,6 +823,13 @@ int drmGetCap(int fd, uint64_t capability, uint64_t *value)
return 0;
}
+int drmSetClientCap(int fd, uint64_t capability, uint64_t value)
+{
+ struct drm_set_client_cap cap = { capability, value };
+
+ return drmIoctl(fd, DRM_IOCTL_SET_CLIENT_CAP, &cap);
+}
+
/**
* Free the bus ID information.
*
diff --git a/xf86drm.h b/xf86drm.h
index 5ecb284..1e763a3 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -609,6 +609,8 @@ extern int drmUpdateDrawableInfo(int fd,
drm_drawable_t handle,
unsigned int num, void *data);
extern int drmCtlInstHandler(int fd, int irq);
extern int drmCtlUninstHandler(int fd);
+extern int drmSetClientCap(int fd, uint64_t capability,
+uint64_t value);
/* General user-level programmer's API: authenticated client and/or X */
extern int drmMap(int fd,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 1/3] drm: Synchronize the stereo 3D mode flags from the kernel headers
v2: stereo layouts are now an enum (Daniel Vetter)
Signed-off-by: Damien Lespiau
---
include/drm/drm_mode.h | 39 +--
xf86drmMode.h | 38 --
2 files changed, 49 insertions(+), 28 deletions(-)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index d41d76b..c1bb1a3 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -42,20 +42,31 @@
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC (1<<0)
-#define DRM_MODE_FLAG_NHSYNC (1<<1)
-#define DRM_MODE_FLAG_PVSYNC (1<<2)
-#define DRM_MODE_FLAG_NVSYNC (1<<3)
-#define DRM_MODE_FLAG_INTERLACE(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN (1<<5)
-#define DRM_MODE_FLAG_CSYNC(1<<6)
-#define DRM_MODE_FLAG_PCSYNC (1<<7)
-#define DRM_MODE_FLAG_NCSYNC (1<<8)
-#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(1<<10)
-#define DRM_MODE_FLAG_PIXMUX (1<<11)
-#define DRM_MODE_FLAG_DBLCLK (1<<12)
-#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_PHSYNC (1<<0)
+#define DRM_MODE_FLAG_NHSYNC (1<<1)
+#define DRM_MODE_FLAG_PVSYNC (1<<2)
+#define DRM_MODE_FLAG_NVSYNC (1<<3)
+#define DRM_MODE_FLAG_INTERLACE(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN (1<<5)
+#define DRM_MODE_FLAG_CSYNC(1<<6)
+#define DRM_MODE_FLAG_PCSYNC (1<<7)
+#define DRM_MODE_FLAG_NCSYNC (1<<8)
+#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(1<<10)
+#define DRM_MODE_FLAG_PIXMUX (1<<11)
+#define DRM_MODE_FLAG_DBLCLK (1<<12)
+#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_3D_MASK (0x1f<<14)
+#define DRM_MODE_FLAG_3D_NONE (0<<14)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING(1<<14)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE(2<<14)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL(4<<14)
+#define DRM_MODE_FLAG_3D_L_DEPTH (5<<14)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH(6<<14)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
+
/* DPMS flags */
/* bit compatible with the xorg definitions. */
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 5bc60ee..7fc52b6 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -81,20 +81,30 @@ extern "C" {
/* Video mode flags */
/* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC(1<<0)
-#define DRM_MODE_FLAG_NHSYNC(1<<1)
-#define DRM_MODE_FLAG_PVSYNC(1<<2)
-#define DRM_MODE_FLAG_NVSYNC(1<<3)
-#define DRM_MODE_FLAG_INTERLACE (1<<4)
-#define DRM_MODE_FLAG_DBLSCAN (1<<5)
-#define DRM_MODE_FLAG_CSYNC (1<<6)
-#define DRM_MODE_FLAG_PCSYNC(1<<7)
-#define DRM_MODE_FLAG_NCSYNC(1<<8)
-#define DRM_MODE_FLAG_HSKEW (1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST (1<<10)
-#define DRM_MODE_FLAG_PIXMUX(1<<11)
-#define DRM_MODE_FLAG_DBLCLK(1<<12)
-#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_PHSYNC (1<<0)
+#define DRM_MODE_FLAG_NHSYNC (1<<1)
+#define DRM_MODE_FLAG_PVSYNC (1<<2)
+#define DRM_MODE_FLAG_NVSYNC (1<<3)
+#define DRM_MODE_FLAG_INTERLACE(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN (1<<5)
+#define DRM_MODE_FLAG_CSYNC(1<<6)
+#define DRM_MODE_FLAG_PCSYNC (1<<7)
+#define DRM_MODE_FLAG_NCSYNC (1<<8)
+#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(1<<10)
+#define DRM_MODE_FLAG_PIXMUX (1<<11)
+#define DRM_MODE_FLAG_DBLCLK (1<<12)
+#define DRM_MODE_FLAG_CLKDIV2 (1<<13)
+#define DRM_MODE_FLAG_3D_MASK (0x1f<<14)
+#define DRM_MODE_FLAG_3D_NONE (0<<14)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING(1<<14)
+#define DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE(2<<14)
+#define DRM_MODE_FLAG_3D_LINE_ALTERNATIVE (3<<14)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL(4<<14)
+#define DRM_MODE_FLAG_3D_L_DEPTH (5<<14)
+#define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH(6<<14)
+#define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
/* DPMS flags */
/* bit compatible with the xorg definitions. */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[libdrm] Stereo 3D v3
v2 was: http://lists.freedesktop.org/archives/dri-devel/2013-September/045354.html Only one change, the stereo part for the flags is now an enum instead of being a bit field. The kernel series has been pushed to drm-intel, the libdrm patches should follow if there isn't any objection. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69961] Regression: Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=69961 samit vats changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69961] Regression: Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=69961 --- Comment #1 from samit vats --- Created attachment 86845 --> https://bugs.freedesktop.org/attachment.cgi?id=86845&action=edit xorg.log.ok -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69961] New: Regression: Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=69961 Priority: medium Bug ID: 69961 Assignee: dri-devel@lists.freedesktop.org Summary: Regression: Xserver fails to start Severity: critical Classification: Unclassified OS: All Reporter: hysv...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 86844 --> https://bugs.freedesktop.org/attachment.cgi?id=86844&action=edit xorg.log Driver Stack Details: = 1)Kernel-3.10.5-031005-generic 2)drm-2.4.46 3)Mesa-9.2 4)Xorg-server-1.11.4 5)xf86-video-ati- master 6)glamor-0.5.1/0.5.0 7)LLVM-3.3 System Configuration: = Asic : CapeVerde XT (ID-683D) O.S. : Ubuntu-13.04 (64 bit) Details: 1) The Xserver start fine with driver build before 28th september commit. 2) X server crashes with Backtrace with git master : (==) Using system config directory "/usr/share/X11/xorg.conf.d" (II) [KMS] Kernel modesetting enabled. /usr/bin/X: symbol lookup error: /home/atitest/install/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: glamor_xv_init xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space
On Mon, Sep 30, 2013 at 2:04 PM, Dieter Nützel wrote: > Even so, I have no xorg.conf only /etc/X11/xorg.conf.d/ files. > Which one should I create/change for testing, this? Just add the snippet I've pasted into a new file in xorg.conf.d and X should pick it up and integrate it into the autodetected config. You can check in the Xorg.log whether it worked out. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space
Am 30.09.2013 13:36, schrieb Daniel Vetter: On Sat, Sep 28, 2013 at 12:49:24PM -0400, John Hupp wrote: [I emailed the list with this same material on 9/13, but it has received no response and someone on the Ubuntu kernel team suggested that I change the email Subject from "Re: Moving a bug upstream per downstream request, emailing the maintainers" to the more descriptive one above.] When I emailed the maintainers with the report below on 8/15 (and archived at http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html), a response came on 8/16: "It's a flash bug. They ignore the format of the Window that they PutImage to. (Worse, they create an image of the right depth or else X would reject the PutImage with a BadMatch and then render incorrect pixel data into it.)" Despite that, someone on the Ubuntu kernel team asserted "at a minimum a non-flash regression exists going from Quantal to Raring," and urged me to proceed with upstream kernel bisection. I finally finished that, and arrived at the result: Still a flash bug. This commit simply enables rgb555 in the kernel, which sna likes to use on gen2/3. Flash is just too dense and always presumes xrgb. Adding Section "Screen" Identifier "igd" DefaultDepth 24 EndSection to your xorg.conf will work around. -Daniel Hello Daniel, hello John, I see the same shit thing with my Radeon RV730 AGP (HD4650) 'cause I have an old SSE1 system, only. The poor people at Adobe do NOT release any update (even a security one) for SSE1 systems since summer 2012!!! Even so, I have no xorg.conf only /etc/X11/xorg.conf.d/ files. Which one should I create/change for testing, this? Thanks, Dieter PS I only see this with 'hardware acceleration' (ha,ha, 2012..., only working right with SSE2, Adobe thinks,...) PPS The little preview pictures during Flash search are right. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
On 09/19/2013 11:44 PM, Russell King wrote: > Replace the following sequence: > > dma_set_mask(dev, mask); > dma_set_coherent_mask(dev, mask); > > with a call to the new helper dma_set_mask_and_coherent(). > > Signed-off-by: Russell King Acked-by: Hans Verkuil Regards, Hans > --- > drivers/staging/media/dt3155v4l/dt3155v4l.c |5 + > 1 files changed, 1 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c > b/drivers/staging/media/dt3155v4l/dt3155v4l.c > index 90d6ac4..081407b 100644 > --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c > +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c > @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct > pci_device_id *id) > int err; > struct dt3155_priv *pd; > > - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32)); > - if (err) > - return -ENODEV; > - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32)); > + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); > if (err) > return -ENODEV; > pd = kzalloc(sizeof(*pd), GFP_KERNEL); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Flash 11.2 content displays in shades of green and purple only, and in a horizontally compressed space
On Sat, Sep 28, 2013 at 12:49:24PM -0400, John Hupp wrote:
> [I emailed the list with this same material on 9/13, but it has
> received no response and someone on the Ubuntu kernel team suggested
> that I change the email Subject from "Re: Moving a bug upstream per
> downstream request, emailing the maintainers" to the more
> descriptive one above.]
>
> When I emailed the maintainers with the report below on 8/15 (and
> archived at
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043876.html),
> a response came on 8/16:
>
> "It's a flash bug. They ignore the format of the Window that they
> PutImage to. (Worse, they create an image of the right depth or else X
> would reject the PutImage with a BadMatch and then render incorrect
> pixel data into it.)"
>
> Despite that, someone on the Ubuntu kernel team asserted "at a
> minimum a non-flash regression exists going from Quantal to Raring,"
> and urged me to proceed with upstream kernel bisection.
>
> I finally finished that, and arrived at the result:
Still a flash bug. This commit simply enables rgb555 in the kernel, which
sna likes to use on gen2/3. Flash is just too dense and always presumes
xrgb. Adding
Section "Screen"
Identifier "igd"
DefaultDepth 24
EndSection
to your xorg.conf will work around.
-Daniel
>
> 57779d06367a915ee03e6cb918d7575f0a46e419 is the first bad commit
> commit 57779d06367a915ee03e6cb918d7575f0a46e419
> Author: Ville Syrjälä
> Date: Wed Oct 31 17:50:14 2012 +0200
>
> drm/i915: Fix display pixel format handling
>
> Fix support for all RGB/BGR pixel formats (except the
> 16:16:16:16 float
> format).
>
> Fix intel_init_framebuffer() to match hardware and driver limitations:
> * RGB332 is not supported at all
> * CI8 is supported
> * XRGB1555 & co. are supported on Gen3 and earlier
> * XRGB210101010 & co. are supported from Gen4 onwards
> * BGR formats are supported from Gen4 onwards
> * YUV formats are supported from Gen5 onwards (driver limitation)
>
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Jesse Barnes
> Signed-off-by: Daniel Vetter
>
> :04 04 334e1536b3513d0c329a8bb6360593d12065b71d
> bf0996ec13cbee07156c5e9f98dcdee30200e658 M drivers
>
> -
>
> The git bisect log:
>
> git bisect start
> # good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
> git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
> # bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3
> git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20
> # good: [db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070] Merge tag 'dt' of
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
> git bisect good db5b0ae00712b5176d7405e7a1dd2bfd6e8f5070
> # bad: [3c2e81ef344a90bb0a39d84af6878b4aeff568a2] Merge branch
> 'drm-next' of git://people.freedesktop.org/~airlied/linux
> git bisect bad 3c2e81ef344a90bb0a39d84af6878b4aeff568a2
> # good: [d8c532c40721f7507896d202b8cae3b3642d2b0d] Merge branch
> 'v4l_for_linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> git bisect good d8c532c40721f7507896d202b8cae3b3642d2b0d
> # good: [2a74dbb9a86e8102dcd07d284135b4530a84826e] Merge branch
> 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
> git bisect good 2a74dbb9a86e8102dcd07d284135b4530a84826e
> # bad: [124ea297c8f0e0a3a567af0894fdbe05caaf80ec] drm/nouveau: unpin
> pushbuffer bo before destroying it
> git bisect bad 124ea297c8f0e0a3a567af0894fdbe05caaf80ec
> # bad: [12f3382bc0262e981a2e58aca900cbbdbbe66825] drm/i915:
> implement WaDisablePSDDualDispatchEnable on IVB & VLV
> git bisect bad 12f3382bc0262e981a2e58aca900cbbdbbe66825
> # good: [20474e90c948545c51da95689b8342a4f3bbaeb6] drm/i915: fix
> checks inside ironlake_crtc_{enable, disable}
> git bisect good 20474e90c948545c51da95689b8342a4f3bbaeb6
> # good: [00c09d70df6b30c980f20facc1db3def3f5a637e] drm/i915: create
> the DDI encoder
> git bisect good 00c09d70df6b30c980f20facc1db3def3f5a637e
> # bad: [a35f267946947b3798827a783d82d3d2aa55697d] drm/i915: remove
> IBX code from lpt_enable_pch_transcoder
> git bisect bad a35f267946947b3798827a783d82d3d2aa55697d
> # bad: [9256aa195d3badd009bf4addee6c3ae39879b8a6] drm/i915: move
> encoder->mode_set calls to crtc_mode_set
> git bisect bad 9256aa195d3badd009bf4addee6c3ae39879b8a6
> # good: [e7210c3c4f0d05e318b854bbd545fe335930c5cc] drm/i915: move
> more pte encoding to pte encode
> git bisect good e7210c3c4f0d05e318b854bbd545fe335930c5cc
> # bad: [90f9a336f56318d4f21a29e8ef063cb70fe7dd11] drm/i915: Check
> the framebuffer offset
> git bisect bad 90f9a336f56318d4f21a29e8ef063cb70fe7dd11
> # bad: [5d7bd705ddb362d5bd8ef2f3b294cd8f9d93c39e] drm/i915: Check
> framebuffer stride more thoroughly
> git bisect bad 5d7bd705ddb362d5bd8ef2f3b294cd8f9d93c39e
> # bad: [57779d06367a915ee03e6cb918d7575f0a46e419] drm/i915: Fix
> display pixel format handling
> git bisect bad 57779d
Re: linux-next: manual merge of the drm-intel tree
On Mon, Sep 30, 2013 at 1:26 PM, Thierry Reding wrote: > Today's linux-next merge of the drm-intel tree got conflicts in > > drivers/gpu/drm/i915/intel_display.c > > I fixed it up (see below). Please check if the resolution looks correct. Looks good. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree
Today's linux-next merge of the drm-intel tree got conflicts in
drivers/gpu/drm/i915/intel_display.c
I fixed it up (see below). Please check if the resolution looks correct.
Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/intel_display.c
index e5822e7,cbbdab6..76870f0
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4775,21 -4882,8 +4882,12 @@@ static void i9xx_set_pipeconf(struct in
pipeconf = 0;
+ if (dev_priv->quirks & QUIRK_PIPEA_FORCE &&
+ I915_READ(PIPECONF(intel_crtc->pipe)) & PIPECONF_ENABLE)
+ pipeconf |= PIPECONF_ENABLE;
+
- if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) {
- /* Enable pixel doubling when the dot clock is > 90% of the
(display)
-* core speed.
-*
-* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
-* pipe == 0 check?
-*/
- if (intel_crtc->config.requested_mode.clock >
- dev_priv->display.get_display_clock_speed(dev) * 9 / 10)
- pipeconf |= PIPECONF_DOUBLE_WIDE;
- }
+ if (intel_crtc->config.double_wide)
+ pipeconf |= PIPECONF_DOUBLE_WIDE;
/* only g4x and later have fancy bpc/dither controls */
if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: release unhandled page flip events at postclose.
This patch resolves a dead lock issue that could be incurred when
exynos_drm_crtc_dpms function was called.
The exynos_drm_crtc_dpms function waits for the completion of pended
page flip events. However, preclose callback - this releases all unhandled
page flip events - is called prior to the exynos_drm_crtc_dpms function call
when drm is closed. So at this time, this will make the exynos_drm_crtc_dpms
to wait infiniately for the completion of the page flip events.
This patch releases the unhandled page flip events at postclose instead
of preclose so that exynos_drm_crtc_dpms function can be waked up.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f727f98..9974294 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -167,10 +167,18 @@ static int exynos_drm_open(struct drm_device *dev, struct
drm_file *file)
static void exynos_drm_preclose(struct drm_device *dev,
struct drm_file *file)
{
+ exynos_drm_subdrv_close(dev, file);
+}
+
+static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
+{
struct exynos_drm_private *private = dev->dev_private;
struct drm_pending_vblank_event *e, *t;
unsigned long flags;
+ if (!file->driver_priv)
+ return;
+
/* release events of current file */
spin_lock_irqsave(&dev->event_lock, flags);
list_for_each_entry_safe(e, t, &private->pageflip_event_list,
@@ -182,13 +190,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
}
spin_unlock_irqrestore(&dev->event_lock, flags);
- exynos_drm_subdrv_close(dev, file);
-}
-
-static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
-{
- if (!file->driver_priv)
- return;
kfree(file->driver_priv);
file->driver_priv = NULL;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69514] R770 (Radeon 4850) screen/buffer corruption when waking up from sleep mode
https://bugs.freedesktop.org/show_bug.cgi?id=69514 --- Comment #13 from Peter Asplund --- I haven't been able to disect anything yet, but I do have some updated information. I switched back my BIOS settings to Hibernate via S3 instead of S1 (which I was forced to switch to because of Windows 7 somehow disabling my hibernate possibility because of some "known issue with power management" or something like it) and now my glitches are gone! The hibernate and wake-up works perfectly. I have yet to try Sleep I think, but I think I tried and it doesn't work at all since my motherboard only supports _either_ S1 or S3. This is very strange though, since I'm fairly certain I've used both of them before. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] ALSA: ppc: keywest: Don't use i2c_client->driver
At Sun, 29 Sep 2013 10:51:04 +0200,
Lars-Peter Clausen wrote:
>
> The 'driver' field of the i2c_client struct is redundant and is going to be
> removed. Use 'to_i2c_driver(client->dev.driver)' instead to get direct
> access to the i2c_driver struct.
>
> Signed-off-by: Lars-Peter Clausen
Acked-by: Takashi Iwai
thanks,
Takashi
> ---
> sound/ppc/keywest.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/ppc/keywest.c b/sound/ppc/keywest.c
> index 01aecc2..0d1c27e 100644
> --- a/sound/ppc/keywest.c
> +++ b/sound/ppc/keywest.c
> @@ -65,7 +65,7 @@ static int keywest_attach_adapter(struct i2c_adapter
> *adapter)
>* already bound. If not it means binding failed, and then there
>* is no point in keeping the device instantiated.
>*/
> - if (!keywest_ctx->client->driver) {
> + if (!keywest_ctx->client->dev.driver) {
> i2c_unregister_device(keywest_ctx->client);
> keywest_ctx->client = NULL;
> return -ENODEV;
> @@ -76,7 +76,7 @@ static int keywest_attach_adapter(struct i2c_adapter
> *adapter)
>* This is safe because i2c-core holds the core_lock mutex for us.
>*/
> list_add_tail(&keywest_ctx->client->detected,
> - &keywest_ctx->client->driver->clients);
> + &to_i2c_driver(keywest_ctx->client->dev.driver)->clients);
> return 0;
> }
>
> --
> 1.8.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Mesa-dev] [r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730
On 30.09.2013 10:06, Michel Dänzer wrote: On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote: after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with my RV730 (AGP). Same problem on PALM. Bisection shows that it is caused by commit 68f6dec32. The initialization order seems to be wrong, the check for UVD is done too early. I'll send a patch in a minute. Best regards Grigori That probably means you lost UVD support for some reason. Assuming UVD is still enabled in the kernel, can you bisect which Mesa change caused the problem for you? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [r600g] Mesa CVS 4e9aa67: vdpau has only MPEG1/2 on RV730
On Son, 2013-09-29 at 22:34 +0200, Dieter Nützel wrote: > > after latest git pull I've only MPEG1, MPEG2_SIMPLE and MPEG2_MAIN with > my RV730 (AGP). That probably means you lost UVD support for some reason. Assuming UVD is still enabled in the kernel, can you bisect which Mesa change caused the problem for you? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 09/28/2013 06:10 PM, Inki Dae wrote:
Any opinion from Device-Tree folks?
IMO, we should have same consensus on Shirish patches before proceeding.
Rahul, it seems that DT people have no interest in this issue. So let's
have a consensus about this issue internally.
To Mr. Kyungmin, Sylwester, Kukjin Kim, and Tomasz,
How about keeping hdmiphy config data in each board dts file?
Please don't use HTML and quote only relevant part of e-mails. Otherwise
there are good chances your messages end up in people's spam box.
It often helps to Cc a DT binding maintainer directly.
Then, you consider moving the HDMI phy configuration to the device tree.
As Sean suggested in this thread:
">> +static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
+ },
+ },
[trimmed couple more entries]
+};
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them universally.
Shirish has uploaded a patch to the chromium review site to push these
into dt (https://chromium-review.googlesource.com/#/c/65581). Maybe
you can work that into your patch set?"
The configuration data is 64 bytes of the register values IIUC. Would it be
possible to figure out exact meaning of each byte ? Do all of these bytes
need to be changed per board ? Perhaps we can have per SoC static tables in
the PHY driver and be overwriting only some of the bytes with values read
from device tree ?
AFAIR firmware-like binary blobs (register address/value pairs) are not
supposed to be stored in DT.
If there is no detailed documentation for theese PHY configuration tables
I guess there is no choice but to put these raw 64 bytes in DT. Presumably
this should be a an required property defined only by board dts, since those
values are PCB design dependent.
However, if not all boards need tweaking this configuration data, then it
could make sense to define recommended per-SoC tables in the driver and
overwrite from DT only if it is specified there for a specific board.
If we can come up with universal configuration for a SoC and selected pixel
clock frequency then it could likely be better to store that in the driver
rather than in DT.
--
Thanks,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
