[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi R?mi, On Tuesday 31 July 2012 21:39:40 R?mi Denis-Courmont wrote: > Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez ?crit : > > On Tuesday 31 July 2012 16:39:00 R?mi Denis-Courmont wrote: > > > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit : > > > > > For that matter, wouldn't it be useful to support exporting a > > > > > userptr > > > > > buffer at some point in the future? > > > > > > > > Shouldn't USERPTR usage be discouraged once we get dma-buf support ? > > > > > > USERPTR, where available, is currently the only way to perform zero-copy > > > from kernel to userspace. READWRITE does not support zero-copy at all. > > > MMAP only supports zero-copy if userspace knows a boundary on the number > > > of concurrent buffers *and* the device can deal with that number of > > > buffers; in general, MMAP requires memory copying. > > > > Could you please share your use case(s) with us ? > > I want to receive the video buffers in user space for processing. Typically > "processing" is software encoding or conversion. That's what virtually any > V4L application does on the desktop... But what prevents you from using MMAP ? -- Regards, Laurent Pinchart
[PATCH] drm/i915: Fix mem leak in intel_sdvo_write_cmd()
If the allocation of 'buf' succeeds but the allocation of 'msgs' fails
we'll return false and leak 'buf' when it goes out of scope.
Signed-off-by: Jesper Juhl
---
drivers/gpu/drm/i915/intel_sdvo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
note: compile tested only due to lack of hardware.
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 26a6a4d..1f73e24 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -444,13 +444,12 @@ static bool intel_sdvo_write_cmd(struct intel_sdvo
*intel_sdvo, u8 cmd,
struct i2c_msg *msgs;
int i, ret = true;
- buf = (u8 *)kzalloc(args_len * 2 + 2, GFP_KERNEL);
- if (!buf)
- return false;
-
+ buf = kzalloc(args_len * 2 + 2, GFP_KERNEL);
msgs = kcalloc(args_len + 3, sizeof(*msgs), GFP_KERNEL);
- if (!msgs)
- return false;
+ if (!msgs || !buf) {
+ ret = false;
+ goto out;
+ }
intel_sdvo_debug_write(intel_sdvo, cmd, args, args_len);
--
1.7.11.3
--
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Tue, Jul 31, 2012 at 09:58:04AM -0400, Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti
> wrote:
> > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher
> > wrote:
> >> Regarding patches 3 and 4, it might be easier to just store a pointer
> >> to the relevant encoder when you verify ATIF rather than walking the
> >> encoder list every time.
Done.
> > Makes sense, I was unsure about the lifetime of the encoders, but
> > AFAICS they're destroyed only when the module in unloaded.
>
> They are present for the life of the driver.
I had to move to call to radeon_acpi_init after radeon_modeset_init,
otherwise the encoders are not present yet (the tear down code path is
correct, acpi first, then modeset).
Latest and greatest version is attached; I fixed notifications when
using custom command codes (tested by Pali Roh?r) and implemented your
suggestion.
Luca
-- next part --
>From f0f8699eabee0d47b93fba14f8126b821cc106a5 Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Sun, 29 Jul 2012 17:04:43 +0200
Subject: [PATCH 1/4] drm/radeon: refactor radeon_atif_call
Don't hard-code function number, this will allow to reuse the function.
v2: add support for the 2nd parameter (from Lee, Chun-Yi
).
Signed-off-by: Luca Tettamanti
---
drivers/gpu/drm/radeon/radeon_acpi.c | 38 --
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5b32e49..158e514 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -14,23 +14,30 @@
#include
/* Call the ATIF method
- *
- * Note: currently we discard the output
*/
-static int radeon_atif_call(acpi_handle handle)
+static union acpi_object *radeon_atif_call(acpi_handle handle, int function,
+ struct acpi_buffer *params)
{
acpi_status status;
union acpi_object atif_arg_elements[2];
struct acpi_object_list atif_arg;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
atif_arg.count = 2;
atif_arg.pointer = &atif_arg_elements[0];
atif_arg_elements[0].type = ACPI_TYPE_INTEGER;
- atif_arg_elements[0].integer.value = ATIF_FUNCTION_VERIFY_INTERFACE;
- atif_arg_elements[1].type = ACPI_TYPE_INTEGER;
- atif_arg_elements[1].integer.value = 0;
+ atif_arg_elements[0].integer.value = function;
+
+ if (params) {
+ atif_arg_elements[1].type = ACPI_TYPE_BUFFER;
+ atif_arg_elements[1].buffer.length = params->length;
+ atif_arg_elements[1].buffer.pointer = params->pointer;
+ } else {
+ /* We need a second fake parameter */
+ atif_arg_elements[1].type = ACPI_TYPE_INTEGER;
+ atif_arg_elements[1].integer.value = 0;
+ }
status = acpi_evaluate_object(handle, "ATIF", &atif_arg, &buffer);
@@ -39,18 +46,18 @@ static int radeon_atif_call(acpi_handle handle)
DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
acpi_format_exception(status));
kfree(buffer.pointer);
- return 1;
+ return NULL;
}
- kfree(buffer.pointer);
- return 0;
+ return buffer.pointer;
}
/* Call all ACPI methods here */
int radeon_acpi_init(struct radeon_device *rdev)
{
acpi_handle handle;
- int ret;
+ union acpi_object *info;
+ int ret = 0;
/* Get the device handle */
handle = DEVICE_ACPI_HANDLE(&rdev->pdev->dev);
@@ -60,10 +67,11 @@ int radeon_acpi_init(struct radeon_device *rdev)
return 0;
/* Call the ATIF method */
- ret = radeon_atif_call(handle);
- if (ret)
- return ret;
+ info = radeon_atif_call(handle, ATIF_FUNCTION_VERIFY_INTERFACE, NULL);
+ if (!info)
+ ret = -EIO;
- return 0;
+ kfree(info);
+ return ret;
}
--
1.7.10.4
-- next part --
>From 427002ddf653b0abd0fb820b09322bf2a0b281af Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Mon, 30 Jul 2012 21:11:58 +0200
Subject: [PATCH 2/4] drm/radeon: implement radeon_atif_verify_interface
Wrap the call to VERIFY_INTERFACE and add the parsing of the support
vectors.
v2: use a packed struct for handling the output of ACPI calls, hides
ugly pointer arithmetics (Lee, Chun-Yi ).
Signed-off-by: Luca Tettamanti
---
drivers/gpu/drm/radeon/radeon.h | 40 +
drivers/gpu/drm/radeon/radeon_acpi.c | 79 +++---
2 files changed, 113 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..0db98eb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1456,6 +1456
[Bug 51383] 'make clean' broken after switching to automake
https://bugs.freedesktop.org/show_bug.cgi?id=51383 --- Comment #1 from Matt Turner 2012-08-01 04:57:09 UTC --- This looks just like a problem caused by still having non-automake Makefiles. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 52549] libdrm 2.4.37 compilation fails if ETIME not defined
https://bugs.freedesktop.org/show_bug.cgi?id=52549 --- Comment #1 from Matt Turner 2012-08-01 04:48:13 UTC --- http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/32267 So why are you trying to build libdrm_intel on an operating system that doesn't have Intel KMS? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez ?crit : > Hi R?mi, > > On Tuesday 31 July 2012 16:39:00 R?mi Denis-Courmont wrote: > > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit : > > > > For that matter, wouldn't it be useful to support exporting a userptr > > > > buffer at some point in the future? > > > > > > Shouldn't USERPTR usage be discouraged once we get dma-buf support ? > > > > USERPTR, where available, is currently the only way to perform zero-copy > > from kernel to userspace. READWRITE does not support zero-copy at all. > > MMAP only supports zero-copy if userspace knows a boundary on the number > > of concurrent buffers *and* the device can deal with that number of > > buffers; in general, MMAP requires memory copying. > > Could you please share your use case(s) with us ? I want to receive the video buffers in user space for processing. Typically "processing" is software encoding or conversion. That's what virtually any V4L application does on the desktop... -- R?mi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Jerome Glisse changed: What|Removed |Added Attachment #65013|0 |1 is obsolete|| --- Comment #76 from Jerome Glisse 2012-08-01 03:40:53 UTC --- Created attachment 65014 --> https://bugs.freedesktop.org/attachment.cgi?id=65014 Free va earyl This one build (minor typo) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #75 from Alexandre Demers 2012-08-01 03:26:16 UTC --- These are all food news. So I'll test both patches and I'll see if it also fixes the thing for me. Awaters (I don't know your name, you'll have to tell me), if what you found fixes my 6 month old problem, I'll offer you a beer (or whatever you'd like to drink). I'll be back soon with some news (good I hope). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
Massive power regression going 3.4->3.5
On Tue, 31 Jul 2012 11:14:17 +0100, Chris Wilson
wrote:
> On Tue, 31 Jul 2012 10:57:10 +0100, James Bottomley HansenPartnership.com> wrote:
> > > When did you inspect the debug files? One effect I can imagine is that
> > > if your system was previously stuck at RPn and never upclocking the GPU
> > > when X starts. The question would then be what is preventing the GPU
> > > from reaching its lowest power state again.
> >
> > After I logged into an xfce4 session and powertop showed idle had been
> > reached.
That you are using xfce4 makes the use of semaphores for pageflips as
being the root cause even more suspect. Pageflips are only used for a
fullscreen DRI client caalling SwapBuffers, to my knowledge xfce4 does
not use DRI at all - its compositing manager is XRender based if you
happen to be using it.
Please can you try the small patch to disable the use of semaphores for
pageflips and see if the regression remains (which I judge it will...):
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 5c4657a..f301f2f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3067,7 +3067,7 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_o
return ret;
if (pipelined != obj->ring) {
- ret = i915_gem_object_sync(obj, pipelined);
+ ret = i915_gem_object_wait_rendering(obj);
if (ret)
return ret;
}
--
Chris Wilson, Intel Open Source Technology Centre
Re: [PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Hello Kgene, On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim wrote: > Leela Krishna Amudala wrote: >> >> The FIMD register headers are moved to include/video/ >> hence, deleting these files from platform side >> >> Signed-off-by: Leela Krishna Amudala >> --- >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 > --- >> >> 2 files changed, 0 insertions(+), 562 deletions(-) >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h >> > No. This should be squashed into first patch on this series. See below. > > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 > -- > 2 files changed, 134 insertions(+), 170 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > include/video/samsung_fimd.h (74%) > If I squash it with the first patch and if somebody set that as a head commit, it will break the build. Hence, splitted it up from the first patch. Thank you Sylwester for suggesting this split up change. Regards, Leela Krishna > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" 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: drm_intel_bo for the KMS framebuffer with IvyBridge?
On Wed, Aug 1, 2012 at 1:07 PM, Segovia, Benjamin wrote: > Yes, I imagine this is not exactly using the API by the book :) but this is > really to play with the HW not to write a real application. Can you give me > the complete link to the file? I am not finding it in libdrm source. I guess > it is somewhere else. > Thanks! http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_display.c#n1794 Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: drm_intel_bo for the KMS framebuffer with IvyBridge?
Yes, I imagine this is not exactly using the API by the book :) but this is really to play with the HW not to write a real application. Can you give me the complete link to the file? I am not finding it in libdrm source. I guess it is somewhere else. Thanks! Ben -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Tuesday, July 31, 2012 8:02 PM To: Segovia, Benjamin Cc: dri-devel@lists.freedesktop.org Subject: Re: drm_intel_bo for the KMS framebuffer with IvyBridge? On Wed, Aug 1, 2012 at 12:59 PM, Segovia, Benjamin wrote: > Hello all, > > Saying I want to play with an IvyBridge machine and the display when X is > *not* running (I just opened /dev/dri/card0 from a terminal). Is there a > simple way to get a drm_intel_bo for the terminal framebuffer such that I > can brutally write into it? So, can I easily get its bo and its format > (width, height, pitch, format, tiling)? > Not recommended, but there is code in the ddx to get the handle for the framebufffer so we can copy it at X startup. Its in intel_display.c. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_intel_bo for the KMS framebuffer with IvyBridge?
On Wed, Aug 1, 2012 at 12:59 PM, Segovia, Benjamin wrote: > Hello all, > > Saying I want to play with an IvyBridge machine and the display when X is > *not* running (I just opened /dev/dri/card0 from a terminal). Is there a > simple way to get a drm_intel_bo for the terminal framebuffer such that I > can brutally write into it? So, can I easily get its bo and its format > (width, height, pitch, format, tiling)? > Not recommended, but there is code in the ddx to get the handle for the framebufffer so we can copy it at X startup. Its in intel_display.c. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm_intel_bo for the KMS framebuffer with IvyBridge?
Hello all, Saying I want to play with an IvyBridge machine and the display when X is *not* running (I just opened /dev/dri/card0 from a terminal). Is there a simple way to get a drm_intel_bo for the terminal framebuffer such that I can brutally write into it? So, can I easily get its bo and its format (width, height, pitch, format, tiling)? Cheers, Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library
https://bugs.freedesktop.org/show_bug.cgi?id=49817 --- Comment #11 from stevenvandenbrandenstift at gmail.com 2012-07-31 19:44:10 UTC --- (In reply to comment #10) > (In reply to comment #8) > > same problem here when trying to run dungeon siege 2 via wine, intro plays > > fine > > and then hangs , found a radeon problem to be the cause. > > I tried the demo of the game but couldn't reproduce this. It seems to be > working fine both with 8.0.4 and with git master. to be more precise its the dungeon siege 2 broken world extension afther running the video config feature from the game. I will try to reinstall wine and the game to give the exact steps i followed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #74 from Jerome Glisse 2012-08-01 02:15:19 UTC --- The way i build my kernel must hide this latency i guess... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #73 from Jerome Glisse 2012-08-01 02:14:12 UTC --- Created attachment 65013 --> https://bugs.freedesktop.org/attachment.cgi?id=65013 Free va early in the kernel Diagnosis was kind of obvious, but it just pop into my mind that ttm was sometimes delaying the deletion. So attached kernel patch should fix the issue without any mesa patch. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #72 from awate...@gmail.com 2012-08-01 02:09:17 UTC --- Also, I believe the source of "radeon :01:00.0: bo 8802ea5ec800 va 0x038EC000 conflict with (bo 8803eb464000 0x038EC000 0x038ED000)" is due to a race condition. It appears that after the call to radeon_bomgr_free_va the virtual address space is in a state where user space sees that freed address as available but the kernel hasn't been notified yet, until the drmIoctl call I assume. I'm not sure if there are multiple threads allowed to interact with radeon_drm_bo.c, but if there are then the user space can request a virtual address that hasn't been freed yet by the kernel. I moved the call to radeon_bomgr_free_va to be after the drmIoctl inradeon_bo_destroy, I'll run through the piglit tests to see if it fixes the errors. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] drm: refcnt drm_framebuffer
On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote: > On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson > wrote: > > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark > > wrote: > >> From: Rob Clark > >> > >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold > >> a ref to the fb when disabling a pipe until the next vblank, this > >> avoids the need to make disabling an overlay synchronous. This is a > >> problem that shows up when userspace is using a drm plane to > >> implement a hw cursor.. making overlay disable synchronous causes > >> a performance problem when x11 is rapidly enabling/disabling the > >> hw cursor. But not making it synchronous opens up a race condition > >> for crashing if userspace turns around and immediately deletes the > >> fb. Refcnt'ing the fb makes it possible to solve this problem. > > > > Presumably you have a follow-on patch putting the new refcnt to use so > > that we can judge whether you truly need refcnting on the fb itself in > > addition to the refcnted object and the various hw bookkeeping that > > needs to be performed? > > Yes, I do.. although it is a bit experimental at this point, so not > really ready to be submitted as anything other than an RFC.. it is > part of omapdrm kms re-write to use dispc directly rather than go thru > omapdss. (With omapdss we don't hit this issue because disabling > overlays is forced to be synchronous.. so instead we have the > performance problem I mentioned.) > > I *could* just rely on the GEM refcnt, but that gets messier when you > take into account multi-planar formats. I suppose I also could have > my own internal refcnt'd object to hold the set of GEM objects > associated w/ the fb, but, well, that seems a bit silly. And > refcnt'ing the fb had been mentioned previously as a good thing to do > (I think it was danvet?) Sure, there are a few places in the code that have caused ordering issues in the past due to lack of refcnting the fb... But since you haven't fixed up those cases, I'm looking for justification for adding that extra bit of complexity. Adding a new interface and no users is just asking for trouble. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #1 from stevenvandenbrandenstift at gmail.com 2012-07-31 18:38:32 UTC --- what else do i need to submit and how to do it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library
https://bugs.freedesktop.org/show_bug.cgi?id=49817 --- Comment #10 from Sven Arvidsson 2012-07-31 18:35:56 UTC --- (In reply to comment #8) > same problem here when trying to run dungeon siege 2 via wine, intro plays > fine > and then hangs , found a radeon problem to be the cause. I tried the demo of the game but couldn't reproduce this. It seems to be working fine both with 8.0.4 and with git master. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi R?mi, On Tuesday 31 July 2012 16:39:00 R?mi Denis-Courmont wrote: > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit : > > > For that matter, wouldn't it be useful to support exporting a userptr > > > buffer at some point in the future? > > > > Shouldn't USERPTR usage be discouraged once we get dma-buf support ? > > USERPTR, where available, is currently the only way to perform zero-copy > from kernel to userspace. READWRITE does not support zero-copy at all. MMAP > only supports zero-copy if userspace knows a boundary on the number of > concurrent buffers *and* the device can deal with that number of buffers; > in general, MMAP requires memory copying. Could you please share your use case(s) with us ? > I am not sure DMABUF even supports transmitting data efficiently to > userspace. In my understanding, it's meant for transmitting data between > DSP's bypassing userspace entirely, in other words the exact opposite of > what USERBUF does. -- Regards, Laurent Pinchart
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #71 from awate...@gmail.com 2012-08-01
01:18:00 UTC ---
I have been having this same issue with respect to rendering regressions, I
have also experienced the error relating to va conflicts. I investigated it a
bit and I think the cause of the rendering regression is when a va is freed
through radeon_bomgr_free_va and subsequently used again in
radeon_bomgr_find_va the GPU isn't done with the memory and it gets overwritten
before the GPU is done.
I experimented with this a bit and by not reusing any va_holes in
radeon_bomgr_find_va the rendering regression goes away, at the expense of
continually eating up the memory. So I looked around a way to make it so the
va was only freed when it wasn't used any more, and it turns out that worked as
well.
In order to test this I placed a call to radeon_bo_wait before
radeon_bomgr_free_va is called within radeon_bo_destroy, the code looks
something like in radeon_drm_bo.c
if (mgr->va) {
radeon_bo_wait(bo, RADEON_USAGE_READWRITE);
radeon_bomgr_free_va(mgr, bo->va, bo->va_size);
}
It causes busy waiting currently and could be improved by tracking the
destroyed bos that need to be freed from va when they are not busy, if this is
ultimately the way to solve it.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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
Fwd: Brightness on HP EliteBook 8460p
On Tuesday 31 July 2012 17:49:32 Luca Tettamanti wrote: > I'm putting back the CC and adding Alex. > > On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r wrote: > > Thanks, now working. When I write to acpi video brightness > > file it change brightness and in dmesg is: > > > > [ 47.200998] [drm:radeon_atif_handler], event, device_class > > = video, type = 0xd0 > > [ 47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS > > pending requests: 0x80 > > [ 47.201104] [drm:radeon_atif_handler], ATIF: 1 pending > > SBIOS requests > > [ 47.201105] [drm:radeon_atif_handler], Changing brightness > > to 11 > > Great! I'll send an updated patch to Alex soon. > > > I think that acpi only sent event about brightness key > > pressed, because nothing happened when I pressed it. > > > > Also for windows is needed special HP application (hp hotkey) > > for brightness keys. Without it brightness keys not working > > too... > I've looked at hp-wmi: the hotkey is indeed dispatched via WMI > (hp-wmi) so you need something in userspace (KDE, Gnome, etc) > to respond to that key press. > No, when I rmmod hp-wmi brightness keys still generate events. And when I disable acpi then brightness keys do not generate events but adjust brightness automatically (by BIOS). I think that hp-wmi on my notebook only handle bluetooth & wifi rfkills and ALS switch. All button working without hp-wmi too. > > And there is one problem with /sys/class/backlight/radeon_bl. > > When I enable Ambient Light Sensor which auto adjust > > brightness based on sensor data, writing value 0 (min) or > > 255 (max) to /sys/class/backlight/radeon_bl/brightness turn > > off display. > Ok, that's weird. 0 turns off the panel by design, 255 should > not... But when ALS is disabled 0 did not turn display off. > > All > > other values (1-254) are OK (adjust brightness level). When I > > turn off Ambient Light Sensor (via hp-wmi kernel module) then > > values 0 and 255 also set brightness level (min and max). My > > suggestion is to convert value 0 to 1 and 255 to 254 to > > prevent this problem. > > No idea what's going on here... might be some weird vendor > magic. The WMI code is rather obscure... > > Luca ACPI/WMI cannot change brightness, see this what doing that ALS function: http://lists.freedesktop.org/archives/dri-devel/2012- March/020416.html -- Pali Roh?r pali.rohar at gmail.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120731/10ea5fbb/attachment-0001.pgp>
[PATCH] drm: refcnt drm_framebuffer
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: > From: Rob Clark > > This simplifies drm fb lifetime, and if the crtc/plane needs to hold > a ref to the fb when disabling a pipe until the next vblank, this > avoids the need to make disabling an overlay synchronous. This is a > problem that shows up when userspace is using a drm plane to > implement a hw cursor.. making overlay disable synchronous causes > a performance problem when x11 is rapidly enabling/disabling the > hw cursor. But not making it synchronous opens up a race condition > for crashing if userspace turns around and immediately deletes the > fb. Refcnt'ing the fb makes it possible to solve this problem. Presumably you have a follow-on patch putting the new refcnt to use so that we can judge whether you truly need refcnting on the fb itself in addition to the refcnted object and the various hw bookkeeping that needs to be performed? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h deleted file mode 100644 index 4c3647f..000 --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h +++ /dev/null @@ -1,159 +0,0 @@ -/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h - * - * Copyright 2008 Openmoko, Inc. - * Copyright 2008 Simtec Electronics - * http://armlinux.simtec.co.uk/ - * Ben Dooks - * - * S3C64XX - new-style framebuffer register definitions - * - * This is the register set for the new style framebuffer interface - * found from the S3C2443 onwards and specifically the S3C64XX series - * S3C6400 and S3C6410. - * - * The file contains the cpu specific items which change between whichever - * architecture is selected. See for the core definitions - * that are the same. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. -*/ - -/* include the core definitions here, in case we really do need to - * override them at a later date. -*/ - -#include - -#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */ -#define VIDCON1_FSTATUS_EVEN (1 << 15) - -/* Video timing controls */ -#define VIDTCON0 (0x10) -#define VIDTCON1 (0x14) -#define VIDTCON2 (0x18) - -/* Window position controls */ - -#define WINCON(_win) (0x20 + ((_win) * 4)) - -/* OSD1 and OSD4 do not have register D */ - -#define VIDOSD_BASE(0x40) - -#define VIDINTCON0 (0x130) - -/* WINCONx */ - -#define WINCONx_CSCWIDTH_MASK (0x3 << 26) -#define WINCONx_CSCWIDTH_SHIFT (26) -#define WINCONx_CSCWIDTH_WIDE (0x0 << 26) -#define WINCONx_CSCWIDTH_NARROW(0x3 << 26) - -#define WINCONx_ENLOCAL(1 << 22) -#define WINCONx_BUFSTATUS (1 << 21) -#define WINCONx_BUFSEL (1 << 20) -#define WINCONx_BUFAUTOEN (1 << 19) -#define WINCONx_YCbCr (1 << 13) - -#define WINCON1_LOCALSEL_CAMIF (1 << 23) - -#define WINCON2_LOCALSEL_CAMIF (1 << 23) -#define WINCON2_BLD_PIX(1 << 6) - -#define WINCON2_ALPHA_SEL (1 << 1) -#define WINCON2_BPPMODE_MASK (0xf << 2) -#define WINCON2_BPPMODE_SHIFT (2) -#define WINCON2_BPPMODE_1BPP (0x0 << 2) -#define WINCON2_BPPMODE_2BPP (0x1 << 2) -#define WINCON2_BPPMODE_4BPP (0x2 << 2) -#define WINCON2_BPPMODE_8BPP_1232 (0x4 << 2) -#define WINCON2_BPPMODE_16BPP_565 (0x5 << 2) -#define WINCON2_BPPMODE_16BPP_A1555(0x6 << 2) -#define WINCON2_BPPMODE_16BPP_I1555(0x7 << 2) -#define WINCON2_BPPMODE_18BPP_666 (0x8 << 2) -#define WINCON2_BPPMODE_18BPP_A1665(0x9 << 2) -#define WINCON2_BPPMODE_19BPP_A1666(0xa << 2) -#define WINCON2_BPPMODE_24BPP_888 (0xb << 2) -#define WINCON2_BPPMODE_24BPP_A1887(0xc << 2) -#define WINCON2_BPPMODE_25BPP_A1888(0xd << 2) -#define WINCON2_BPPMODE_28BPP_A4888(0xd << 2) - -#define WINCON3_BLD_PIX(1 << 6) - -#define WINCON3_ALPHA_SEL (1 << 1) -#define WINCON3_BPPMODE_MASK (0xf << 2) -#define WINCON3_BPPMODE_SHIFT (2) -#define WINCON3_BPPMODE_1BPP (0x0 << 2) -#define WINCON3_BPPMODE_2BPP (0x1 << 2) -#define WINCON3_BPPMODE_4BPP (0x2 << 2) -#define WINCON3_BPPMODE_16BPP_565 (0x5 << 2) -#define WINCON3_BPPMODE_16BPP_A1555(0x6 << 2) -#define WINCON3_BPPMODE_16BPP_I1555(0x7 << 2) -#define WINCON3_BPPMODE_18BPP_666 (0x8 << 2) -#define WINCON3_BPPMODE_18BPP_A1665(0x9 << 2) -#define WINCON3_BPPMODE_19BPP_A1666(0xa << 2) -#define WINCON3_BPPMODE_24BPP_888 (0xb << 2) -#define WINCON3_BPPMODE_24BPP_A1887(0xc << 2) -#define WINCON3_BPPMODE_25BPP_A1888(0xd << 2) -#define WINCON3_BPPMODE_28BPP_A4888(0xd << 2) - -#define VIDINTCON0_FIFIOSEL_WINDOW2(0
[PATCH V2 4/5] driver: Include the modified FIMD header file
The fimd register headers have been moved to include/video/ hence, modifying the driver files accordingly. Signed-off-by: Leela Krishna Amudala --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 29fdbfe..8da90f9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -20,7 +20,7 @@ #include #include -#include +#include #include "exynos_drm_drv.h" #include "exynos_drm_fbdev.h" diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c index 69bf9d0..1226fdd 100644 --- a/drivers/video/s3c-fb.c +++ b/drivers/video/s3c-fb.c @@ -26,7 +26,7 @@ #include #include -#include +#include #include /* This driver will export a number of framebuffer interfaces depending -- 1.7.0.4
[PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
The fimd register headers have been moved to include/video/ hence, modifying the machine files accordingly. Signed-off-by: Leela Krishna Amudala --- arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- 22 files changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index f98a83a..573a0c4 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -39,7 +39,7 @@ #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c index 5a12dc2..c69707e 100644 --- a/arch/arm/mach-exynos/mach-origen.c +++ b/arch/arm/mach-exynos/mach-origen.c @@ -31,7 +31,7 @@ #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c index b26beb1..8a8acff 100644 --- a/arch/arm/mach-exynos/mach-smdk4x12.c +++ b/arch/arm/mach-exynos/mach-smdk4x12.c @@ -35,7 +35,7 @@ #include #include #include -#include +#include #include #include diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c index 3cfa688..c2df6e8 100644 --- a/arch/arm/mach-exynos/mach-smdkv310.c +++ b/arch/arm/mach-exynos/mach-smdkv310.c @@ -28,7 +28,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c index 4d1f40d..e6fb471 100644 --- a/arch/arm/mach-exynos/mach-universal_c210.c +++ b/arch/arm/mach-exynos/mach-universal_c210.c @@ -39,7 +39,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-exynos/setup-fimd0.c b/arch/arm/mach-exynos/setup-fimd0.c index 07a6dbe..53c4c51 100644 --- a/arch/arm/mach-exynos/setup-fimd0.c +++ b/arch/arm/mach-exynos/setup-fimd0.c @@ -14,7 +14,7 @@ #include #include -#include +#include #include diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c b/arch/arm/mach-s3c24xx/mach-smdk2416.c index c3100a0..c8d5f51 100644 --- a/arch/arm/mach-s3c24xx/mach-smdk2416.c +++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c @@ -52,7 +52,7 @@ #include #include -#include +#include #include #include diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c b/arch/arm/mach-s3c64xx/mach-anw6410.c index ffa29dd..27e3087 100644 --- a/arch/arm/mach-s3c64xx/mach-anw6410.c +++ b/arch/arm/mach-s3c64xx/mach-anw6410.c @@ -44,7 +44,7 @@ #include #include #include -#include +#include #include #include diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c index 09cd812..66e8c69 100644 --- a/arch/arm/mach-s3c64xx/mach-crag6410.c +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c @@ -57,7 +57,7 @@ #include #include -#include +#include #include #include #include diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c index 6890881..ab78c5e 100644 --- a/arch/arm/mach-s3c64xx/mach-hmt.c +++ b/arch/arm/mach-s3c64xx/mach-hmt.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include "common.h" diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c index 5539a25..4b9a9ff 100644 --- a/arch/arm/mach-s3c64xx/mach-mini6410.c +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c @@ -41,7 +41,7 @@ #include #include #include -#include +#include #include diff --git a/arch/arm/mach-s3c64xx/mach-ncp.c b/arch/arm/mach-s3c64xx/mach-ncp.c index cad2e05..d4c8af0 100644 --- a/arch/arm/mach-s3c64xx/mach-ncp.c +++ b/arch/arm/mach-s3c64xx/mach-ncp.c @@ -43,7 +43,7 @@ #include #include #include -#include +#include #include "common.h" diff --git a/arch/arm/mach-s3c64x
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Exynos5 has VIDTCON and VIDCON registers at different offsets from the previous SOCs. Hence, adding the macros. Signed-off-by: Leela Krishna Amudala --- include/video/samsung_fimd.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index e979f42..820f190 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -524,3 +524,10 @@ * 1110-none- -none- -none- -none--none- * -none- -none- -none- -none--none- */ + +/*EXYNOS5 FIMD REG OFFSET */ +#define EXYNOS5_VIDTCON0 (0x20010) +#define EXYNOS5_VIDTCON1 (0x20014) +#define EXYNOS5_VIDTCON2 (0x20018) +#define EXYNOS5_VIDTCON3 (0x2001C) +#define EXYNOS5_VIDCON1(0x20004) -- 1.7.0.4
[PATCH V2 1/5] include/video: Add samsung FIMD register header
This patch copies the contents from regs-fb-v4.h and regs-fb.h to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala --- include/video/samsung_fimd.h | 526 ++ 1 files changed, 526 insertions(+), 0 deletions(-) create mode 100644 include/video/samsung_fimd.h diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h new file mode 100644 index 000..e979f42 --- /dev/null +++ b/include/video/samsung_fimd.h @@ -0,0 +1,526 @@ +/* include/video/samsung_fimd.h + * + * Copyright 2008 Openmoko, Inc. + * Copyright 2008 Simtec Electronics + * http://armlinux.simtec.co.uk/ + * Ben Dooks + * + * S3C Platform - new-style fimd and framebuffer register definitions + * + * This is the register set for the fimd and new style framebuffer interface + * found from the S3C2443 onwards into the S3C2416, S3C2450 and the + * S3C64XX series such as the S3C6400 and S3C6410. + * + * The file does not contain the cpu specific items which are based on + * whichever architecture is selected, it only contains the core of the + * register set. See to get the specifics. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. +*/ + +/* VIDCON0 */ + +#define VIDCON0(0x00) +#define VIDCON0_INTERLACE (1 << 29) +#define VIDCON0_VIDOUT_MASK(0x3 << 26) +#define VIDCON0_VIDOUT_SHIFT (26) +#define VIDCON0_VIDOUT_RGB (0x0 << 26) +#define VIDCON0_VIDOUT_TV (0x1 << 26) +#define VIDCON0_VIDOUT_I80_LDI0(0x2 << 26) +#define VIDCON0_VIDOUT_I80_LDI1(0x3 << 26) + +#define VIDCON0_L1_DATA_MASK (0x7 << 23) +#define VIDCON0_L1_DATA_SHIFT (23) +#define VIDCON0_L1_DATA_16BPP (0x0 << 23) +#define VIDCON0_L1_DATA_18BPP16(0x1 << 23) +#define VIDCON0_L1_DATA_18BPP9 (0x2 << 23) +#define VIDCON0_L1_DATA_24BPP (0x3 << 23) +#define VIDCON0_L1_DATA_18BPP (0x4 << 23) +#define VIDCON0_L1_DATA_16BPP8 (0x5 << 23) + +#define VIDCON0_L0_DATA_MASK (0x7 << 20) +#define VIDCON0_L0_DATA_SHIFT (20) +#define VIDCON0_L0_DATA_16BPP (0x0 << 20) +#define VIDCON0_L0_DATA_18BPP16(0x1 << 20) +#define VIDCON0_L0_DATA_18BPP9 (0x2 << 20) +#define VIDCON0_L0_DATA_24BPP (0x3 << 20) +#define VIDCON0_L0_DATA_18BPP (0x4 << 20) +#define VIDCON0_L0_DATA_16BPP8 (0x5 << 20) + +#define VIDCON0_PNRMODE_MASK (0x3 << 17) +#define VIDCON0_PNRMODE_SHIFT (17) +#define VIDCON0_PNRMODE_RGB(0x0 << 17) +#define VIDCON0_PNRMODE_BGR(0x1 << 17) +#define VIDCON0_PNRMODE_SERIAL_RGB (0x2 << 17) +#define VIDCON0_PNRMODE_SERIAL_BGR (0x3 << 17) + +#define VIDCON0_CLKVALUP (1 << 16) +#define VIDCON0_CLKVAL_F_MASK (0xff << 6) +#define VIDCON0_CLKVAL_F_SHIFT (6) +#define VIDCON0_CLKVAL_F_LIMIT (0xff) +#define VIDCON0_CLKVAL_F(_x) ((_x) << 6) +#define VIDCON0_VLCKFREE (1 << 5) +#define VIDCON0_CLKDIR (1 << 4) + +#define VIDCON0_CLKSEL_MASK(0x3 << 2) +#define VIDCON0_CLKSEL_SHIFT (2) +#define VIDCON0_CLKSEL_HCLK(0x0 << 2) +#define VIDCON0_CLKSEL_LCD (0x1 << 2) +#define VIDCON0_CLKSEL_27M (0x3 << 2) + +#define VIDCON0_ENVID (1 << 1) +#define VIDCON0_ENVID_F(1 << 0) + +#define VIDCON1(0x04) +#define VIDCON1_LINECNT_MASK (0x7ff << 16) +#define VIDCON1_LINECNT_SHIFT (16) +#define VIDCON1_LINECNT_GET(_v)(((_v) >> 16) & 0x7ff) +#define VIDCON1_VSTATUS_MASK (0x3 << 13) +#define VIDCON1_VSTATUS_SHIFT (13) +#define VIDCON1_VSTATUS_VSYNC (0x0 << 13) +#define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13) +#define VIDCON1_VSTATUS_ACTIVE (0x2 << 13) +#define VIDCON1_VSTATUS_FRONTPORCH (0x0 << 13) +#define VIDCON1_VCLK_MASK (0x3 << 9) +#define VIDCON1_VCLK_HOLD (0x0 << 9) +#define VIDCON1_VCLK_RUN (0x1 << 9) + +#define VIDCON1_INV_VCLK (1 << 7) +#define VIDCON1_INV_HSYNC (1 << 6) +#define VIDCON1_INV_VSYNC (1 << 5) +#define VIDCON1_INV_VDEN (1
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. Changes from version 1: - Split the patches as per Sylwester comments - Changed FIMD_V8_xxx macro to EXYNOS5_xxx Leela Krishna Amudala (5): include/video: Add samsung FIMD register header include/video: Add Exynos5 specific FIMD register offsets arm: samsung: Include the modified FIMD header file driver: Include the modified FIMD header file arm: samsung: delete frame buffer header files from platform arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h => include/video/samsung_fimd.h (74%)
Fwd: Brightness on HP EliteBook 8460p
I'm putting back the CC and adding Alex. On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r wrote: > Thanks, now working. When I write to acpi video brightness file > it change brightness and in dmesg is: > > [ 47.200998] [drm:radeon_atif_handler], event, device_class = > video, type = 0xd0 > [ 47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS > pending requests: 0x80 > [ 47.201104] [drm:radeon_atif_handler], ATIF: 1 pending SBIOS > requests > [ 47.201105] [drm:radeon_atif_handler], Changing brightness to > 11 Great! I'll send an updated patch to Alex soon. > I think that acpi only sent event about brightness key pressed, > because nothing happened when I pressed it. > > Also for windows is needed special HP application (hp hotkey) for > brightness keys. Without it brightness keys not working too... I've looked at hp-wmi: the hotkey is indeed dispatched via WMI (hp-wmi) so you need something in userspace (KDE, Gnome, etc) to respond to that key press. > And there is one problem with /sys/class/backlight/radeon_bl. > When I enable Ambient Light Sensor which auto adjust brightness > based on sensor data, writing value 0 (min) or 255 (max) to > /sys/class/backlight/radeon_bl/brightness turn off display. Ok, that's weird. 0 turns off the panel by design, 255 should not... > All > other values (1-254) are OK (adjust brightness level). When I > turn off Ambient Light Sensor (via hp-wmi kernel module) then > values 0 and 255 also set brightness level (min and max). My > suggestion is to convert value 0 to 1 and 255 to 254 to prevent > this problem. No idea what's going on here... might be some weird vendor magic. The WMI code is rather obscure... Luca
[PATCH] drm/radeon: Remove unused functions
This applies on top of drm/radeon: Mark all possible functions / structs as
static.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 44 ---
drivers/gpu/drm/radeon/radeon_combios.c |9 -
drivers/gpu/drm/radeon/radeon_fb.c | 16 --
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5 ---
4 files changed, 0 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index b51fc49..ff9b692 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2544,50 +2544,6 @@ static void r100_errata(struct radeon_device *rdev)
}
}
-/* Wait for vertical sync on primary CRTC */
-static void r100_gpu_wait_for_vsync(struct radeon_device *rdev)
-{
- uint32_t crtc_gen_cntl, tmp;
- int i;
-
- crtc_gen_cntl = RREG32(RADEON_CRTC_GEN_CNTL);
- if ((crtc_gen_cntl & RADEON_CRTC_DISP_REQ_EN_B) ||
- !(crtc_gen_cntl & RADEON_CRTC_EN)) {
- return;
- }
- /* Clear the CRTC_VBLANK_SAVE bit */
- WREG32(RADEON_CRTC_STATUS, RADEON_CRTC_VBLANK_SAVE_CLEAR);
- for (i = 0; i < rdev->usec_timeout; i++) {
- tmp = RREG32(RADEON_CRTC_STATUS);
- if (tmp & RADEON_CRTC_VBLANK_SAVE) {
- return;
- }
- DRM_UDELAY(1);
- }
-}
-
-/* Wait for vertical sync on secondary CRTC */
-static void r100_gpu_wait_for_vsync2(struct radeon_device *rdev)
-{
- uint32_t crtc2_gen_cntl, tmp;
- int i;
-
- crtc2_gen_cntl = RREG32(RADEON_CRTC2_GEN_CNTL);
- if ((crtc2_gen_cntl & RADEON_CRTC2_DISP_REQ_EN_B) ||
- !(crtc2_gen_cntl & RADEON_CRTC2_EN))
- return;
-
- /* Clear the CRTC_VBLANK_SAVE bit */
- WREG32(RADEON_CRTC2_STATUS, RADEON_CRTC2_VBLANK_SAVE_CLEAR);
- for (i = 0; i < rdev->usec_timeout; i++) {
- tmp = RREG32(RADEON_CRTC2_STATUS);
- if (tmp & RADEON_CRTC2_VBLANK_SAVE) {
- return;
- }
- DRM_UDELAY(1);
- }
-}
-
static int r100_rbbm_fifo_wait_for_entry(struct radeon_device *rdev, unsigned
n)
{
unsigned i;
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index c2bfac2..fe225cc 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -3304,15 +3304,6 @@ static void combios_write_ram_size(struct drm_device
*dev)
WREG32(RADEON_CONFIG_MEMSIZE, mem_size);
}
-static void radeon_combios_dyn_clk_setup(struct drm_device *dev, int enable)
-{
- uint16_t dyn_clk_info =
- combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE);
-
- if (dyn_clk_info)
- combios_parse_pll_table(dev, dyn_clk_info);
-}
-
void radeon_combios_asic_init(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index 8b088ca..6ada72c 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -316,22 +316,6 @@ static int radeon_fb_find_or_create_single(struct
drm_fb_helper *helper,
return new_fb;
}
-static char *mode_option;
-static int radeon_parse_options(char *options)
-{
- char *this_opt;
-
- if (!options || !*options)
- return 0;
-
- while ((this_opt = strsep(&options, ",")) != NULL) {
- if (!*this_opt)
- continue;
- mode_option = this_opt;
- }
- return 0;
-}
-
void radeon_fb_output_poll_changed(struct radeon_device *rdev)
{
drm_fb_helper_hotplug_event(&rdev->mode_info.rfbdev->helper);
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 31022c2..08a60bd 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -206,11 +206,6 @@ static void radeon_legacy_rmx_mode_set(struct drm_crtc
*crtc,
WREG32(RADEON_FP_CRTC_V_TOTAL_DISP, fp_crtc_v_total_disp);
}
-static void radeon_restore_common_regs(struct drm_device *dev)
-{
- /* don't need this yet */
-}
-
static void radeon_pll_wait_for_read_update_complete(struct drm_device *dev)
{
struct radeon_device *rdev = dev->dev_private;
--
1.7.2.1
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Tue, Jul 31, 2012 at 4:05 PM, Luca Tettamanti wrote: > On Tue, Jul 31, 2012 at 09:58:04AM -0400, Alex Deucher wrote: >> On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti >> wrote: >> > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher >> > wrote: >> >> Regarding patches 3 and 4, it might be easier to just store a pointer >> >> to the relevant encoder when you verify ATIF rather than walking the >> >> encoder list every time. > > Done. > >> > Makes sense, I was unsure about the lifetime of the encoders, but >> > AFAICS they're destroyed only when the module in unloaded. >> >> They are present for the life of the driver. > > I had to move to call to radeon_acpi_init after radeon_modeset_init, > otherwise the encoders are not present yet (the tear down code path is > correct, acpi first, then modeset). > Latest and greatest version is attached; I fixed notifications when > using custom command codes (tested by Pali Roh?r) and implemented your > suggestion. Patches look good. I picked them up and combined them with may patches plus a few other small fixes. They are available here: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches Let me know what you think. Alex
Massive power regression going 3.4->3.5
On Tue, 2012-07-31 at 16:09 +0100, James Bottomley wrote: > On Tue, 2012-07-31 at 07:27 -0700, Keith Packard wrote: > > James Bottomley writes: > > > > > on 3.5 killing X causes idle power to go 14W -> 5.9W > > > on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W > > > > That's actually pretty good news -- you're just not getting to RC6 > > when X is running, but RC6 is otherwise working. And, yes, the GPU > > really can suck that much power. The debug info that Chris pointed you > > at should tell a more complete story. For comparison, on my sandybridge > > box this morning: > > Well, I don't know what it means, but I have a culprit from bisect (I > managed to manually verify the bisection heads which would step back > into 3.3). > > 2911a35b2e4eb87ec48d03aeb11f019e51ae3c0d is the first bad commit > commit 2911a35b2e4eb87ec48d03aeb11f019e51ae3c0d > Author: Ben Widawsky > Date: Thu Apr 5 14:47:36 2012 -0700 > > drm/i915: use semaphores for the display plane > > I'm going to try building 3.5 with this reverted (it doesn't revert > cleanly). OK, I confirm that reverting this patch in 3.5 recovers a ~6.5W idle power. James
[PATCH 2/2] drm/radeon: fix bank tiling parameters on SI
On 31.07.2012 16:42, Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 10:21 AM, Christian K?nig
> wrote:
>> On 31.07.2012 16:02, Alex Deucher wrote:
>>> On Tue, Jul 31, 2012 at 7:48 AM, Christian K?nig
>>> wrote:
The sixteen bank case wasn't handled here, leading to GPU
crashes because of userspace miscalculation.
>>> You mean a GPU hang or a segfault in userspace? IIRC, from the hw
>>> perspective numbers of banks over 8 are considered 8 for tiling.
>> Well it was a GPU segfault :) The GPU was accessing memory regions that
>> weren't VM mapped.
>>
>> As far as i could figure it out it wasn't happy with the alignment of the
>> color buffer. The number of banks we used for that calculation seemed to be
>> different from what the kernel programmed into the tiling config registers.
>> So I tried changing it from 8 to 16 and hurray it started working (ok, more
>> or less currently digging into the next problem).
>>
>> It is possible that this is just masquerading another bug, but as far as I
>> can see it is the most logical explanation.
> Seems reasonable.
>
> Reviewed-by: Alex Deucher
>
>> Why are 16 banks equal to 8 banks on the hw side?
> I was talking to one of the hw guys about some issues with tiling.
> Certain 6xx or 7xx chips report more than 8 banks in the MC config,
> but the tiling configuration on them only supports 4 and 8 banks.
> IIRC, he said number of banks above 8 should be treated as 8 at least
> for 6xx-9xx. Although, looking at it again it looks like maybe we
> want 16 bank support for evergreen/cayman as well after all. It
> shouldn't hurt other than possibly over allocating a bit.
The alternative is to reduce the number of banks in the gb_tile_mode* regs.
I should also note that I have encountered a couple of more problems
with SI and 16 banks, they go away if I reduce the banks to 8. Not sure
what the reason is but it is possible that our surface_manager can't
handle 16 banks yet.
So be careful if you enable that for cayman and evergreen.
Cheers,
Christian.
>
> Alex
>
>> Christian.
>>
>>
>>> Alex
>>>
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/si.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 0b02792..0182fc8 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -1639,11 +1639,19 @@ static void si_gpu_init(struct radeon_device
*rdev)
/* XXX what about 12? */
rdev->config.si.tile_config |= (3 << 0);
break;
- }
- if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
- rdev->config.si.tile_config |= 1 << 4;
- else
+ }
+ switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
+ case 0: /* four banks */
rdev->config.si.tile_config |= 0 << 4;
+ break;
+ case 1: /* eight banks */
+ rdev->config.si.tile_config |= 1 << 4;
+ break;
+ case 2: /* sixteen banks */
+ default:
+ rdev->config.si.tile_config |= 2 << 4;
+ break;
+ }
rdev->config.si.tile_config |=
((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
rdev->config.si.tile_config |=
--
1.7.9.5
___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
[PATCH 1/3] Move FIMD register headers to include/video/
On Tuesday, July 31, 2012 3:28 PM Marek Szyprowski wrote:
>
> Hello,
>
> On Tuesday, July 31, 2012 2:48 AM Jingoo Han wrote:
>
> > On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote:
> > >
> > > Hello Jingoo Han,
> > >
> > > On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han
> > > wrote:
> > > > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote:
> > > >>
> > > >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> > > >> to include/video/samsung_fimd.h
> > > >>
> > > >> Signed-off-by: Leela Krishna Amudala
> > > >> ---
> > > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 ---
> > > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403
> > > >> -
> > > >> include/video/samsung_fimd.h| 533
> > > >> +++
> > > >> 3 files changed, 533 insertions(+), 562 deletions(-)
> > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
> > > >> create mode 100644 include/video/samsung_fimd.h
> > > >>
> > > >> +*/
> > > >> +
> > > >> +/*FIMD V8 REG OFFSET */
> > > >> +#define FIMD_V8_VIDTCON0 (0x20010)
> > > >> +#define FIMD_V8_VIDTCON1 (0x20014)
> > > >> +#define FIMD_V8_VIDTCON2 (0x20018)
> > > >> +#define FIMD_V8_VIDTCON3 (0x2001C)
> > > >> +#define FIMD_V8_VIDCON1 (0x20004)
> >
> >
> > How about using soc_is_exynos5250()?
> >
> > +#define VIDTCON0 (soc_is_exynos5250() ? \
> > + (0x20010) : (0x10))
> >
> > In this case, the FIMD driver does not need to change.
> > Also, one binary is available.
>
> Please don't mix two methods of runtime detection. FIMD driver (s3c-fb)
> already
> has runtime hw detection based on platform device id. Adding such detection
> for
> exynos5 to DRM FIMD driver should not be a big issue too.
Marek,
Then, do you want use like this?
#define VIDTCON0(0x10)
+#define FIMD_V8_VIDTCON0 (0x20010)
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1924,7 +1924,7 @@ static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
.variant = {
.nr_windows = 5,
- .vidtcon= VIDTCON0,
+ .vidtcon= FIMD_V8_VIDTCON0,
>
> Best regards
> --
> Marek Szyprowski
> Samsung Poland R&D Center
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 17:03:52 Rob Clark, vous avez ?crit : > On Tue, Jul 31, 2012 at 8:39 AM, R?mi Denis-Courmont wrote: > > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit : > >> > For that matter, wouldn't it be useful to support exporting a userptr > >> > buffer at some point in the future? > >> > >> Shouldn't USERPTR usage be discouraged once we get dma-buf support ? > > > > USERPTR, where available, is currently the only way to perform zero-copy > > from kernel to userspace. READWRITE does not support zero-copy at all. > > MMAP only supports zero-copy if userspace knows a boundary on the number > > of concurrent buffers *and* the device can deal with that number of > > buffers; in general, MMAP requires memory copying. > > hmm, this sounds like the problem is device pre-allocating buffers? Basically, yes. > Anyways, last time I looked, the vb2 core supported changing dmabuf fd > each time you QBUF, in a similar way to what you can do w/ userptr. > So that seems to get you the advantages you miss w/ mmap without the > pitfalls of userptr. It might work albeit with a higher system calls count overhead. But what about libv4l2 transparent format conversion? Emulated USERBUF, with MMAP in the back-end would provide by far the least overhead. I don't see how DMABUF would work there. -- R?mi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis
[PATCH 1/3] Move FIMD register headers to include/video/
On Tuesday, July 31, 2012 3:37 PM, Tomasz Figa wrote: > > Hi, > > On Tuesday 31 of July 2012 at 09:47:57, Jingoo Han wrote: > > On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: > > > Hello Jingoo Han, > > > > > > On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han > > > wrote: > > > > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: > > > >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side > > > >> to include/video/samsung_fimd.h > > > >> > > > >> Signed-off-by: Leela Krishna Amudala > > > >> --- > > > >> > > > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- > > > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 > > > >> - > > > >> include/video/samsung_fimd.h| 533 > > > >> +++ 3 files changed, 533 insertions(+), 562 > > > >> deletions(-) > > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > > > >> create mode 100644 include/video/samsung_fimd.h > > > >> > > > >> +*/ > > > >> + > > > >> +/*FIMD V8 REG OFFSET */ > > > >> +#define FIMD_V8_VIDTCON0 (0x20010) > > > >> +#define FIMD_V8_VIDTCON1 (0x20014) > > > >> +#define FIMD_V8_VIDTCON2 (0x20018) > > > >> +#define FIMD_V8_VIDTCON3 (0x2001C) > > > >> +#define FIMD_V8_VIDCON1 (0x20004) > > > > How about using soc_is_exynos5250()? > > > > +#define VIDTCON0 (soc_is_exynos5250() ? \ > > + (0x20010) : (0x10)) > > > > In this case, the FIMD driver does not need to change. > > Also, one binary is available. > > > > This would look good indeed, but there are some drawbacks: > - it would not scale nicely for future SoCs using the new FIMD I don't think so. Currently, one clear thing is that only Exynos5250 FIMD has VIDTCON0 offset with 0x2. We cannot know whether future SoCs have VIDTCON0 offset with 0x2. Also, VIDTCON offset is not relevant to FIMD version. There was the case that FIMD version 7 has VIDTCON0 offset with 0x2. > - it would add the overhead of checking SoC ID for every access to affected > registers (at least 1 load, 1 AND, 1 compare, 1 move and 1 conditional OR, so > 5 instructions in total, possibly even more, as opposed to a single load from > a variant struct). I don't think that it's critical. VIDTCON registers are used for controlling LCD timing values. These registers are just used for probing and resuming. It is not used at running time. Anyway, your point would be considered. Thank you. > > I would stay with the way used in s3c-fb driver, using variant structs > describing FIMD revisions. > > Best regards, > Tomasz Figa > > > > > Best regards, > > Jingoo Han > > > > > > CC'ed Marek. > > > > > > > > To Leela Krishna Amudala, > > > > > > > > Don't add these definitions for FIMD_V8_xxx registers, which arenot > > > > related to current "regs-fb-v4.h> > > > and regs-fb.h". > > > > > > > Just "move" and "merge" regs-fb-v4.h and regs-fb.h to one header file, > > > > not "add" new definitions. If you want to add these definitions, please > > > > make new patch for this.> > > > Will do it in the suggested way, > > > > > > > Also, "#define FIMD_V8_xxx" is ugly. > > > > I think that there is better way. > > > > Please, find other way. > > > > > > I used FIMD_V8_xxx instead of EXYNOS5_FIMD_*, because in future, > > > there is a possibility that version 8 FIMD can be used in other > > > application processors also. > > > Thanks for reviewing the patch. > > > > > > Best Wishes, > > > Leela Krishna. > > > > > > >> -- > > > >> 1.7.0.4 > > > > > > > > -- > > > > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" > > > > in > > > > the body of a message to majordomo at vger.kernel.org > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > > in the body of a message to majordomo at vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm/radeon: fix fence related segfault in CS
On 31.07.2012 16:47, Michel D?nzer wrote:
> On Die, 2012-07-31 at 13:48 +0200, Christian K?nig wrote:
>> Don't return success if scheduling the IB fails, otherwise
>> we end up with an oops in ttm_eu_fence_buffer_objects.
>>
>> Signed-off-by: Christian K?nig
>> Reviewed-by: Alex Deucher
>> Cc: stable at vger.kernel.org
>> ---
>> drivers/gpu/drm/radeon/radeon_cs.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
>> b/drivers/gpu/drm/radeon/radeon_cs.c
>> index 142f894..17238f4 100644
>> --- a/drivers/gpu/drm/radeon/radeon_cs.c
>> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
>> @@ -377,7 +377,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
>> if (r) {
>> DRM_ERROR("Failed to schedule IB !\n");
>> }
>> -return 0;
>> +return r;
>> }
>>
>> static int radeon_bo_vm_update_pte(struct radeon_cs_parser *parser,
> AFAICT this fix is already in Linus' tree (commit
> 93bf888c5c730605e3470f5d2381f296eda88d79).
Your right, but why the heck isn't it in drm-fixes?
Christian.
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Hello. On 31-07-2012 16:23, Leela Krishna Amudala wrote: > Exynos5 has VIDTCON and VIDCON registers at different offsets > from the previous SOCs. Hence, adding the macros. > Signed-off-by: Leela Krishna Amudala > --- > include/video/samsung_fimd.h |7 +++ > 1 files changed, 7 insertions(+), 0 deletions(-) > diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h > index e979f42..820f190 100644 > --- a/include/video/samsung_fimd.h > +++ b/include/video/samsung_fimd.h > @@ -524,3 +524,10 @@ >* 1110 -none- -none- -none- -none--none- >* -none- -none- -none- -none--none- > */ > + > +/*EXYNOS5 FIMD REG OFFSET */ > +#define EXYNOS5_VIDTCON0 (0x20010) > +#define EXYNOS5_VIDTCON1 (0x20014) > +#define EXYNOS5_VIDTCON2 (0x20018) > +#define EXYNOS5_VIDTCON3 (0x2001C) > +#define EXYNOS5_VIDCON1 (0x20004) Parens not needed around simple literals. WBR, Sergei
[PATCH 1/2] drm/radeon: fix fence related segfault in CS
On Die, 2012-07-31 at 13:48 +0200, Christian K?nig wrote:
> Don't return success if scheduling the IB fails, otherwise
> we end up with an oops in ttm_eu_fence_buffer_objects.
>
> Signed-off-by: Christian K?nig
> Reviewed-by: Alex Deucher
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_cs.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 142f894..17238f4 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -377,7 +377,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
> if (r) {
> DRM_ERROR("Failed to schedule IB !\n");
> }
> - return 0;
> + return r;
> }
>
> static int radeon_bo_vm_update_pte(struct radeon_cs_parser *parser,
AFAICT this fix is already in Linus' tree (commit
93bf888c5c730605e3470f5d2381f296eda88d79).
--
Earthling Michel D?nzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
[RFC 0/3] solving omapdrm/omapdss layering issues
r is there no clean way to do that, in > which case we should just copy the code we need into omapdrm, and > leave the deprecated omapdss as it is for legacy drivers. I agree that we need to get omapdrm work well, as it's (or will be) the most important display framework. And if managing that requires us to combine omapdss and omapdrm, I'm fine with it. But, again, so far I don't understand why it's so difficult to have them separate with omapdss giving notifications of important events, and also how combining the two drivers would fix any issues (though I agree it could simplify some code somewhat). So what I propose is first to look at the problems you have, so that I understand what the problem is with omapdss-omapdrm interaction. Tomi ------ next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120731/6b5a62be/attachment.pgp>
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez ?crit : > > For that matter, wouldn't it be useful to support exporting a userptr > > buffer at some point in the future? > > Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. I am not sure DMABUF even supports transmitting data efficiently to userspace. In my understanding, it's meant for transmitting data between DSP's bypassing userspace entirely, in other words the exact opposite of what USERBUF does. -- R?mi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis
Massive power regression going 3.4->3.5
On Tue, 31 Jul 2012 16:09:44 +0100, James Bottomley wrote: > On Tue, 2012-07-31 at 07:27 -0700, Keith Packard wrote: > > James Bottomley writes: > > > > > on 3.5 killing X causes idle power to go 14W -> 5.9W > > > on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W > > > > That's actually pretty good news -- you're just not getting to RC6 > > when X is running, but RC6 is otherwise working. And, yes, the GPU > > really can suck that much power. The debug info that Chris pointed you > > at should tell a more complete story. For comparison, on my sandybridge > > box this morning: > > Well, I don't know what it means, but I have a culprit from bisect (I > managed to manually verify the bisection heads which would step back > into 3.3). > > 2911a35b2e4eb87ec48d03aeb11f019e51ae3c0d is the first bad commit > commit 2911a35b2e4eb87ec48d03aeb11f019e51ae3c0d > Author: Ben Widawsky > Date: Thu Apr 5 14:47:36 2012 -0700 > > drm/i915: use semaphores for the display plane > > I'm going to try building 3.5 with this reverted (it doesn't revert > cleanly). The quick test would be to simply revert the i915_gem_object_pin_to_display_plane() hunk. That would help narrow down whether it is a side-efffect of using the semaphore to synchronize the pageflip, or if the existing code was broken as it was moved. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 2/2] drm/radeon: fix bank tiling parameters on SI
On 31.07.2012 16:02, Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 7:48 AM, Christian K?nig
> wrote:
>> The sixteen bank case wasn't handled here, leading to GPU
>> crashes because of userspace miscalculation.
> You mean a GPU hang or a segfault in userspace? IIRC, from the hw
> perspective numbers of banks over 8 are considered 8 for tiling.
Well it was a GPU segfault :) The GPU was accessing memory regions that
weren't VM mapped.
As far as i could figure it out it wasn't happy with the alignment of
the color buffer. The number of banks we used for that calculation
seemed to be different from what the kernel programmed into the tiling
config registers. So I tried changing it from 8 to 16 and hurray it
started working (ok, more or less currently digging into the next problem).
It is possible that this is just masquerading another bug, but as far as
I can see it is the most logical explanation.
Why are 16 banks equal to 8 banks on the hw side?
Christian.
>
> Alex
>
>> Signed-off-by: Christian K?nig
>> Cc: stable at vger.kernel.org
>> ---
>> drivers/gpu/drm/radeon/si.c | 16
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
>> index 0b02792..0182fc8 100644
>> --- a/drivers/gpu/drm/radeon/si.c
>> +++ b/drivers/gpu/drm/radeon/si.c
>> @@ -1639,11 +1639,19 @@ static void si_gpu_init(struct radeon_device *rdev)
>> /* XXX what about 12? */
>> rdev->config.si.tile_config |= (3 << 0);
>> break;
>> - }
>> - if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
>> - rdev->config.si.tile_config |= 1 << 4;
>> - else
>> + }
>> + switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
>> + case 0: /* four banks */
>> rdev->config.si.tile_config |= 0 << 4;
>> + break;
>> + case 1: /* eight banks */
>> + rdev->config.si.tile_config |= 1 << 4;
>> + break;
>> + case 2: /* sixteen banks */
>> + default:
>> + rdev->config.si.tile_config |= 2 << 4;
>> + break;
>> + }
>> rdev->config.si.tile_config |=
>> ((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
>> PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
>> rdev->config.si.tile_config |=
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Massive power regression going 3.4->3.5
On Tue, 2012-07-31 at 07:27 -0700, Keith Packard wrote: > James Bottomley writes: > > > on 3.5 killing X causes idle power to go 14W -> 5.9W > > on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W > > That's actually pretty good news -- you're just not getting to RC6 > when X is running, but RC6 is otherwise working. And, yes, the GPU > really can suck that much power. The debug info that Chris pointed you > at should tell a more complete story. For comparison, on my sandybridge > box this morning: Well, I don't know what it means, but I have a culprit from bisect (I managed to manually verify the bisection heads which would step back into 3.3). 2911a35b2e4eb87ec48d03aeb11f019e51ae3c0d is the first bad commit commit 2911a35b2e4eb87ec48d03aeb11f019e51ae3c0d Author: Ben Widawsky Date: Thu Apr 5 14:47:36 2012 -0700 drm/i915: use semaphores for the display plane I'm going to try building 3.5 with this reverted (it doesn't revert cleanly). James
[PATCH] i915: don't map imported dma-bufs for dmar.
From: Dave Airlie The exporter should have given us pages in the correct place, avoid the prepare object mapping phase on dmar systems. This fixes an oops on a GM45/R600 machine, when running the intel/radeon tests. Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 9fd25a4..ee9b68f 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -361,7 +361,8 @@ int i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj) struct drm_device *dev = obj->base.dev; struct drm_i915_private *dev_priv = dev->dev_private; - if (dev_priv->mm.gtt->needs_dmar) + /* don't map imported dma buf objects */ + if (dev_priv->mm.gtt->needs_dmar && !obj->sg_table) return intel_gtt_map_memory(obj->pages, obj->base.size >> PAGE_SHIFT, &obj->sg_list, -- 1.7.11.2
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #70 from Alex Deucher 2012-07-31 15:10:38 UTC --- Does this kernel patch help? http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Hi, On 07/31/2012 02:51 PM, Sergei Shtylyov wrote: >> +/*EXYNOS5 FIMD REG OFFSET */ How about changing it to, e.g. /* EXYNOS5 specific register offset definitions */ (but just in case you happen to resend this patch series) >> +#define EXYNOS5_VIDTCON0(0x20010) >> +#define EXYNOS5_VIDTCON1(0x20014) >> +#define EXYNOS5_VIDTCON2(0x20018) >> +#define EXYNOS5_VIDTCON3(0x2001C) >> +#define EXYNOS5_VIDCON1(0x20004) > >Parens not needed around simple literals. Yes, I agree it looks insane. But, I think we could allow this for consistency with the remaining definitions. -- Regards, Sylwester
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Rémi, On Tuesday 31 July 2012 21:39:40 Rémi Denis-Courmont wrote: > Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez écrit : > > On Tuesday 31 July 2012 16:39:00 Rémi Denis-Courmont wrote: > > > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : > > > > > For that matter, wouldn't it be useful to support exporting a > > > > > userptr > > > > > buffer at some point in the future? > > > > > > > > Shouldn't USERPTR usage be discouraged once we get dma-buf support ? > > > > > > USERPTR, where available, is currently the only way to perform zero-copy > > > from kernel to userspace. READWRITE does not support zero-copy at all. > > > MMAP only supports zero-copy if userspace knows a boundary on the number > > > of concurrent buffers *and* the device can deal with that number of > > > buffers; in general, MMAP requires memory copying. > > > > Could you please share your use case(s) with us ? > > I want to receive the video buffers in user space for processing. Typically > "processing" is software encoding or conversion. That's what virtually any > V4L application does on the desktop... But what prevents you from using MMAP ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Mark all possible functions / structs as static
On Tue, Jul 31, 2012 at 12:45 AM, Alex Deucher wrote: > On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen wrote: >> Let's allow GCC to optimize better. >> >> This exposed some five unused functions, but this patch doesn't remove them. >> >> Signed-off-by: Lauri Kasanen > > Reviewed-by: Alex Deucher You might want to take this one step further and fix all the warnings it introduces here, CC [M] drivers/gpu/drm/radeon/radeon_combios.o /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/radeon_combios.c:3307:13: warning: ?radeon_combios_dyn_clk_setup? defined but not used [-Wunused-function] CC [M] drivers/gpu/drm/radeon/radeon_legacy_crtc.o /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/radeon_legacy_crtc.c:209:13: warning: ?radeon_restore_common_regs? defined but not used [-Wunused-function] CC [M] drivers/gpu/drm/radeon/r100.o /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/r100.c:2548:13: warning: ?r100_gpu_wait_for_vsync? defined but not used [-Wunused-function] /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/r100.c:2570:13: warning: ?r100_gpu_wait_for_vsync2? defined but not used [-Wunused-function] Not sure we want to lose all these functions or just if 0 them out for reference purposes, or even why we might need to call some of them. Dave.
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Tue, Jul 31, 2012 at 4:05 PM, Luca Tettamanti wrote: > On Tue, Jul 31, 2012 at 09:58:04AM -0400, Alex Deucher wrote: >> On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti wrote: >> > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher >> > wrote: >> >> Regarding patches 3 and 4, it might be easier to just store a pointer >> >> to the relevant encoder when you verify ATIF rather than walking the >> >> encoder list every time. > > Done. > >> > Makes sense, I was unsure about the lifetime of the encoders, but >> > AFAICS they're destroyed only when the module in unloaded. >> >> They are present for the life of the driver. > > I had to move to call to radeon_acpi_init after radeon_modeset_init, > otherwise the encoders are not present yet (the tear down code path is > correct, acpi first, then modeset). > Latest and greatest version is attached; I fixed notifications when > using custom command codes (tested by Pali Rohár) and implemented your > suggestion. Patches look good. I picked them up and combined them with may patches plus a few other small fixes. They are available here: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches Let me know what you think. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson wrote: > On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote: >> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson >> wrote: >> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark >> > wrote: >> >> From: Rob Clark >> >> >> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold >> >> a ref to the fb when disabling a pipe until the next vblank, this >> >> avoids the need to make disabling an overlay synchronous. This is a >> >> problem that shows up when userspace is using a drm plane to >> >> implement a hw cursor.. making overlay disable synchronous causes >> >> a performance problem when x11 is rapidly enabling/disabling the >> >> hw cursor. But not making it synchronous opens up a race condition >> >> for crashing if userspace turns around and immediately deletes the >> >> fb. Refcnt'ing the fb makes it possible to solve this problem. >> > >> > Presumably you have a follow-on patch putting the new refcnt to use so >> > that we can judge whether you truly need refcnting on the fb itself in >> > addition to the refcnted object and the various hw bookkeeping that >> > needs to be performed? >> >> Yes, I do.. although it is a bit experimental at this point, so not >> really ready to be submitted as anything other than an RFC.. it is >> part of omapdrm kms re-write to use dispc directly rather than go thru >> omapdss. (With omapdss we don't hit this issue because disabling >> overlays is forced to be synchronous.. so instead we have the >> performance problem I mentioned.) >> >> I *could* just rely on the GEM refcnt, but that gets messier when you >> take into account multi-planar formats. I suppose I also could have >> my own internal refcnt'd object to hold the set of GEM objects >> associated w/ the fb, but, well, that seems a bit silly. And >> refcnt'ing the fb had been mentioned previously as a good thing to do >> (I think it was danvet?) > > Sure, there are a few places in the code that have caused ordering > issues in the past due to lack of refcnting the fb... But since you > haven't fixed up those cases, I'm looking for justification for adding > that extra bit of complexity. Adding a new interface and no users is > just asking for trouble. hmm, I did realize that drm_plane cleanup only happens as a result of drm_framebuffer_cleanup().. which doesn't work too well if the driver is holding a ref to the fb :-/ so I guess at a minimum I need to fix plane cleanup to be part of drm_fb_helper_restore_fbdev_mode() BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
> Hi Hans,
>
> On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
> > On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
> > > +/**
> > > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > > descriptor + *
> > > + * @fd: file descriptor associated with DMABUF (set by driver)
> > > + * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
> > > struct + *v4l2_buffer::m.offset (for single-plane
> > > formats) or
> > > + * v4l2_plane::m.offset (for multi-planar formats)
> > > + * @flags: flags for newly created file, currently only O_CLOEXEC
> > > is
> > > + * supported, refer to manual of open syscall for more
> > > details
> > > + *
> > > + * Contains data used for exporting a video buffer as DMABUF file
> > > descriptor. + * The buffer is identified by a 'cookie' returned by
> > > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > > userspace). All + * reserved fields must be set to zero. The field
> > > reserved0 is expected to + * become a structure 'type' allowing an
> > > alternative layout of the structure + * content. Therefore this field
> > > should not be used for any other extensions. + */
> > > +struct v4l2_exportbuffer {
> > > + __u32 fd;
> > > + __u32 reserved0;
> > > + __u32 mem_offset;
> >
> > This should be a union identical to the m union in v4l2_plane, together with
> > a u32 memory field. That way you can just copy memory and m from
> > v4l2_plane/buffer and call expbuf. If new memory types are added in the
> > future, then you don't need to change this struct.
>
> OK, reserved0 could be replace by __u32 memory. Could we have other dma-buf
> export types in the future not corresponding to a memory type ? I don't see
> any use case right now though.
The memory type should be all you need. And the union is also needed since the
userptr value is unsigned long, thus ensuring that you have 64-bits available
for pointer types in the future. That's really my main point: the union should
have the same size as the union in v4l2_buffer/plane, allowing for the same
size pointers or whatever to be added in the future.
> > For that matter, wouldn't it be useful to support exporting a userptr buffer
> > at some point in the future?
>
> Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
Why? It's perfectly fine to use it and it's not going away.
I'm not saying that we should support exporting a userptr buffer as a dmabuf fd,
but I'm just wondering if that is possible at all and how difficult it would be.
Regards,
Hans
>
> > BTW, this patch series needs to be rebased to the latest for_v3.6. Quite a
> > few core things have changed when it comes to adding new ioctls.
>
>
[PATCH libdrm] Add configure option --with/--without-valgrind
Add a configure option --with/--without-valgrind to be able to compile libdrm with or without valgrind. The latter was not possible if pkgconfig found the valgrind package. --- configure.ac | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 09fed53..0776320 100644 --- a/configure.ac +++ b/configure.ac @@ -292,8 +292,21 @@ fi AC_SUBST(PCIACCESS_CFLAGS) AC_SUBST(PCIACCESS_LIBS) -PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], [have_valgrind=no]) -if test "x$have_valgrind" = "xyes"; then +AC_ARG_WITH(valgrind, + AS_HELP_STRING([--with-valgrind], + [Enable support for valgrind (default: auto)]), + [VALGRIND=$with_valgrind], [VALGRIND=auto]) + +if test "x$VALGRIND" = "xauto"; then + PKG_CHECK_MODULES(VALGRIND, [valgrind], [VALGRIND=yes], [VALGRIND=no]) +else + if test "x$VALGRIND" = "xyes"; then + VALGRIND=yes + else + VALGRIND=no + fi +fi +if test "x$VALGRIND" = "xyes"; then AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress false warnings]) fi @@ -340,6 +353,7 @@ echo "" echo "$PACKAGE_STRING will be compiled with:" echo "" echo " libkms $LIBKMS" +echo " valgrind $VALGRIND" echo " Intel API $INTEL" echo " vmwgfx API $VMWGFX" echo " Radeon API $RADEON" -- 1.7.2.5
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans,
On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
> On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
> > This patch adds extension to V4L2 api. It allow to export a mmap buffer as
> > file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
> > offset used by mmap and return a file descriptor on success.
> >
> > Signed-off-by: Tomasz Stanislawski
> > Signed-off-by: Kyungmin Park
> > ---
> >
> > drivers/media/video/v4l2-compat-ioctl32.c |1 +
> > drivers/media/video/v4l2-dev.c|1 +
> > drivers/media/video/v4l2-ioctl.c |6 ++
> > include/linux/videodev2.h | 26
> > ++
> > include/media/v4l2-ioctl.h|2 ++
> > 5 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> > b/drivers/media/video/v4l2-compat-ioctl32.c index d33ab18..141e745 100644
> > --- a/drivers/media/video/v4l2-compat-ioctl32.c
> > +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> > @@ -970,6 +970,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned
> > int cmd, unsigned long arg)>
> > case VIDIOC_S_FBUF32:
> > case VIDIOC_OVERLAY32:
> >
> > case VIDIOC_QBUF32:
> > + case VIDIOC_EXPBUF:
> > case VIDIOC_DQBUF32:
> > case VIDIOC_STREAMON32:
> >
> > case VIDIOC_STREAMOFF32:
> > diff --git a/drivers/media/video/v4l2-dev.c
> > b/drivers/media/video/v4l2-dev.c index 5ccbd46..6bf6307 100644
> > --- a/drivers/media/video/v4l2-dev.c
> > +++ b/drivers/media/video/v4l2-dev.c
> > @@ -597,6 +597,7 @@ static void determine_valid_ioctls(struct video_device
> > *vdev)>
> > SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
> > SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
> > SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
> >
> > + SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
> >
> > SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
> > SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay);
> > SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf);
> >
> > diff --git a/drivers/media/video/v4l2-ioctl.c
> > b/drivers/media/video/v4l2-ioctl.c index 31fc2ad..a73b14e 100644
> > --- a/drivers/media/video/v4l2-ioctl.c
> > +++ b/drivers/media/video/v4l2-ioctl.c
> > @@ -212,6 +212,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
> >
> > IOCTL_INFO(VIDIOC_S_FBUF, INFO_FL_PRIO),
> > IOCTL_INFO(VIDIOC_OVERLAY, INFO_FL_PRIO),
> > IOCTL_INFO(VIDIOC_QBUF, 0),
> >
> > + IOCTL_INFO(VIDIOC_EXPBUF, 0),
> >
> > IOCTL_INFO(VIDIOC_DQBUF, 0),
> > IOCTL_INFO(VIDIOC_STREAMON, INFO_FL_PRIO),
> > IOCTL_INFO(VIDIOC_STREAMOFF, INFO_FL_PRIO),
> >
> > @@ -957,6 +958,11 @@ static long __video_do_ioctl(struct file *file,
> >
> > dbgbuf(cmd, vfd, p);
> >
> > break;
> >
> > }
> >
> > + case VIDIOC_EXPBUF:
> > + {
> > + ret = ops->vidioc_expbuf(file, fh, arg);
> > + break;
> > + }
> >
> > case VIDIOC_DQBUF:
> > {
> >
> > struct v4l2_buffer *p = arg;
> >
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 51b20f4..e8893a5 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -684,6 +684,31 @@ struct v4l2_buffer {
> >
> > #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
> > #define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
> >
> > +/**
> > + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
> > descriptor + *
> > + * @fd:file descriptor associated with DMABUF (set by driver)
> > + * @mem_offset:buffer memory offset as returned by VIDIOC_QUERYBUF in
> > struct + * v4l2_buffer::m.offset (for single-plane formats) or
> > + * v4l2_plane::m.offset (for multi-planar formats)
> > + * @flags: flags for newly created file, currently only O_CLOEXEC is
> > + * supported, refer to manual of open syscall for more details
> > + *
> > + * Contains data used for exporting a video buffer as DMABUF file
> > descriptor. + * The buffer is identified by a 'cookie' returned by
> > VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
> > userspace). All + * reserved fields must be set to zero. The field
> > reserved0 is expected to + * become a structure 'type' allowing an
> > alternative layout of the structure + * content. Therefore this field
> > should not be used for any other extensions. + */
> > +struct v4l2_exportbuffer {
> > + __u32 fd;
> > + __u32 reserved0;
> > + __u32 mem_offset;
>
> This should be a union identical to the m union in v4l2_plane, together with
> a u32 memory field. That way you can just copy memory and m from
> v4l2_plane/buffer and call expbuf. If new memory types are added in the
> future, then you don't need to change this struct.
OK, reserved0 could be replace by __u32 memory. Could we have other dma-buf
e
[PATCH 2/2] drm/radeon: fix bank tiling parameters on SI
The sixteen bank case wasn't handled here, leading to GPU
crashes because of userspace miscalculation.
Signed-off-by: Christian K?nig
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/si.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 0b02792..0182fc8 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -1639,11 +1639,19 @@ static void si_gpu_init(struct radeon_device *rdev)
/* XXX what about 12? */
rdev->config.si.tile_config |= (3 << 0);
break;
- }
- if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
- rdev->config.si.tile_config |= 1 << 4;
- else
+ }
+ switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
+ case 0: /* four banks */
rdev->config.si.tile_config |= 0 << 4;
+ break;
+ case 1: /* eight banks */
+ rdev->config.si.tile_config |= 1 << 4;
+ break;
+ case 2: /* sixteen banks */
+ default:
+ rdev->config.si.tile_config |= 2 << 4;
+ break;
+ }
rdev->config.si.tile_config |=
((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
rdev->config.si.tile_config |=
--
1.7.9.5
[PATCH 1/2] drm/radeon: fix fence related segfault in CS
Don't return success if scheduling the IB fails, otherwise
we end up with an oops in ttm_eu_fence_buffer_objects.
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_cs.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 142f894..17238f4 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -377,7 +377,7 @@ static int radeon_cs_ib_chunk(struct radeon_device *rdev,
if (r) {
DRM_ERROR("Failed to schedule IB !\n");
}
- return 0;
+ return r;
}
static int radeon_bo_vm_update_pte(struct radeon_cs_parser *parser,
--
1.7.9.5
[PATCH] drm/i915: Fix mem leak in intel_sdvo_write_cmd()
If the allocation of 'buf' succeeds but the allocation of 'msgs' fails
we'll return false and leak 'buf' when it goes out of scope.
Signed-off-by: Jesper Juhl
---
drivers/gpu/drm/i915/intel_sdvo.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
note: compile tested only due to lack of hardware.
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 26a6a4d..1f73e24 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -444,13 +444,12 @@ static bool intel_sdvo_write_cmd(struct intel_sdvo
*intel_sdvo, u8 cmd,
struct i2c_msg *msgs;
int i, ret = true;
- buf = (u8 *)kzalloc(args_len * 2 + 2, GFP_KERNEL);
- if (!buf)
- return false;
-
+ buf = kzalloc(args_len * 2 + 2, GFP_KERNEL);
msgs = kcalloc(args_len + 3, sizeof(*msgs), GFP_KERNEL);
- if (!msgs)
- return false;
+ if (!msgs || !buf) {
+ ret = false;
+ goto out;
+ }
intel_sdvo_debug_write(intel_sdvo, cmd, args, args_len);
--
1.7.11.3
--
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] Add configure option --with/--without-valgrind
Add a configure option --with/--without-valgrind to be able to compile libdrm with or without valgrind. The latter was not possible if pkgconfig found the valgrind package. --- configure.ac | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 09fed53..0776320 100644 --- a/configure.ac +++ b/configure.ac @@ -292,8 +292,21 @@ fi AC_SUBST(PCIACCESS_CFLAGS) AC_SUBST(PCIACCESS_LIBS) -PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], [have_valgrind=no]) -if test "x$have_valgrind" = "xyes"; then +AC_ARG_WITH(valgrind, + AS_HELP_STRING([--with-valgrind], + [Enable support for valgrind (default: auto)]), + [VALGRIND=$with_valgrind], [VALGRIND=auto]) + +if test "x$VALGRIND" = "xauto"; then + PKG_CHECK_MODULES(VALGRIND, [valgrind], [VALGRIND=yes], [VALGRIND=no]) +else + if test "x$VALGRIND" = "xyes"; then + VALGRIND=yes + else + VALGRIND=no + fi +fi +if test "x$VALGRIND" = "xyes"; then AC_DEFINE([HAVE_VALGRIND], 1, [Use valgrind intrinsics to suppress false warnings]) fi @@ -340,6 +353,7 @@ echo "" echo "$PACKAGE_STRING will be compiled with:" echo "" echo " libkms $LIBKMS" +echo " valgrind $VALGRIND" echo " Intel API $INTEL" echo " vmwgfx API $VMWGFX" echo " Radeon API $RADEON" -- 1.7.2.5
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Tue, Jul 31, 2012 at 09:58:04AM -0400, Alex Deucher wrote:
> On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti wrote:
> > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher
> > wrote:
> >> Regarding patches 3 and 4, it might be easier to just store a pointer
> >> to the relevant encoder when you verify ATIF rather than walking the
> >> encoder list every time.
Done.
> > Makes sense, I was unsure about the lifetime of the encoders, but
> > AFAICS they're destroyed only when the module in unloaded.
>
> They are present for the life of the driver.
I had to move to call to radeon_acpi_init after radeon_modeset_init,
otherwise the encoders are not present yet (the tear down code path is
correct, acpi first, then modeset).
Latest and greatest version is attached; I fixed notifications when
using custom command codes (tested by Pali Rohár) and implemented your
suggestion.
Luca
>From f0f8699eabee0d47b93fba14f8126b821cc106a5 Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Sun, 29 Jul 2012 17:04:43 +0200
Subject: [PATCH 1/4] drm/radeon: refactor radeon_atif_call
Don't hard-code function number, this will allow to reuse the function.
v2: add support for the 2nd parameter (from Lee, Chun-Yi
).
Signed-off-by: Luca Tettamanti
---
drivers/gpu/drm/radeon/radeon_acpi.c | 38 --
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 5b32e49..158e514 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -14,23 +14,30 @@
#include
/* Call the ATIF method
- *
- * Note: currently we discard the output
*/
-static int radeon_atif_call(acpi_handle handle)
+static union acpi_object *radeon_atif_call(acpi_handle handle, int function,
+ struct acpi_buffer *params)
{
acpi_status status;
union acpi_object atif_arg_elements[2];
struct acpi_object_list atif_arg;
- struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL};
+ struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
atif_arg.count = 2;
atif_arg.pointer = &atif_arg_elements[0];
atif_arg_elements[0].type = ACPI_TYPE_INTEGER;
- atif_arg_elements[0].integer.value = ATIF_FUNCTION_VERIFY_INTERFACE;
- atif_arg_elements[1].type = ACPI_TYPE_INTEGER;
- atif_arg_elements[1].integer.value = 0;
+ atif_arg_elements[0].integer.value = function;
+
+ if (params) {
+ atif_arg_elements[1].type = ACPI_TYPE_BUFFER;
+ atif_arg_elements[1].buffer.length = params->length;
+ atif_arg_elements[1].buffer.pointer = params->pointer;
+ } else {
+ /* We need a second fake parameter */
+ atif_arg_elements[1].type = ACPI_TYPE_INTEGER;
+ atif_arg_elements[1].integer.value = 0;
+ }
status = acpi_evaluate_object(handle, "ATIF", &atif_arg, &buffer);
@@ -39,18 +46,18 @@ static int radeon_atif_call(acpi_handle handle)
DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n",
acpi_format_exception(status));
kfree(buffer.pointer);
- return 1;
+ return NULL;
}
- kfree(buffer.pointer);
- return 0;
+ return buffer.pointer;
}
/* Call all ACPI methods here */
int radeon_acpi_init(struct radeon_device *rdev)
{
acpi_handle handle;
- int ret;
+ union acpi_object *info;
+ int ret = 0;
/* Get the device handle */
handle = DEVICE_ACPI_HANDLE(&rdev->pdev->dev);
@@ -60,10 +67,11 @@ int radeon_acpi_init(struct radeon_device *rdev)
return 0;
/* Call the ATIF method */
- ret = radeon_atif_call(handle);
- if (ret)
- return ret;
+ info = radeon_atif_call(handle, ATIF_FUNCTION_VERIFY_INTERFACE, NULL);
+ if (!info)
+ ret = -EIO;
- return 0;
+ kfree(info);
+ return ret;
}
--
1.7.10.4
>From 427002ddf653b0abd0fb820b09322bf2a0b281af Mon Sep 17 00:00:00 2001
From: Luca Tettamanti
Date: Mon, 30 Jul 2012 21:11:58 +0200
Subject: [PATCH 2/4] drm/radeon: implement radeon_atif_verify_interface
Wrap the call to VERIFY_INTERFACE and add the parsing of the support
vectors.
v2: use a packed struct for handling the output of ACPI calls, hides
ugly pointer arithmetics (Lee, Chun-Yi ).
Signed-off-by: Luca Tettamanti
---
drivers/gpu/drm/radeon/radeon.h | 40 +
drivers/gpu/drm/radeon/radeon_acpi.c | 79 +++---
2 files changed, 113 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fefcca5..0db98eb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1456,6 +1456,44 @@ struct r600_vram_scratch {
u64
[PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson wrote: > On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote: >> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson >> wrote: >> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark >> > wrote: >> >> From: Rob Clark >> >> >> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold >> >> a ref to the fb when disabling a pipe until the next vblank, this >> >> avoids the need to make disabling an overlay synchronous. This is a >> >> problem that shows up when userspace is using a drm plane to >> >> implement a hw cursor.. making overlay disable synchronous causes >> >> a performance problem when x11 is rapidly enabling/disabling the >> >> hw cursor. But not making it synchronous opens up a race condition >> >> for crashing if userspace turns around and immediately deletes the >> >> fb. Refcnt'ing the fb makes it possible to solve this problem. >> > >> > Presumably you have a follow-on patch putting the new refcnt to use so >> > that we can judge whether you truly need refcnting on the fb itself in >> > addition to the refcnted object and the various hw bookkeeping that >> > needs to be performed? >> >> Yes, I do.. although it is a bit experimental at this point, so not >> really ready to be submitted as anything other than an RFC.. it is >> part of omapdrm kms re-write to use dispc directly rather than go thru >> omapdss. (With omapdss we don't hit this issue because disabling >> overlays is forced to be synchronous.. so instead we have the >> performance problem I mentioned.) >> >> I *could* just rely on the GEM refcnt, but that gets messier when you >> take into account multi-planar formats. I suppose I also could have >> my own internal refcnt'd object to hold the set of GEM objects >> associated w/ the fb, but, well, that seems a bit silly. And >> refcnt'ing the fb had been mentioned previously as a good thing to do >> (I think it was danvet?) > > Sure, there are a few places in the code that have caused ordering > issues in the past due to lack of refcnting the fb... But since you > haven't fixed up those cases, I'm looking for justification for adding > that extra bit of complexity. Adding a new interface and no users is > just asking for trouble. fwiw, my line of reasoning was: from userspace perspective, once you do drm_mode_rmfb(), the fb is gone, so I didn't change where it gets removed from the list of fb's or anything like that. Instead I just left it so that a driver could, if it wants, take an extra ref temporarily to the fb to keep it around for a bit. I didn't change any of the existing drivers, other than update the to call drm_framebuffer_unreference() instead of fb->funcs->delete() directly, because I didn't want to break anything in existing drivers, and I figured the new behavior was better as an opt-in by individual drivers when they want to take advantage of refcnt'ing. But if you have suggestions about related cleanups that should be made, I'm willing to take that on. Anyways, like I mentioned, I'm still a little ways from being ready to submit anything other than RFC patches in omapdrm to use fb refcnt'ing, so this isn't something that needs to be merged immediately. But it seemed like low risk and like it would be something that other drivers could take advantage of, so I figured it was worth sending this patch now. BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/radeon: Mark all possible functions / structs as static
On Tue, 31 Jul 2012 14:43:34 +1000 Dave Airlie wrote: > On Tue, Jul 31, 2012 at 12:45 AM, Alex Deucher > wrote: > > On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen wrote: > >> Let's allow GCC to optimize better. > >> > >> This exposed some five unused functions, but this patch doesn't remove > >> them. > >> > >> Signed-off-by: Lauri Kasanen > > > > Reviewed-by: Alex Deucher > > You might want to take this one step further and fix all the warnings > it introduces here, > > CC [M] drivers/gpu/drm/radeon/radeon_combios.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/radeon_combios.c:3307:13: > warning: ?radeon_combios_dyn_clk_setup? defined but not used > [-Wunused-function] > CC [M] drivers/gpu/drm/radeon/radeon_legacy_crtc.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/radeon_legacy_crtc.c:209:13: > warning: ?radeon_restore_common_regs? defined but not used > [-Wunused-function] > > CC [M] drivers/gpu/drm/radeon/r100.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/r100.c:2548:13: > warning: ?r100_gpu_wait_for_vsync? defined but not used > [-Wunused-function] > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/r100.c:2570:13: > warning: ?r100_gpu_wait_for_vsync2? defined but not used > [-Wunused-function] > > Not sure we want to lose all these functions or just if 0 them out for > reference purposes, or even why we might need to call some of them. That's why I didn't remove them. I don't have the info on whether they are needed or not, someone qualified will need to make that decision. - Lauri
[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library
https://bugs.freedesktop.org/show_bug.cgi?id=49817 --- Comment #11 from stevenvandenbrandenst...@gmail.com 2012-07-31 19:44:10 UTC --- (In reply to comment #10) > (In reply to comment #8) > > same problem here when trying to run dungeon siege 2 via wine, intro plays > > fine > > and then hangs , found a radeon problem to be the cause. > > I tried the demo of the game but couldn't reproduce this. It seems to be > working fine both with 8.0.4 and with git master. to be more precise its the dungeon siege 2 broken world extension afther running the video config feature from the game. I will try to reinstall wine and the game to give the exact steps i followed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 1/3] Move FIMD register headers to include/video/
Hello Marek, On Tue, Jul 31, 2012 at 11:58 AM, Marek Szyprowski wrote: > Hello, > > On Tuesday, July 31, 2012 2:48 AM Jingoo Han wrote: > >> On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: >> > >> > Hello Jingoo Han, >> > >> > On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han wrote: >> > > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: >> > >> >> > >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side >> > >> to include/video/samsung_fimd.h >> > >> >> > >> Signed-off-by: Leela Krishna Amudala >> > >> --- >> > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- >> > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 >> > >> - >> > >> include/video/samsung_fimd.h| 533 >> > >> +++ >> > >> 3 files changed, 533 insertions(+), 562 deletions(-) >> > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h >> > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h >> > >> create mode 100644 include/video/samsung_fimd.h >> > >> >> > >> +*/ >> > >> + >> > >> +/*FIMD V8 REG OFFSET */ >> > >> +#define FIMD_V8_VIDTCON0 (0x20010) >> > >> +#define FIMD_V8_VIDTCON1 (0x20014) >> > >> +#define FIMD_V8_VIDTCON2 (0x20018) >> > >> +#define FIMD_V8_VIDTCON3 (0x2001C) >> > >> +#define FIMD_V8_VIDCON1 (0x20004) >> >> >> How about using soc_is_exynos5250()? >> >> +#define VIDTCON0 (soc_is_exynos5250() ? \ >> + (0x20010) : (0x10)) >> >> In this case, the FIMD driver does not need to change. >> Also, one binary is available. > > Please don't mix two methods of runtime detection. FIMD driver (s3c-fb) > already > has runtime hw detection based on platform device id. Adding such detection > for > exynos5 to DRM FIMD driver should not be a big issue too. > I have code ready for DRM-FIMD driver with the above approach (getting FIMD version by runtime detection) will post the patches soon along with arch side patches once the arch changes are ready. and I'll continue the same name FIMD_V8_xxx for macro names. > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson wrote: > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: >> From: Rob Clark >> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold >> a ref to the fb when disabling a pipe until the next vblank, this >> avoids the need to make disabling an overlay synchronous. This is a >> problem that shows up when userspace is using a drm plane to >> implement a hw cursor.. making overlay disable synchronous causes >> a performance problem when x11 is rapidly enabling/disabling the >> hw cursor. But not making it synchronous opens up a race condition >> for crashing if userspace turns around and immediately deletes the >> fb. Refcnt'ing the fb makes it possible to solve this problem. > > Presumably you have a follow-on patch putting the new refcnt to use so > that we can judge whether you truly need refcnting on the fb itself in > addition to the refcnted object and the various hw bookkeeping that > needs to be performed? Yes, I do.. although it is a bit experimental at this point, so not really ready to be submitted as anything other than an RFC.. it is part of omapdrm kms re-write to use dispc directly rather than go thru omapdss. (With omapdss we don't hit this issue because disabling overlays is forced to be synchronous.. so instead we have the performance problem I mentioned.) I *could* just rely on the GEM refcnt, but that gets messier when you take into account multi-planar formats. I suppose I also could have my own internal refcnt'd object to hold the set of GEM objects associated w/ the fb, but, well, that seems a bit silly. And refcnt'ing the fb had been mentioned previously as a good thing to do (I think it was danvet?) BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Fwd: Brightness on HP EliteBook 8460p
On Sat, Jul 28, 2012 at 4:47 PM, Pali Roh?r wrote: > Hello, I have some good news. Radeon patches from this post > http://lists.freedesktop.org/archives/dri-devel/2012-July/025535.html > export brightness file /sys/class/backlight/radeon_bl/brightness > And finally with these patches I'm able to change brightness on my EliteBook. Nice, in your older mail I read: > The PEGP.DGFX acpi device was binding to > acpi/video driver, the above ASL code emit a 0xD0 bus event to > video.c but cann't process it. Even we add a new bus event in > video.c and generate a acpi event, there still need another acpi > driver should take care it. That event (0xd0) is probably a custom event announced through ATIF. I'm working on the code to deal with it, the latest patches are here: http://lists.freedesktop.org/archives/dri-devel/2012-July/025646.html You first need this one with the ACPI header: http://lists.freedesktop.org/archives/dri-devel/2012-July/025517.html and the other 3 that you've already tested. With my patches on top you should be able to change the brightness using the hotkeys. I'd be grateful if you could test them :-) Luca
Re: [PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson wrote: > On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote: >> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson >> wrote: >> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: >> >> From: Rob Clark >> >> >> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold >> >> a ref to the fb when disabling a pipe until the next vblank, this >> >> avoids the need to make disabling an overlay synchronous. This is a >> >> problem that shows up when userspace is using a drm plane to >> >> implement a hw cursor.. making overlay disable synchronous causes >> >> a performance problem when x11 is rapidly enabling/disabling the >> >> hw cursor. But not making it synchronous opens up a race condition >> >> for crashing if userspace turns around and immediately deletes the >> >> fb. Refcnt'ing the fb makes it possible to solve this problem. >> > >> > Presumably you have a follow-on patch putting the new refcnt to use so >> > that we can judge whether you truly need refcnting on the fb itself in >> > addition to the refcnted object and the various hw bookkeeping that >> > needs to be performed? >> >> Yes, I do.. although it is a bit experimental at this point, so not >> really ready to be submitted as anything other than an RFC.. it is >> part of omapdrm kms re-write to use dispc directly rather than go thru >> omapdss. (With omapdss we don't hit this issue because disabling >> overlays is forced to be synchronous.. so instead we have the >> performance problem I mentioned.) >> >> I *could* just rely on the GEM refcnt, but that gets messier when you >> take into account multi-planar formats. I suppose I also could have >> my own internal refcnt'd object to hold the set of GEM objects >> associated w/ the fb, but, well, that seems a bit silly. And >> refcnt'ing the fb had been mentioned previously as a good thing to do >> (I think it was danvet?) > > Sure, there are a few places in the code that have caused ordering > issues in the past due to lack of refcnting the fb... But since you > haven't fixed up those cases, I'm looking for justification for adding > that extra bit of complexity. Adding a new interface and no users is > just asking for trouble. hmm, I did realize that drm_plane cleanup only happens as a result of drm_framebuffer_cleanup().. which doesn't work too well if the driver is holding a ref to the fb :-/ so I guess at a minimum I need to fix plane cleanup to be part of drm_fb_helper_restore_fbdev_mode() BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" 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: Massive power regression going 3.4->3.5
On Tue, 31 Jul 2012 11:14:17 +0100, Chris Wilson
wrote:
> On Tue, 31 Jul 2012 10:57:10 +0100, James Bottomley
> wrote:
> > > When did you inspect the debug files? One effect I can imagine is that
> > > if your system was previously stuck at RPn and never upclocking the GPU
> > > when X starts. The question would then be what is preventing the GPU
> > > from reaching its lowest power state again.
> >
> > After I logged into an xfce4 session and powertop showed idle had been
> > reached.
That you are using xfce4 makes the use of semaphores for pageflips as
being the root cause even more suspect. Pageflips are only used for a
fullscreen DRI client caalling SwapBuffers, to my knowledge xfce4 does
not use DRI at all - its compositing manager is XRender based if you
happen to be using it.
Please can you try the small patch to disable the use of semaphores for
pageflips and see if the regression remains (which I judge it will...):
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 5c4657a..f301f2f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3067,7 +3067,7 @@ i915_gem_object_pin_to_display_plane(struct drm_i915_gem_o
return ret;
if (pipelined != obj->ring) {
- ret = i915_gem_object_sync(obj, pipelined);
+ ret = i915_gem_object_wait_rendering(obj);
if (ret)
return ret;
}
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Fwd: Brightness on HP EliteBook 8460p
On Tue, Jul 31, 2012 at 12:03 PM, Pali Roh?r wrote: > On Tuesday 31 July 2012 17:49:32 Luca Tettamanti wrote: >> I'm putting back the CC and adding Alex. >> >> On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r > wrote: >> > Thanks, now working. When I write to acpi video brightness >> > file it change brightness and in dmesg is: >> > >> > [ 47.200998] [drm:radeon_atif_handler], event, device_class >> > = video, type = 0xd0 >> > [ 47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS >> > pending requests: 0x80 >> > [ 47.201104] [drm:radeon_atif_handler], ATIF: 1 pending >> > SBIOS requests >> > [ 47.201105] [drm:radeon_atif_handler], Changing brightness >> > to 11 >> >> Great! I'll send an updated patch to Alex soon. >> >> > I think that acpi only sent event about brightness key >> > pressed, because nothing happened when I pressed it. >> > >> > Also for windows is needed special HP application (hp hotkey) >> > for brightness keys. Without it brightness keys not working >> > too... >> I've looked at hp-wmi: the hotkey is indeed dispatched via WMI >> (hp-wmi) so you need something in userspace (KDE, Gnome, etc) >> to respond to that key press. >> > > No, when I rmmod hp-wmi brightness keys still generate events. > And when I disable acpi then brightness keys do not generate > events but adjust brightness automatically (by BIOS). > > I think that hp-wmi on my notebook only handle bluetooth & wifi > rfkills and ALS switch. All button working without hp-wmi too. > >> > And there is one problem with /sys/class/backlight/radeon_bl. >> > When I enable Ambient Light Sensor which auto adjust >> > brightness based on sensor data, writing value 0 (min) or >> > 255 (max) to /sys/class/backlight/radeon_bl/brightness turn >> > off display. >> Ok, that's weird. 0 turns off the panel by design, 255 should >> not... > > But when ALS is disabled 0 did not turn display off. 0 only turns off the backlight, not the panel itself. Is the backlight still partially on or is it just the actual panel (timing and image)? Alex
[PATCH] drm/radeon/kms: allow "invalid" DB formats as a means to disable DB
Signed-off-by: Marek Ol??k
Reviewed-by: Alex Deucher
Reviewed-by: Michel D?nzer
Cc: stable at vger.kernel.org [3.5]
---
drivers/gpu/drm/radeon/evergreen_cs.c |6 --
drivers/gpu/drm/radeon/evergreend.h |2 ++
drivers/gpu/drm/radeon/r600_cs.c |6 --
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index c1655412..f2e5c54 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -961,13 +961,15 @@ static int evergreen_cs_track_check(struct
radeon_cs_parser *p)
if (track->db_dirty) {
/* Check stencil buffer */
- if (G_028800_STENCIL_ENABLE(track->db_depth_control)) {
+ if (G_028044_FORMAT(track->db_s_info) !=
V_028044_STENCIL_INVALID &&
+ G_028800_STENCIL_ENABLE(track->db_depth_control)) {
r = evergreen_cs_track_validate_stencil(p);
if (r)
return r;
}
/* Check depth buffer */
- if (G_028800_Z_ENABLE(track->db_depth_control)) {
+ if (G_028040_FORMAT(track->db_z_info) != V_028040_Z_INVALID &&
+ G_028800_Z_ENABLE(track->db_depth_control)) {
r = evergreen_cs_track_validate_depth(p);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/evergreend.h
b/drivers/gpu/drm/radeon/evergreend.h
index b50b15c..4a43b46 100644
--- a/drivers/gpu/drm/radeon/evergreend.h
+++ b/drivers/gpu/drm/radeon/evergreend.h
@@ -1273,6 +1273,8 @@
#define S_028044_FORMAT(x) (((x) & 0x1) << 0)
#define G_028044_FORMAT(x) (((x) >> 0) & 0x1)
#define C_028044_FORMAT 0xFFFE
+#defineV_028044_STENCIL_INVALID0
+#defineV_028044_STENCIL_8 1
#define G_028044_TILE_SPLIT(x) (((x) >> 8) & 0x7)
#define DB_Z_READ_BASE 0x28048
#define DB_STENCIL_READ_BASE 0x2804c
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index ca87f7a..1119e31 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -764,8 +764,10 @@ static int r600_cs_track_check(struct radeon_cs_parser *p)
}
/* Check depth buffer */
- if (track->db_dirty &&
(G_028800_STENCIL_ENABLE(track->db_depth_control) ||
- G_028800_Z_ENABLE(track->db_depth_control))) {
+ if (track->db_dirty &&
+ G_028010_FORMAT(track->db_depth_info) != V_028010_DEPTH_INVALID &&
+ (G_028800_STENCIL_ENABLE(track->db_depth_control) ||
+G_028800_Z_ENABLE(track->db_depth_control))) {
r = r600_cs_track_validate_db(p);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 2c4d53f..ed13538 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -59,9 +59,10 @@
* 2.15.0 - add max_pipes query
* 2.16.0 - fix evergreen 2D tiled surface calculation
* 2.17.0 - add STRMOUT_BASE_UPDATE for r7xx
+ * 2.18.0 - r600-eg: allow "invalid" DB formats
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 17
+#define KMS_DRIVER_MINOR 18
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
--
1.7.9.5
Fwd: Brightness on HP EliteBook 8460p
On Tue, Jul 31, 2012 at 11:49 AM, Luca Tettamanti wrote: > I'm putting back the CC and adding Alex. > > On Tue, Jul 31, 2012 at 5:07 PM, Pali Roh?r wrote: >> Thanks, now working. When I write to acpi video brightness file >> it change brightness and in dmesg is: >> >> [ 47.200998] [drm:radeon_atif_handler], event, device_class = >> video, type = 0xd0 >> [ 47.201102] [drm:radeon_atif_get_sbios_requests], SBIOS >> pending requests: 0x80 >> [ 47.201104] [drm:radeon_atif_handler], ATIF: 1 pending SBIOS >> requests >> [ 47.201105] [drm:radeon_atif_handler], Changing brightness to >> 11 > > Great! I'll send an updated patch to Alex soon. > >> I think that acpi only sent event about brightness key pressed, >> because nothing happened when I pressed it. >> >> Also for windows is needed special HP application (hp hotkey) for >> brightness keys. Without it brightness keys not working too... > > I've looked at hp-wmi: the hotkey is indeed dispatched via WMI > (hp-wmi) so you need something in userspace (KDE, Gnome, etc) to > respond to that key press. > >> And there is one problem with /sys/class/backlight/radeon_bl. >> When I enable Ambient Light Sensor which auto adjust brightness >> based on sensor data, writing value 0 (min) or 255 (max) to >> /sys/class/backlight/radeon_bl/brightness turn off display. > > Ok, that's weird. 0 turns off the panel by design, 255 should not... > >> All >> other values (1-254) are OK (adjust brightness level). When I >> turn off Ambient Light Sensor (via hp-wmi kernel module) then >> values 0 and 255 also set brightness level (min and max). My >> suggestion is to convert value 0 to 1 and 255 to 254 to prevent >> this problem. > > No idea what's going on here... might be some weird vendor magic. > The WMI code is rather obscure... FWIW, there is also a bit in the atom firmware info table (WMI_SUPPORT) to tell whether the system uses WMI or not. We can probably use that to limit the max backlight if 255 causes problems for other WMI systems. I'm not sure how the interaction with WMI is supposed to work however. Alex
[PATCH] drm/radeon: Remove unused functions
On Tue, Jul 31, 2012 at 10:41 AM, Lauri Kasanen wrote: > This applies on top of drm/radeon: Mark all possible functions / structs as > static. > > Signed-off-by: Lauri Kasanen Reviewed-by: Alex Deucher
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #1 from stevenvandenbrandenst...@gmail.com 2012-07-31 18:38:32 UTC --- what else do i need to submit and how to do it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 49817] radeon: The kernel rejected CS when running shader example from SFML library
https://bugs.freedesktop.org/show_bug.cgi?id=49817 --- Comment #10 from Sven Arvidsson 2012-07-31 18:35:56 UTC --- (In reply to comment #8) > same problem here when trying to run dungeon siege 2 via wine, intro plays > fine > and then hangs , found a radeon problem to be the cause. I tried the demo of the game but couldn't reproduce this. It seems to be working fine both with 8.0.4 and with git master. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
Fix GPU triggering random system read after VRAM start change
On Tue, Jul 31, 2012 at 11:15 AM, Jerome Glisse wrote: > On Tue, Jul 31, 2012 at 10:56 AM, Alex Deucher > wrote: >> On Fri, Jul 27, 2012 at 4:32 PM, wrote: >>> So first patch is a fix in itself, smallest possible and should go to >>> stable. Second patch is an improvement as a first step to flicker free >>> boot. >> >> First patch looks ok. In mc_stop we should disable the crtc and then >> poll CRTC_CONTROL.CRTC_CURRENT_MASTER_EN_STATE until it goes to 0 to >> make sure the crtc has actually stopped reading before we change the >> mc config. Other than that, > > In all my test is was instantaneous, ie less than 1us to take effect, > so i did not wanted to make the patch bigger than it is. But if you > really think we should do that i can readd that code in patch 1. Thinking about it more, It should fine as is since we take the crtc lock. Alex
[PATCH] drm: refcnt drm_framebuffer
From: Rob Clark
This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous. This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor. But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb. Refcnt'ing the fb makes it possible to solve this problem.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c| 38 ++---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |4 +--
drivers/gpu/drm/i915/intel_display.c |4 +--
include/drm/drm_crtc.h|4 +++
4 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..2f928a3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -294,6 +294,8 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
{
int ret;
+ kref_init(&fb->refcount);
+
ret = drm_mode_object_get(dev, &fb->base, DRM_MODE_OBJECT_FB);
if (ret)
return ret;
@@ -307,6 +309,36 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_framebuffer_init);
+static void drm_framebuffer_free(struct kref *kref)
+{
+ struct drm_framebuffer *fb =
+ container_of(kref, struct drm_framebuffer, refcount);
+ fb->funcs->destroy(fb);
+}
+
+/**
+ * drm_framebuffer_unreference - unref a framebuffer
+ *
+ * LOCKING:
+ * Caller must hold mode config lock.
+ */
+void drm_framebuffer_unreference(struct drm_framebuffer *fb)
+{
+ struct drm_device *dev = fb->dev;
+ WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
+ kref_put(&fb->refcount, drm_framebuffer_free);
+}
+EXPORT_SYMBOL(drm_framebuffer_unreference);
+
+/**
+ * drm_framebuffer_reference - incr the fb refcnt
+ */
+void drm_framebuffer_reference(struct drm_framebuffer *fb)
+{
+ kref_get(&fb->refcount);
+}
+EXPORT_SYMBOL(drm_framebuffer_reference);
+
/**
* drm_framebuffer_cleanup - remove a framebuffer object
* @fb: framebuffer to remove
@@ -1031,7 +1063,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
}
list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) {
- fb->funcs->destroy(fb);
+ drm_framebuffer_unreference(fb);
}
list_for_each_entry_safe(crtc, ct, &dev->mode_config.crtc_list, head) {
@@ -2339,7 +2371,7 @@ int drm_mode_rmfb(struct drm_device *dev,
/* TODO unhock the destructor from the buffer object */
list_del(&fb->filp_head);
- fb->funcs->destroy(fb);
+ drm_framebuffer_unreference(fb);
out:
mutex_unlock(&dev->mode_config.mutex);
@@ -2490,7 +2522,7 @@ void drm_fb_release(struct drm_file *priv)
mutex_lock(&dev->mode_config.mutex);
list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
list_del(&fb->filp_head);
- fb->funcs->destroy(fb);
+ drm_framebuffer_unreference(fb);
}
mutex_unlock(&dev->mode_config.mutex);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index d5586cc..05695d6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -266,8 +266,8 @@ static void exynos_drm_fbdev_destroy(struct drm_device *dev,
/* release drm framebuffer and real buffer */
if (fb_helper->fb && fb_helper->fb->funcs) {
fb = fb_helper->fb;
- if (fb && fb->funcs->destroy)
- fb->funcs->destroy(fb);
+ if (fb)
+ drm_framebuffer_unreference(fb);
}
/* release linux framebuffer */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a8538ac..a9d2328 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5467,7 +5467,7 @@ bool intel_get_load_detect_pipe(struct intel_encoder
*intel_encoder,
if (!drm_crtc_helper_set_mode(crtc, mode, 0, 0, old_fb)) {
DRM_DEBUG_KMS("failed to set mode on load-detect pipe\n");
if (old->release_fb)
- old->release_fb->funcs->destroy(old->release_fb);
+ drm_framebuffer_unreference(old->release_fb);
crtc->fb = old_fb;
return false;
}
@@ -5497,7 +5497,7 @@ void intel_release_load_detect_pipe(struct intel_encoder
*intel_encoder,
drm_helper_disable_unused_functions(dev);
if (old->release_fb)
-
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher wrote: > Regarding patches 3 and 4, it might be easier to just store a pointer > to the relevant encoder when you verify ATIF rather than walking the > encoder list every time. Makes sense, I was unsure about the lifetime of the encoders, but AFAICS they're destroyed only when the module in unloaded. Luca
Fix GPU triggering random system read after VRAM start change
On Tue, Jul 31, 2012 at 10:56 AM, Alex Deucher wrote: > On Fri, Jul 27, 2012 at 4:32 PM, wrote: >> So first patch is a fix in itself, smallest possible and should go to >> stable. Second patch is an improvement as a first step to flicker free >> boot. > > First patch looks ok. In mc_stop we should disable the crtc and then > poll CRTC_CONTROL.CRTC_CURRENT_MASTER_EN_STATE until it goes to 0 to > make sure the crtc has actually stopped reading before we change the > mc config. Other than that, In all my test is was instantaneous, ie less than 1us to take effect, so i did not wanted to make the patch bigger than it is. But if you really think we should do that i can readd that code in patch 1. Cheers, Jerome > > Reviewed-by: Alex Deucher > >> >> I have yet extensively tested second patch, especialy not on AGP but >> so far on few GPU/motherboard it looks good. It can probably wait 3.7. >> Will test it more and report. > > Looks good as well. A nice clean up to boot. > >> >> I have a third patch that is a step closer to flicker free boot on uefi, >> waiting ack to release a reg. >> >> Cheers, >> Jerome >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Massive power regression going 3.4->3.5
On Tue, 31 Jul 2012 10:57:10 +0100, James Bottomley wrote: > > When did you inspect the debug files? One effect I can imagine is that > > if your system was previously stuck at RPn and never upclocking the GPU > > when X starts. The question would then be what is preventing the GPU > > from reaching its lowest power state again. > > After I logged into an xfce4 session and powertop showed idle had been > reached. So it looks like rc6 is functioning as the GPU is downclocked whilst idle and the rc6 residency counter is increasing. I guess we need a new tree to bark at. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 2/2] drm/radeon: fix bank tiling parameters on cayman
From: Alex Deucher
Handle the 16 bank case.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ni.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 9945d86..853800e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -574,10 +574,18 @@ static void cayman_gpu_init(struct radeon_device *rdev)
if (rdev->flags & RADEON_IS_IGP)
rdev->config.cayman.tile_config |= 1 << 4;
else {
- if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
- rdev->config.cayman.tile_config |= 1 << 4;
- else
+ switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
+ case 0: /* four banks */
rdev->config.cayman.tile_config |= 0 << 4;
+ break;
+ case 1: /* eight banks */
+ rdev->config.cayman.tile_config |= 1 << 4;
+ break;
+ case 2: /* sixteen banks */
+ default:
+ rdev->config.cayman.tile_config |= 2 << 4;
+ break;
+ }
}
rdev->config.cayman.tile_config |=
((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
--
1.7.7.5
[PATCH 1/2] drm/radeon: fix bank tiling parameters on evergreen
From: Alex Deucher
Handle the 16 bank case.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 30f5c31..475984a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2005,10 +2005,18 @@ static void evergreen_gpu_init(struct radeon_device
*rdev)
if (rdev->flags & RADEON_IS_IGP)
rdev->config.evergreen.tile_config |= 1 << 4;
else {
- if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
- rdev->config.evergreen.tile_config |= 1 << 4;
- else
+ switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
+ case 0: /* four banks */
rdev->config.evergreen.tile_config |= 0 << 4;
+ break;
+ case 1: /* eight banks */
+ rdev->config.evergreen.tile_config |= 1 << 4;
+ break;
+ case 2: /* sixteen banks */
+ default:
+ rdev->config.evergreen.tile_config |= 2 << 4;
+ break;
+ }
}
rdev->config.evergreen.tile_config |= 0 << 8;
rdev->config.evergreen.tile_config |=
--
1.7.7.5
Re: [PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 12:47 PM, Chris Wilson wrote: > On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote: >> On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson >> wrote: >> > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: >> >> From: Rob Clark >> >> >> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold >> >> a ref to the fb when disabling a pipe until the next vblank, this >> >> avoids the need to make disabling an overlay synchronous. This is a >> >> problem that shows up when userspace is using a drm plane to >> >> implement a hw cursor.. making overlay disable synchronous causes >> >> a performance problem when x11 is rapidly enabling/disabling the >> >> hw cursor. But not making it synchronous opens up a race condition >> >> for crashing if userspace turns around and immediately deletes the >> >> fb. Refcnt'ing the fb makes it possible to solve this problem. >> > >> > Presumably you have a follow-on patch putting the new refcnt to use so >> > that we can judge whether you truly need refcnting on the fb itself in >> > addition to the refcnted object and the various hw bookkeeping that >> > needs to be performed? >> >> Yes, I do.. although it is a bit experimental at this point, so not >> really ready to be submitted as anything other than an RFC.. it is >> part of omapdrm kms re-write to use dispc directly rather than go thru >> omapdss. (With omapdss we don't hit this issue because disabling >> overlays is forced to be synchronous.. so instead we have the >> performance problem I mentioned.) >> >> I *could* just rely on the GEM refcnt, but that gets messier when you >> take into account multi-planar formats. I suppose I also could have >> my own internal refcnt'd object to hold the set of GEM objects >> associated w/ the fb, but, well, that seems a bit silly. And >> refcnt'ing the fb had been mentioned previously as a good thing to do >> (I think it was danvet?) > > Sure, there are a few places in the code that have caused ordering > issues in the past due to lack of refcnting the fb... But since you > haven't fixed up those cases, I'm looking for justification for adding > that extra bit of complexity. Adding a new interface and no users is > just asking for trouble. fwiw, my line of reasoning was: from userspace perspective, once you do drm_mode_rmfb(), the fb is gone, so I didn't change where it gets removed from the list of fb's or anything like that. Instead I just left it so that a driver could, if it wants, take an extra ref temporarily to the fb to keep it around for a bit. I didn't change any of the existing drivers, other than update the to call drm_framebuffer_unreference() instead of fb->funcs->delete() directly, because I didn't want to break anything in existing drivers, and I figured the new behavior was better as an opt-in by individual drivers when they want to take advantage of refcnt'ing. But if you have suggestions about related cleanups that should be made, I'm willing to take that on. Anyways, like I mentioned, I'm still a little ways from being ready to submit anything other than RFC patches in omapdrm to use fb refcnt'ing, so this isn't something that needs to be merged immediately. But it seemed like low risk and like it would be something that other drivers could take advantage of, so I figured it was worth sending this patch now. BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
Massive power regression going 3.4->3.5
On Tue, 2012-07-31 at 10:54 +0100, Chris Wilson wrote: > On Tue, 31 Jul 2012 10:37:35 +0100, James Bottomley HansenPartnership.com> wrote: > > On Tue, 2012-07-31 at 09:28 +0100, Chris Wilson wrote: > > > On Tue, 31 Jul 2012 09:06:42 +0100, James Bottomley > > HansenPartnership.com> wrote: > > > > Actually, bad news: it looks like the problem is drm: > > > > > > > > on 3.5 killing X causes idle power to go 14W -> 5.9W > > > > on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W > > > > > > The files that will be the most interesting to compare at first are: > > > > > > /sys/kernel/debug/dri/0/i915_drpc_info > > > /sys/kernel/debug/dri/0/i915_cur_delayinfo > > > /sys/kernel/debug/dri/0/i915_fbc_status > > > > This is for the good kernel 3.4.6 > > > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_drpc_info > > RC information accurate: yes > > Video Turbo Mode: yes > > HW control enabled: yes > > SW control enabled: no > > RC1e Enabled: no > > RC6 Enabled: yes > > Deep RC6 Enabled: no > > Deepest RC6 Enabled: no > > Current RC state: RC6 > > Core Power Down: no > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo > > GT_PERF_STATUS: 0x0d29 > > RPSTAT1: 0x00040d00 > > Render p-state ratio: 13 > > Render p-state VID: 41 > > Render p-state limit: 255 > > CAGF: 650MHz > > RP CUR UP EI: 20459us > > RP CUR UP: 172us > > RP PREV UP: 0us > > RP CUR DOWN EI: 0us > > RP CUR DOWN: 0us > > RP PREV DOWN: 0us > > Lowest (RPN) frequency: 650MHz > > Nominal (RP1) frequency: 650MHz > > Max non-overclocked (RP0) frequency: 1100MHz > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_fbc_status > > FBC disabled: disabled per module param (default off) > > > > And the bad kernel 3.5 > > > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_drpc_info > > RC information accurate: yes > > Video Turbo Mode: yes > > HW control enabled: yes > > SW control enabled: no > > RC1e Enabled: no > > RC6 Enabled: yes > > Deep RC6 Enabled: no > > Deepest RC6 Enabled: no > > Current RC state: RC6 > > Core Power Down: no > > RC6 "Locked to RPn" residency since boot: 0 > > RC6 residency since boot: 97671911 > > RC6+ residency since boot: 0 > > RC6++ residency since boot: 0 > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo > > GT_PERF_STATUS: 0x0d29 > > RPSTAT1: 0x00048d00 > > Render p-state ratio: 13 > > Render p-state VID: 41 > > Render p-state limit: 255 > > CAGF: 650MHz > > RP CUR UP EI: 63719us > > RP CUR UP: 26us > > RP PREV UP: 0us > > RP CUR DOWN EI: 0us > > RP CUR DOWN: 0us > > RP PREV DOWN: 0us > > Lowest (RPN) frequency: 650MHz > > Nominal (RP1) frequency: 650MHz > > Max non-overclocked (RP0) frequency: 1100MHz > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_fbc_status > > FBC disabled: disabled per module param (default off) > > Ok, that rules out the the easy case of rc6 being disabled or not > functioning at all, which could easily account for 6W. > > When did you inspect the debug files? One effect I can imagine is that > if your system was previously stuck at RPn and never upclocking the GPU > when X starts. The question would then be what is preventing the GPU > from reaching its lowest power state again. After I logged into an xfce4 session and powertop showed idle had been reached. James
Fix GPU triggering random system read after VRAM start change
On Fri, Jul 27, 2012 at 4:32 PM, wrote: > So first patch is a fix in itself, smallest possible and should go to > stable. Second patch is an improvement as a first step to flicker free > boot. First patch looks ok. In mc_stop we should disable the crtc and then poll CRTC_CONTROL.CRTC_CURRENT_MASTER_EN_STATE until it goes to 0 to make sure the crtc has actually stopped reading before we change the mc config. Other than that, Reviewed-by: Alex Deucher > > I have yet extensively tested second patch, especialy not on AGP but > so far on few GPU/motherboard it looks good. It can probably wait 3.7. > Will test it more and report. Looks good as well. A nice clean up to boot. > > I have a third patch that is a step closer to flicker free boot on uefi, > waiting ack to release a reg. > > Cheers, > Jerome > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Massive power regression going 3.4->3.5
On Tue, 31 Jul 2012 10:37:35 +0100, James Bottomley wrote: > On Tue, 2012-07-31 at 09:28 +0100, Chris Wilson wrote: > > On Tue, 31 Jul 2012 09:06:42 +0100, James Bottomley > HansenPartnership.com> wrote: > > > Actually, bad news: it looks like the problem is drm: > > > > > > on 3.5 killing X causes idle power to go 14W -> 5.9W > > > on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W > > > > The files that will be the most interesting to compare at first are: > > > > /sys/kernel/debug/dri/0/i915_drpc_info > > /sys/kernel/debug/dri/0/i915_cur_delayinfo > > /sys/kernel/debug/dri/0/i915_fbc_status > > This is for the good kernel 3.4.6 > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_drpc_info > RC information accurate: yes > Video Turbo Mode: yes > HW control enabled: yes > SW control enabled: no > RC1e Enabled: no > RC6 Enabled: yes > Deep RC6 Enabled: no > Deepest RC6 Enabled: no > Current RC state: RC6 > Core Power Down: no > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo > GT_PERF_STATUS: 0x0d29 > RPSTAT1: 0x00040d00 > Render p-state ratio: 13 > Render p-state VID: 41 > Render p-state limit: 255 > CAGF: 650MHz > RP CUR UP EI: 20459us > RP CUR UP: 172us > RP PREV UP: 0us > RP CUR DOWN EI: 0us > RP CUR DOWN: 0us > RP PREV DOWN: 0us > Lowest (RPN) frequency: 650MHz > Nominal (RP1) frequency: 650MHz > Max non-overclocked (RP0) frequency: 1100MHz > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_fbc_status > FBC disabled: disabled per module param (default off) > > And the bad kernel 3.5 > > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_drpc_info > RC information accurate: yes > Video Turbo Mode: yes > HW control enabled: yes > SW control enabled: no > RC1e Enabled: no > RC6 Enabled: yes > Deep RC6 Enabled: no > Deepest RC6 Enabled: no > Current RC state: RC6 > Core Power Down: no > RC6 "Locked to RPn" residency since boot: 0 > RC6 residency since boot: 97671911 > RC6+ residency since boot: 0 > RC6++ residency since boot: 0 > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo > GT_PERF_STATUS: 0x0d29 > RPSTAT1: 0x00048d00 > Render p-state ratio: 13 > Render p-state VID: 41 > Render p-state limit: 255 > CAGF: 650MHz > RP CUR UP EI: 63719us > RP CUR UP: 26us > RP PREV UP: 0us > RP CUR DOWN EI: 0us > RP CUR DOWN: 0us > RP PREV DOWN: 0us > Lowest (RPN) frequency: 650MHz > Nominal (RP1) frequency: 650MHz > Max non-overclocked (RP0) frequency: 1100MHz > jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_fbc_status > FBC disabled: disabled per module param (default off) Ok, that rules out the the easy case of rc6 being disabled or not functioning at all, which could easily account for 6W. When did you inspect the debug files? One effect I can imagine is that if your system was previously stuck at RPn and never upclocking the GPU when X starts. The question would then be what is preventing the GPU from reaching its lowest power state again. -Chris -- Chris Wilson, Intel Open Source Technology Centre
Re: [PATCH] drm: refcnt drm_framebuffer
On Tue, 31 Jul 2012 12:41:28 -0500, Rob Clark wrote: > On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson > wrote: > > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: > >> From: Rob Clark > >> > >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold > >> a ref to the fb when disabling a pipe until the next vblank, this > >> avoids the need to make disabling an overlay synchronous. This is a > >> problem that shows up when userspace is using a drm plane to > >> implement a hw cursor.. making overlay disable synchronous causes > >> a performance problem when x11 is rapidly enabling/disabling the > >> hw cursor. But not making it synchronous opens up a race condition > >> for crashing if userspace turns around and immediately deletes the > >> fb. Refcnt'ing the fb makes it possible to solve this problem. > > > > Presumably you have a follow-on patch putting the new refcnt to use so > > that we can judge whether you truly need refcnting on the fb itself in > > addition to the refcnted object and the various hw bookkeeping that > > needs to be performed? > > Yes, I do.. although it is a bit experimental at this point, so not > really ready to be submitted as anything other than an RFC.. it is > part of omapdrm kms re-write to use dispc directly rather than go thru > omapdss. (With omapdss we don't hit this issue because disabling > overlays is forced to be synchronous.. so instead we have the > performance problem I mentioned.) > > I *could* just rely on the GEM refcnt, but that gets messier when you > take into account multi-planar formats. I suppose I also could have > my own internal refcnt'd object to hold the set of GEM objects > associated w/ the fb, but, well, that seems a bit silly. And > refcnt'ing the fb had been mentioned previously as a good thing to do > (I think it was danvet?) Sure, there are a few places in the code that have caused ordering issues in the past due to lack of refcnting the fb... But since you haven't fixed up those cases, I'm looking for justification for adding that extra bit of complexity. Adding a new interface and no users is just asking for trouble. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: fix bank tiling parameters on SI
On Tue, Jul 31, 2012 at 10:21 AM, Christian K?nig
wrote:
> On 31.07.2012 16:02, Alex Deucher wrote:
>>
>> On Tue, Jul 31, 2012 at 7:48 AM, Christian K?nig
>> wrote:
>>>
>>> The sixteen bank case wasn't handled here, leading to GPU
>>> crashes because of userspace miscalculation.
>>
>> You mean a GPU hang or a segfault in userspace? IIRC, from the hw
>> perspective numbers of banks over 8 are considered 8 for tiling.
>
> Well it was a GPU segfault :) The GPU was accessing memory regions that
> weren't VM mapped.
>
> As far as i could figure it out it wasn't happy with the alignment of the
> color buffer. The number of banks we used for that calculation seemed to be
> different from what the kernel programmed into the tiling config registers.
> So I tried changing it from 8 to 16 and hurray it started working (ok, more
> or less currently digging into the next problem).
>
> It is possible that this is just masquerading another bug, but as far as I
> can see it is the most logical explanation.
Seems reasonable.
Reviewed-by: Alex Deucher
>
> Why are 16 banks equal to 8 banks on the hw side?
I was talking to one of the hw guys about some issues with tiling.
Certain 6xx or 7xx chips report more than 8 banks in the MC config,
but the tiling configuration on them only supports 4 and 8 banks.
IIRC, he said number of banks above 8 should be treated as 8 at least
for 6xx-9xx. Although, looking at it again it looks like maybe we
want 16 bank support for evergreen/cayman as well after all. It
shouldn't hurt other than possibly over allocating a bit.
Alex
>
> Christian.
>
>
>>
>> Alex
>>
>>> Signed-off-by: Christian K?nig
>>> Cc: stable at vger.kernel.org
>>> ---
>>> drivers/gpu/drm/radeon/si.c | 16
>>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
>>> index 0b02792..0182fc8 100644
>>> --- a/drivers/gpu/drm/radeon/si.c
>>> +++ b/drivers/gpu/drm/radeon/si.c
>>> @@ -1639,11 +1639,19 @@ static void si_gpu_init(struct radeon_device
>>> *rdev)
>>> /* XXX what about 12? */
>>> rdev->config.si.tile_config |= (3 << 0);
>>> break;
>>> - }
>>> - if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
>>> - rdev->config.si.tile_config |= 1 << 4;
>>> - else
>>> + }
>>> + switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
>>> + case 0: /* four banks */
>>> rdev->config.si.tile_config |= 0 << 4;
>>> + break;
>>> + case 1: /* eight banks */
>>> + rdev->config.si.tile_config |= 1 << 4;
>>> + break;
>>> + case 2: /* sixteen banks */
>>> + default:
>>> + rdev->config.si.tile_config |= 2 << 4;
>>> + break;
>>> + }
>>> rdev->config.si.tile_config |=
>>> ((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
>>> PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
>>> rdev->config.si.tile_config |=
>>> --
>>> 1.7.9.5
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
Re: [PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 12:00 PM, Chris Wilson wrote: > On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: >> From: Rob Clark >> >> This simplifies drm fb lifetime, and if the crtc/plane needs to hold >> a ref to the fb when disabling a pipe until the next vblank, this >> avoids the need to make disabling an overlay synchronous. This is a >> problem that shows up when userspace is using a drm plane to >> implement a hw cursor.. making overlay disable synchronous causes >> a performance problem when x11 is rapidly enabling/disabling the >> hw cursor. But not making it synchronous opens up a race condition >> for crashing if userspace turns around and immediately deletes the >> fb. Refcnt'ing the fb makes it possible to solve this problem. > > Presumably you have a follow-on patch putting the new refcnt to use so > that we can judge whether you truly need refcnting on the fb itself in > addition to the refcnted object and the various hw bookkeeping that > needs to be performed? Yes, I do.. although it is a bit experimental at this point, so not really ready to be submitted as anything other than an RFC.. it is part of omapdrm kms re-write to use dispc directly rather than go thru omapdss. (With omapdss we don't hit this issue because disabling overlays is forced to be synchronous.. so instead we have the performance problem I mentioned.) I *could* just rely on the GEM refcnt, but that gets messier when you take into account multi-planar formats. I suppose I also could have my own internal refcnt'd object to hold the set of GEM objects associated w/ the fb, but, well, that seems a bit silly. And refcnt'ing the fb had been mentioned previously as a good thing to do (I think it was danvet?) BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > 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
Massive power regression going 3.4->3.5
On Tue, 2012-07-31 at 09:28 +0100, Chris Wilson wrote: > On Tue, 31 Jul 2012 09:06:42 +0100, James Bottomley HansenPartnership.com> wrote: > > Actually, bad news: it looks like the problem is drm: > > > > on 3.5 killing X causes idle power to go 14W -> 5.9W > > on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W > > The files that will be the most interesting to compare at first are: > > /sys/kernel/debug/dri/0/i915_drpc_info > /sys/kernel/debug/dri/0/i915_cur_delayinfo > /sys/kernel/debug/dri/0/i915_fbc_status This is for the good kernel 3.4.6 jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_drpc_info RC information accurate: yes Video Turbo Mode: yes HW control enabled: yes SW control enabled: no RC1e Enabled: no RC6 Enabled: yes Deep RC6 Enabled: no Deepest RC6 Enabled: no Current RC state: RC6 Core Power Down: no jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo GT_PERF_STATUS: 0x0d29 RPSTAT1: 0x00040d00 Render p-state ratio: 13 Render p-state VID: 41 Render p-state limit: 255 CAGF: 650MHz RP CUR UP EI: 20459us RP CUR UP: 172us RP PREV UP: 0us RP CUR DOWN EI: 0us RP CUR DOWN: 0us RP PREV DOWN: 0us Lowest (RPN) frequency: 650MHz Nominal (RP1) frequency: 650MHz Max non-overclocked (RP0) frequency: 1100MHz jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_fbc_status FBC disabled: disabled per module param (default off) And the bad kernel 3.5 jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_drpc_info RC information accurate: yes Video Turbo Mode: yes HW control enabled: yes SW control enabled: no RC1e Enabled: no RC6 Enabled: yes Deep RC6 Enabled: no Deepest RC6 Enabled: no Current RC state: RC6 Core Power Down: no RC6 "Locked to RPn" residency since boot: 0 RC6 residency since boot: 97671911 RC6+ residency since boot: 0 RC6++ residency since boot: 0 jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo GT_PERF_STATUS: 0x0d29 RPSTAT1: 0x00048d00 Render p-state ratio: 13 Render p-state VID: 41 Render p-state limit: 255 CAGF: 650MHz RP CUR UP EI: 63719us RP CUR UP: 26us RP PREV UP: 0us RP CUR DOWN EI: 0us RP CUR DOWN: 0us RP PREV DOWN: 0us Lowest (RPN) frequency: 650MHz Nominal (RP1) frequency: 650MHz Max non-overclocked (RP0) frequency: 1100MHz jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_fbc_status FBC disabled: disabled per module param (default off) > However if it was simple regression in drm, then the bisect would have > continued to work despite the merge point jumping between 3.4 and 3.5, > right? No ... the bisect stepped back into 3.3 which mean I lost the ability to detect the regression. I think it might be fixable given I have a more precise identifier for the tree because it looks like none of the roots of the drm tree is before 3.4-rc. James
[Bug 44341] Radeon HD6990M: HDMI audio output works now! Kernel gives new warning
https://bugzilla.kernel.org/show_bug.cgi?id=44341 Christopher Fr?mmel changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE --- Comment #5 from Christopher Fr?mmel 2012-07-31 10:32:16 --- Fixed in 3.5 final -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/3] Move FIMD register headers to include/video/
Hello,
On Tuesday, July 31, 2012 10:19 AM Jingoo Han wrote:
> On Tuesday, July 31, 2012 3:28 PM Marek Szyprowski wrote:
> >
> > Hello,
> >
> > On Tuesday, July 31, 2012 2:48 AM Jingoo Han wrote:
> >
> > > On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote:
> > > >
> > > > Hello Jingoo Han,
> > > >
> > > > On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han
> > > > wrote:
> > > > > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote:
> > > > >>
> > > > >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side
> > > > >> to include/video/samsung_fimd.h
> > > > >>
> > > > >> Signed-off-by: Leela Krishna Amudala
> > > > >> ---
> > > > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 ---
> > > > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403
> > > > >> -
> > > > >> include/video/samsung_fimd.h| 533
> > > > >> +++
> > > > >> 3 files changed, 533 insertions(+), 562 deletions(-)
> > > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
> > > > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
> > > > >> create mode 100644 include/video/samsung_fimd.h
> > > > >>
> > > > >> +*/
> > > > >> +
> > > > >> +/*FIMD V8 REG OFFSET */
> > > > >> +#define FIMD_V8_VIDTCON0 (0x20010)
> > > > >> +#define FIMD_V8_VIDTCON1 (0x20014)
> > > > >> +#define FIMD_V8_VIDTCON2 (0x20018)
> > > > >> +#define FIMD_V8_VIDTCON3 (0x2001C)
> > > > >> +#define FIMD_V8_VIDCON1 (0x20004)
> > >
> > >
> > > How about using soc_is_exynos5250()?
> > >
> > > +#define VIDTCON0 (soc_is_exynos5250() ? \
> > > + (0x20010) : (0x10))
> > >
> > > In this case, the FIMD driver does not need to change.
> > > Also, one binary is available.
> >
> > Please don't mix two methods of runtime detection. FIMD driver (s3c-fb)
> > already
> > has runtime hw detection based on platform device id. Adding such detection
> > for
> > exynos5 to DRM FIMD driver should not be a big issue too.
>
> Marek,
> Then, do you want use like this?
>
> #define VIDTCON0 (0x10)
> +#define FIMD_V8_VIDTCON0 (0x20010)
>
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1924,7 +1924,7 @@ static struct s3c_fb_driverdata s3c_fb_data_exynos4 = {
> static struct s3c_fb_driverdata s3c_fb_data_exynos5 = {
> .variant = {
> .nr_windows = 5,
> - .vidtcon= VIDTCON0,
> + .vidtcon= FIMD_V8_VIDTCON0,
Yes, this method looks good imo. Maybe even having something like vidtcon_base
in
variant structure will be enough to cover all VIDTCON0-3 registers.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
[Bug 52997] New: evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 Bug #: 52997 Summary: evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: stevenvandenbrandenstift at gmail.com trying to run dungeon siege 2 via wine, intro plays fine and then hangs , found a radeon problem to be the cause. dmegs output: [ 7230.283645] radeon :00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice 4194303) [ 7230.283665] radeon :00:01.0: evergreen_cs_track_validate_cb:481 problematic surf: (32 8388608) (0 8 1 0 0 0 0) [ 7230.283675] radeon :00:01.0: evergreen_packet3_check:2096 invalid cmd stream 783 [ 7230.283684] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! [ 7231.299423] radeon :00:01.0: evergreen_cs_track_validate_cb:477 cb[0] bo too small (layer size -2147483648, offset 0, max layer 1, bo size 4096, slice 4194303) [ 7231.299434] radeon :00:01.0: evergreen_cs_track_validate_cb:481 problematic surf: (32 8388608) (0 8 1 0 0 0 0) [ 7231.299439] radeon :00:01.0: evergreen_packet3_check:2096 invalid cmd stream 783 [ 7231.299444] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream ! the wine errors (don't know if helpfull at all) show a directdraw problem ]$ wine ./.wine/drive_c/Program\ Files/2K\ Games/Dungeon\ Siege\ 2\ Broken\ World/DS2VideoConfig.exe fixme:ddraw:DirectDrawEnumerateExA flags 0x0007 not handled radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x33e048,0x), stub! radeon: The kernel rejected CS, see dmesg for more information. fixme:win:EnumDisplayDevicesW ((null),0,0x33e114,0x), stub! uname -a: 3.4.6-1-ARCH #1 SMP PREEMPT Fri Jul 20 08:21:26 CEST 2012 x86_64 GNU/Linux glxinfo: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD PALM OpenGL version string: 2.1 Mesa 8.0.4 OpenGL shading language version string: 1.20 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm/radeon: fix bank tiling parameters on SI
On Tue, Jul 31, 2012 at 7:48 AM, Christian K?nig
wrote:
> The sixteen bank case wasn't handled here, leading to GPU
> crashes because of userspace miscalculation.
You mean a GPU hang or a segfault in userspace? IIRC, from the hw
perspective numbers of banks over 8 are considered 8 for tiling.
Alex
>
> Signed-off-by: Christian K?nig
> Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/radeon/si.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index 0b02792..0182fc8 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -1639,11 +1639,19 @@ static void si_gpu_init(struct radeon_device *rdev)
> /* XXX what about 12? */
> rdev->config.si.tile_config |= (3 << 0);
> break;
> - }
> - if ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT)
> - rdev->config.si.tile_config |= 1 << 4;
> - else
> + }
> + switch ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) {
> + case 0: /* four banks */
> rdev->config.si.tile_config |= 0 << 4;
> + break;
> + case 1: /* eight banks */
> + rdev->config.si.tile_config |= 1 << 4;
> + break;
> + case 2: /* sixteen banks */
> + default:
> + rdev->config.si.tile_config |= 2 << 4;
> + break;
> + }
> rdev->config.si.tile_config |=
> ((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
> PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
> rdev->config.si.tile_config |=
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: refcnt drm_framebuffer
On Tue, 31 Jul 2012 11:20:21 -0500, Rob Clark wrote: > From: Rob Clark > > This simplifies drm fb lifetime, and if the crtc/plane needs to hold > a ref to the fb when disabling a pipe until the next vblank, this > avoids the need to make disabling an overlay synchronous. This is a > problem that shows up when userspace is using a drm plane to > implement a hw cursor.. making overlay disable synchronous causes > a performance problem when x11 is rapidly enabling/disabling the > hw cursor. But not making it synchronous opens up a race condition > for crashing if userspace turns around and immediately deletes the > fb. Refcnt'ing the fb makes it possible to solve this problem. Presumably you have a follow-on patch putting the new refcnt to use so that we can judge whether you truly need refcnting on the fb itself in addition to the refcnted object and the various hw bookkeeping that needs to be performed? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Tue, Jul 31, 2012 at 5:16 AM, Luca Tettamanti wrote: > On Mon, Jul 30, 2012 at 10:45 PM, Alex Deucher > wrote: >> Regarding patches 3 and 4, it might be easier to just store a pointer >> to the relevant encoder when you verify ATIF rather than walking the >> encoder list every time. > > Makes sense, I was unsure about the lifetime of the encoders, but > AFAICS they're destroyed only when the module in unloaded. They are present for the life of the driver. Alex
[PATCH] drm/radeon: Mark all possible functions / structs as static
On Tue, Jul 31, 2012 at 12:43 AM, Dave Airlie wrote: > On Tue, Jul 31, 2012 at 12:45 AM, Alex Deucher > wrote: >> On Fri, Jul 27, 2012 at 5:34 PM, Lauri Kasanen wrote: >>> Let's allow GCC to optimize better. >>> >>> This exposed some five unused functions, but this patch doesn't remove them. >>> >>> Signed-off-by: Lauri Kasanen >> >> Reviewed-by: Alex Deucher > > You might want to take this one step further and fix all the warnings > it introduces here, I think these are mostly left-overs from porting code from the ddx. All can be safely removed. > > CC [M] drivers/gpu/drm/radeon/radeon_combios.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/radeon_combios.c:3307:13: > warning: ?radeon_combios_dyn_clk_setup? defined but not used > [-Wunused-function] Can be removed. COMBIOS_DYN_CLK_1_TABLE is already parsed in radeon_combios_asic_init(). radeon_combios_dyn_clk_setup() is redundant. > CC [M] drivers/gpu/drm/radeon/radeon_legacy_crtc.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/radeon_legacy_crtc.c:209:13: > warning: ?radeon_restore_common_regs? defined but not used > [-Wunused-function] Can be removed. The function is empty. It was a leftover from the ddx save/restore code. > > CC [M] drivers/gpu/drm/radeon/r100.o > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/r100.c:2548:13: > warning: ?r100_gpu_wait_for_vsync? defined but not used > [-Wunused-function] > /home/airlied/devel/kernel/drm-next/drivers/gpu/drm/radeon/r100.c:2570:13: > warning: ?r100_gpu_wait_for_vsync2? defined but not used > [-Wunused-function] Both can be removed. Remnants from the ddx. Alex
[PATCH 1/3] Move FIMD register headers to include/video/
On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: > > Hello Jingoo Han, > > On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han wrote: > > On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: > >> > >> Moved the contents of regs-fb-v4.h and regs-fb.h from arch side > >> to include/video/samsung_fimd.h > >> > >> Signed-off-by: Leela Krishna Amudala > >> --- > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 - > >> include/video/samsung_fimd.h| 533 > >> +++ > >> 3 files changed, 533 insertions(+), 562 deletions(-) > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > >> create mode 100644 include/video/samsung_fimd.h > >> > >> +*/ > >> + > >> +/*FIMD V8 REG OFFSET */ > >> +#define FIMD_V8_VIDTCON0 (0x20010) > >> +#define FIMD_V8_VIDTCON1 (0x20014) > >> +#define FIMD_V8_VIDTCON2 (0x20018) > >> +#define FIMD_V8_VIDTCON3 (0x2001C) > >> +#define FIMD_V8_VIDCON1 (0x20004) How about using soc_is_exynos5250()? +#define VIDTCON0 (soc_is_exynos5250() ? \ + (0x20010) : (0x10)) In this case, the FIMD driver does not need to change. Also, one binary is available. Best regards, Jingoo Han > > > > > > CC'ed Marek. > > > > To Leela Krishna Amudala, > > > > Don't add these definitions for FIMD_V8_xxx registers, which arenot related > > to current "regs-fb-v4.h > and regs-fb.h". > > Just "move" and "merge" regs-fb-v4.h and regs-fb.h to one header file, not > > "add" new definitions. > > If you want to add these definitions, please make new patch for this. > > > > Will do it in the suggested way, > > > > Also, "#define FIMD_V8_xxx" is ugly. > > I think that there is better way. > > Please, find other way. > > > > > > I used FIMD_V8_xxx instead of EXYNOS5_FIMD_*, because in future, > there is a possibility that version 8 FIMD can be used in other > application processors also. > Thanks for reviewing the patch. > > Best Wishes, > Leela Krishna. > > >> -- > >> 1.7.0.4 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > > the body of a message to majordomo at vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] solving omapdrm/omapdss layering issues
On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen wrote: > Hi, > > On Fri, 2012-07-27 at 20:07 -0500, Rob Clark wrote: >> From: Rob Clark >> >> I've been working for the better part of the week on solving some of >> the omapdss vs kms mismatches, which is one of the bigger remaining >> issues in the TODO before moving omapdrm out of staging. >> >> The biggest place that this shows up is in GO bit handling. Basically, >> some of the scanout related registers in DSS hw block are only shadow >> registers, and if the GO bit is set during the vblank the hw copies >> into the actual registers (not accessible to CPU) and clears the GO >> bit. When the GO bit is set, there is no safe way to update these >> registers without undefined results. So omapdss tries to be friendly >> and abstract this, by buffering up the updated state, and applying it > > It's not really about being friendly. Omapdss tries to do as little as > possible, while still supporting all its HW features. Shadow registers > are a bit tricky creating this mess. What I mean by 'friendly' is it tries to abstract this for simple users, like an fbdev driver. But this really quickly breaks down w/ a more sophisticated user. Which is why I've been more in favor of making omapdss less of a layer. The idea of using it as some helper functions which handle a bit the variation of different generations of hw while not abstracting the fundamental operating concepts of DSS IP block (ie. GO bit stuff) seems perfect to me. So dispc plus dss_feature stuff seems like just what I'm looking for. >> on the next vblank once the GO bit is cleared. But this causes all >> sorts of mayhem at the omapdrm layer, which would like to unpin the >> previous scanout buffer(s) on the next vblank (or endwin) irq. Due >> to the buffering in omapdss, we have no way to know on a vblank if we >> have switched to the scanout buffer or not. Basically it works ok as >> long as userspace is only ever updating on layer (either crtc or drm >> plane) at a time. But throw together hw mouse cursor (drm plane) >> plus a window manager like compiz which does page flips, or wayland >> (weston drm compositor) with hw composition (drm plane), and things >> start to fail in a big way. >> >> I've tried a few approaches to preserve the omapdss more or less as it >> is, by adding callbacks for when GO bit is cleared, etc. But the >> sequencing of setting up connector/encoder/crtc is not really what >> omapdss expects, and would generally end up confusing the "apply" >> layer in omapdss (it would end up not programming various registers >> because various dirty flags would get cleared, for example mgr updated >> before overlay connected, etc). > > Can you give more info what the problem is? It shouldn't end up not > programming registers, except if there's a bug there. Yeah, it is probably just a bug.. and a bug could be fixed. But with all that extra code it is certainly a lot harder to debug. So 'could' and 'should' are maybe two different things. > Didn't the apply-id stuff I proposed some months ago have enough stuff > to make this work? I guess the approach I was trying was similar to that proposal.. it probably could be made to work. But I am really not a big fan of unnecessary complexity. And unnecessary layering adds complexity. This is why in general most of the drm folks have preferred an approach of helper fxns rather than layers. And I tend to agree with them. > The thing about shadow registers is that we need to manage them in one > central place. And the same shadow registers are used for both the > composition stuff (overlays etc) and output stuff (video timings & > configuration). If omapdrm handles the composition shadow registers, it > also needs to handle all the other shadow registers. Yup.. I'm handling it in a central place :-) basically all the register programming is coming through the 'struct omap_drm_apply' mechanism, so it is all aligned to vblank/framedone and GO bit status. So probably that isn't strictly needed, because I'm treating all registers as shadow'd registers, but that seemed like a clean approach. >> Finally, in frustration, this afternoon I hit upon an idea. Why not >> just use the dispc code in omapdss, which is basically a stateless >> layer of helper functions, and bypass the stateful layer of omapdss. > > If you do this, you'll need to implement all the stuff of the stateful > layer in omapdrm. You can't just call the dispc funcs and expect things > to work reliably. Things like enabling/disabling overlays with fifomerge > requires possibly multiple vsyncs. And output related shadow registers > may be changed separately from the composition side. All the dispc fxn calls (except whatever is done directly from the 'omap_dss_device', which I haven't converted over yet) are done synchronized to the ovl mgrs GO bit. I haven't hooked up fifomerge yet, although looking at the apply code in omapdss, that looks like it should be pretty
