[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mercredi 1 ao?t 2012 14:35:03 Laurent Pinchart, vous avez ?crit : > > But in general, the V4L element in the pipeline does not know how fast > > the downstream element(s) will consume the buffers. Thus it has to copy > > from the MMAP buffers into anonymous user memory pending processing. > > Then any dequeued buffer can be requeued as soon as possible. In theory, > > it might also be that, even though the latency is known, the number of > > required buffers exceeds the maximum MMAP buffers count of the V4L > > device. Either way, user space ends up doing memory copy from MMAP to > > custom buffers. > > > > This problem does not exist with USERBUF - the V4L2 element can simply > > allocate a new buffer for each dequeued buffer. > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. -- R?mi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis
[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
? ??2012-08-01 ? 15:49 +0200?Luca Tettamanti ???
> AMD ACPI interface may overload the standard event
> ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> userspace because the user did not press the mode switch key (the
> spurious keypress confuses the DE which usually changes the
> display configuration and messes up a dual-screen setup).
> This patch gives the radeon driver the chance to examine the event and
> block the keypress if the event is an "AMD event".
>
> Signed-off-by: Luca Tettamanti
Tested-by: Lee, Chun-Yi
This patch works to me on my HP notebook to avoid (VGA, 0x81) notify
event issued when AC-power unpluged.
Thanks
Joey Lee
> ---
> Any comment from ACPI front?
>
> drivers/acpi/video.c | 10 --
> drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 1e0a9e1..a8592c4 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> acpi_video_device_enumerate(video);
> acpi_video_device_rebind(video);
> acpi_bus_generate_proc_event(device, event, 0);
> - keycode = KEY_SWITCHVIDEOMODE;
> + /* This event is also overloaded by AMD ACPI interface, don't
> + * send the key press if the event has been handled elsewhere
> + * (e.g. radeon DRM driver).
> + */
> + if (!acpi_notifier_call_chain(device, event, 0))
> + keycode = KEY_SWITCHVIDEOMODE;
> break;
>
> case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
> */
> @@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> break;
> }
>
> - if (event != ACPI_VIDEO_NOTIFY_SWITCH)
> + if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
> + event != ACPI_VIDEO_NOTIFY_PROBE)
> acpi_notifier_call_chain(device, event, 0);
>
> if (keycode) {
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index 96de08d..ee0d29e 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
> }
> /* TODO: check other events */
>
> - return NOTIFY_OK;
> + /* We've handled the event, stop the notifier chain. The ACPI interface
> + * overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
> + * userspace if the event was generated only to signal a SBIOS
> + * request.
> + */
> + return NOTIFY_BAD;
> }
>
> /* Call all ACPI methods here */
[RFC 0/3] solving omapdrm/omapdss layering issues
Hi, On Wednesday 01 August 2012 07:55 PM, Rob Clark wrote: > On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen > wrote: >> On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: >>> On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen >>> wrote: >> 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 >> >> No, that's not what omapdss tries to do. I'm not trying to hide the >> shadow registers and the GO bit behind the omapdss API, I'm just trying >> to make it work. >> >> The omapdss API was made with omapfb, so it's true that the API may not >> be good for omapdrm. But I'm happy to change the API. >> >>> And btw, I think the current mapping of drm_encoder to mgr in omapdrm >>> is not correct. I'm just in the process of shuffling things around. >>> I think drm/kms actually maps quite nicely to the underlying hardware >>> with the following arrangement: >>> >>> drm_plane -> ovl >>> drm_crtc -> mgr >>> drm_encoder -> DSI/DPI/HDMI/VENC encoder >>> drm_connector -> pretty much what we call a panel driver today >> >> Hmm, what was the arrangement earlier? > > it was previously: > >plane -> ovl >crtc -> placeholder >encoder -> mgr >connector -> dssdev (encoder+panel) > > although crtc is really the point where you should enable/disable > vblank irqs, so the new arrangement is somewhat cleaner (although on > my branch the encoder/connector part are not finished yet) > >> I guess the fact is that DRM concepts do not really match the OMAP DSS >> hardware, and we'll have to use whatever gives us least problems. > > Actually, I think it does map fairly well to the hardware.. at least > more so than to omapdss ;-) > > The one area that kms mismatches a bit is decoupling of ovl from mgr > that we have in our hw.. I've partially solved that a while back w/ > the patch in drm to add "private planes" so the omap_crtc internally > uses an omap_plane. It isn't exposed to userspace to be able to > re-use the planes from unused crtcs, although I have some ideas about > that (but not yet time to work on it). > >>> It would be quite useful if you could look at the omap_drm_apply >>> mechanism I had in omapdrm, because that seems like a quite >>> straightforward way to deal w/ shadowed registers. I think it will >> >> Yes, it seems straightforward, but it's not =). >> >> I had a look at your omapdrm-on-dispc-2 branch. What you are doing there >> is quite similar to what omapdss was doing earlier. It's not going to >> work reliably with multiple outputs and fifomerge. >> >> Configuring things like overlay color mode are quite simple. They only >> affect that one overlay. Also things like manager default bg color are >> simple, they affect only that one manager. >> >> But enabling/disabling an overlay or a manager, changing the destination >> mgr of an overlay, fifomerge... Those are not simple. You can't do them >> directly, as you do in your branch. >> >> As an example, consider the case of enabling an overlay (vid1), and >> moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll >> first need to take the fifo buffers from gfx, set GO, and wait for the >> settings to take effect. Only then you can set the fifo buffers for >> vid1, enable it and set GO bit. > > hmm, it does sound like it needs a bit of a state machine to deal with > multi-step updates.. although that makes races more of a problem, > which was something I was trying hard to avoid. > > For enabling/disabling an output (manager+encoder), this is relatively > infrequent, so it can afford to block to avoid races. (Like userspace > enabling and then rapidly disabling an output part way through the > enable.) But enabling/disabling an overlay, or adjusting position or > scanout address must not block. And ideally, if possible, switching > an overlay between two managers should not block. > > For fifomerge, if I understand correctly, it shouldn't really be > needed for functionality, but mainly as a power optimization? If this > is the case I wonder about an approach of disabling fifomerge when > there are ongoing setting changes, and then setting it after things > settle down? I'll have to think about it, but I was trying to avoid > needing a multi-step state machine to avoid the associated race > conditions, but if this is not possible then it is not possible. > >> I didn't write omapdss's apply.c for fun or to make omapfb simpler. I >> made it because the shadow register system is complex, and we need to >> handle the tricky cases somewhere. >> >> So, as I said before, I believe you'll just end up writing similar code >> to what is currently in apply.c. It won't be as simple as your current >> branch. >> >> Also, as I mentioned earlier, you
Massive power regression going 3.4->3.5
On 2012-08-01 03:06, Chris Wilson wrote: > On Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley > wrote: >> On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: >> > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley >> wrote: >> > > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: >> > > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley >> wrote: >> > > > > I got the attached to apply and it doesn't really improve >> the idle power >> > > > > much (12.5W). >> > > > >> > > > That's good to know. Next step is to try overriding >> i915.semaphores. >> > > > Can you please test with i915.semaphores=0 and >> i915.semaphores=1? >> > > >> > > There's not much point doing i915_semaphores=1 since that's the >> default >> > > on gen 6 hardware, but i915_semaphores=0 recovers and idle power >> of >> > > ~6.5W >> > >> > It is only the default if iommu is off, and changing the default >> > was one of the side-effects of the patch you bisected. >> > >> > Can you please login to the desktop, let it idle, record >> > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. >> > Then trace-cmd record -e i915 sleep 10s, >> >> OK, what is trace-cmd? It looks similar to perf tools ... is that >> it? > > Yes, it is roughly equivalent and you should be able to achieve the > same > with perf trace - except I haven't done it before so I don't have > quick > advice on how to drive it. :) > -Chris Should be something like: perf record -f -g -e i915:* -a
Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On 三, 2012-08-01 at 15:49 +0200, Luca Tettamanti wrote:
> AMD ACPI interface may overload the standard event
> ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> userspace because the user did not press the mode switch key (the
> spurious keypress confuses the DE which usually changes the
> display configuration and messes up a dual-screen setup).
> This patch gives the radeon driver the chance to examine the event and
> block the keypress if the event is an "AMD event".
>
> Signed-off-by: Luca Tettamanti
> ---
> Any comment from ACPI front?
>
it looks good to me.
But I'm wondering if we can use the following code for ACPI part, which
looks cleaner.
I know this may change the behavior of other events, but in theory, we
should not send any input event if we know something wrong in kernel.
what do you think?
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..8ad1f53 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1448,8 +1448,7 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
case ACPI_VIDEO_NOTIFY_SWITCH: /* User requested a switch,
* most likely via hotkey. */
acpi_bus_generate_proc_event(device, event, 0);
- if (!acpi_notifier_call_chain(device, event, 0))
- keycode = KEY_SWITCHVIDEOMODE;
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_PROBE: /* User plugged in or removed a video
@@ -1479,8 +1478,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
- acpi_notifier_call_chain(device, event, 0);
+ if (acpi_notifier_call_chain(device, event, 0))
+ keycode = 0;
if (keycode) {
input_report_key(input, keycode, 1);
> drivers/acpi/video.c | 10 --
> drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 1e0a9e1..a8592c4 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> acpi_video_device_enumerate(video);
> acpi_video_device_rebind(video);
> acpi_bus_generate_proc_event(device, event, 0);
> - keycode = KEY_SWITCHVIDEOMODE;
> + /* This event is also overloaded by AMD ACPI interface, don't
> + * send the key press if the event has been handled elsewhere
> + * (e.g. radeon DRM driver).
> + */
> + if (!acpi_notifier_call_chain(device, event, 0))
> + keycode = KEY_SWITCHVIDEOMODE;
> break;
>
> case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
> */
> @@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> break;
> }
>
> - if (event != ACPI_VIDEO_NOTIFY_SWITCH)
> + if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
> + event != ACPI_VIDEO_NOTIFY_PROBE)
> acpi_notifier_call_chain(device, event, 0);
>
> if (keycode) {
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index 96de08d..ee0d29e 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
> }
> /* TODO: check other events */
>
> - return NOTIFY_OK;
> + /* We've handled the event, stop the notifier chain. The ACPI interface
> + * overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
> + * userspace if the event was generated only to signal a SBIOS
> + * request.
> + */
> + return NOTIFY_BAD;
> }
>
> /* Call all ACPI methods here */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mercredi 1 août 2012 14:35:03 Laurent Pinchart, vous avez écrit : > > But in general, the V4L element in the pipeline does not know how fast > > the downstream element(s) will consume the buffers. Thus it has to copy > > from the MMAP buffers into anonymous user memory pending processing. > > Then any dequeued buffer can be requeued as soon as possible. In theory, > > it might also be that, even though the latency is known, the number of > > required buffers exceeds the maximum MMAP buffers count of the V4L > > device. Either way, user space ends up doing memory copy from MMAP to > > custom buffers. > > > > This problem does not exist with USERBUF - the V4L2 element can simply > > allocate a new buffer for each dequeued buffer. > > What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? Does CREATE_BUFS always work while already streaming has already started? If it depends on the driver, it's kinda helpless. What's the guaranteed minimum buffer count? It seems in any case, MMAP has a hard limit of 32 buffers (at least videobuf2 has), though one might argue this should be more than enough. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
於 三，2012-08-01 於 15:49 +0200，Luca Tettamanti 提到：
> AMD ACPI interface may overload the standard event
> ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
> cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
> userspace because the user did not press the mode switch key (the
> spurious keypress confuses the DE which usually changes the
> display configuration and messes up a dual-screen setup).
> This patch gives the radeon driver the chance to examine the event and
> block the keypress if the event is an "AMD event".
>
> Signed-off-by: Luca Tettamanti
Tested-by: Lee, Chun-Yi
This patch works to me on my HP notebook to avoid (VGA, 0x81) notify
event issued when AC-power unpluged.
Thanks
Joey Lee
> ---
> Any comment from ACPI front?
>
> drivers/acpi/video.c | 10 --
> drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
> index 1e0a9e1..a8592c4 100644
> --- a/drivers/acpi/video.c
> +++ b/drivers/acpi/video.c
> @@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> acpi_video_device_enumerate(video);
> acpi_video_device_rebind(video);
> acpi_bus_generate_proc_event(device, event, 0);
> - keycode = KEY_SWITCHVIDEOMODE;
> + /* This event is also overloaded by AMD ACPI interface, don't
> + * send the key press if the event has been handled elsewhere
> + * (e.g. radeon DRM driver).
> + */
> + if (!acpi_notifier_call_chain(device, event, 0))
> + keycode = KEY_SWITCHVIDEOMODE;
> break;
>
> case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
> */
> @@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
> *device, u32 event)
> break;
> }
>
> - if (event != ACPI_VIDEO_NOTIFY_SWITCH)
> + if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
> + event != ACPI_VIDEO_NOTIFY_PROBE)
> acpi_notifier_call_chain(device, event, 0);
>
> if (keycode) {
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index 96de08d..ee0d29e 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
> }
> /* TODO: check other events */
>
> - return NOTIFY_OK;
> + /* We've handled the event, stop the notifier chain. The ACPI interface
> + * overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
> + * userspace if the event was generated only to signal a SBIOS
> + * request.
> + */
> + return NOTIFY_BAD;
> }
>
> /* Call all ACPI methods here */
___
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 #83 from Jerome Glisse 2012-08-02 03:46:43 UTC --- How do you trigger the va issue ? piglit ? I was not able to reproduce. It's kind of painful to debug in the dark. -- 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
[RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, 2012-08-01 at 11:53 -0500, Rob Clark wrote: > Ok.. this would help. I'll take a look. I do request that > interfaces/panels don't set any mgr/timing related registers. I had > to comment all this stuff out in my prototype. Really we want to set > the timings separately on the crtc (mgr) / encoder (interface) / > connector (panel.. not sure if it is needed, though?). KMS will take > care of propagating the timings through the pipeline. If we only had auto-update displays, and only the video timings were shadow register, it'd work. Unfortunately we have other registers as shadow registers also, like DISPC_CONTROL1, DISPC_CONFIG1 and DISPC_DIVISOR1. But we should think if this could be somehow be changed, so that all the shadow register info would come from one place. I do find it a bit unlikely with a quick thought, though. Well, hmm. Perhaps... Omapdrm (or omapfb etc) doesn't really need to know about the values of those registers, it just needs to control the GO bit. So perhaps if we had some method to inform omapdrm that these things have changed, and omapdrm would then set the GO bit as soon as possible. But there are some tricky stuff, like the divisors... Well, we need to think about this. 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/20120801/2d978c2f/attachment-0001.pgp>
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Sylwester Nawrocki wrote: > > Hi, > > On 08/01/2012 11:39 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> 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. > >> > > NACK. your changes are not adding just moving. So should be squashed. If > > required, you could create just one patch for moving them, probably, 1st, > > 3rd, 4th and 5th patches into one patch. > > Yes, this patch series is mainly moving files around. But to avoid git > bisect breakage, it should be split as it is done now, or the whole > series should be squashed into one patch. The latter might be even easier > to handle, but having a single patch touching arch/arm/ and drivers/ > might not be a good idea. If you're fine handling that, then we just > need to squash this series into single patch. > It just need to be ensured, IMO, there is no bisection breakage. > I know you meant. But we don't need to keep the changes 'adding and removing' for just moving on this. I commented on 0/5 patch in this series before, if this is ready, I will create topic branch so that it could be merged into both mine and Florian's. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: > > On 08/01/2012 02:28 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> 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. > >> > > (Cc'ed Florian Tobias Schandinat) > > > > Yeah, since it's merge window, this series could be created against on > > mainline. And IMO, would be helpful to us if this series could be sent > to > > upstream via samsung tree after reviewing, because this touches too many > > files in samsung tree and just adds include/video/samsung_fimd.h. But > I'm > > not sure the added inclusion will be used in other file of drivers/video. > If > > so, I can provide some topic branch can be merged into Florian's tree. > > Florian, how about? > > Using a topic branch to merge it in both trees sounds like a good plan > to me. > Sure, if this change is ready, I will create topic branch then let you know. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH] staging: drm/omap: remove reclaim_buffers callback
The reclaim_buffers callback has already been removed by Daniel Vetter
with his patch "drm: kill reclaim_buffers callback"
(b0071efe82). As a result the kernel compilation fails with omapdrm support
and so the callback for reclaim_buffers is being removed from omapdrm.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/staging/omapdrm/omap_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 342645a..b8e79eb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
.irq_postinstall = dev_irq_postinstall,
.irq_uninstall = dev_irq_uninstall,
.irq_handler = dev_irq_handler,
- .reclaim_buffers = drm_core_reclaim_buffers,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
--
1.7.10
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Leela Krishna Amudala wrote: > > 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. > NACK. your changes are not adding just moving. So should be squashed. If required, you could create just one patch for moving them, probably, 1st, 3rd, 4th and 5th patches into one patch. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Thank you Sylwester for suggesting this split up change. > > Regards, > Leela Krishna
[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 #79 from Alexandre Demers 2012-08-01 18:06:40 UTC --- (In reply to comment #78) > (In reply to comment #77) > > (In reply to comment #70) > > > Does this kernel patch help? > > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html > > > > No, it doesn't (well not about the present bug). > > This patch is mostly for the lockup situation, it does not affect the va > issue. > My patch should definitely fix va issue. Alex patch might fix lockup on top of > that. OK, so I should try them together then. I should be able to test it tonight. As of this morning with Alex's patch only, va issue was still reported but I had no time to test it further for lockups. -- 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 #82 from Alexandre Demers 2012-08-02 01:02:42 UTC --- (In reply to comment #80) > I tried both patches, the one from comment 76 and the one from comment 70, > neither fixed the issue with the rendering regression or the va conflict. Same here, I was rebuilding my kernel from scratch just in case. -- 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 #81 from Anthony Waters 2012-08-02 00:47:06 UTC --- Created attachment 65051 --> https://bugs.freedesktop.org/attachment.cgi?id=65051 fixes to wait on the bo and to free the va after the kernel These are the changes I made to make it work in mesa, the first change, inserting radeon_bo_wait was so that the va wouldn't be immediately reallocated for a different va while the GPU was still using it causing the rendering regression. The second change was to move the freeing of the va in mesa after the kernel was freed so that the kernel's list would be updated before mesa's list. Hopefully this provides more insight to the issue/cause -- 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
drm/nouveau: crash regression in 3.5
On 30.07.2012 19:16, Marcin Slusarz wrote: > Are you sure you boot the correct kernel? I'm asking because your panic says > its > version is "3.5.0 #3" - exactly the same as in previous crash log. I am using the correct kernel, don't worry. (.version may not be incremented on each build necessarily). I am still seeing the same crash with all your patches, but only with "noaccel=1". I have added some printk's (starting with XXX), but can not obtain them via netconsole. I think netconsole may have been disabled and replaced with the real console at that point already? When I boot with noaccel I can see the printk's in the log on disk. That log is attached. I am sorry that I can not provide better information. Thanks, Ortwin -- next part -- Aug 1 17:34:31 localhost kernel: console [netcon0] enabled Aug 1 17:34:31 localhost kernel: netconsole: network logging started Aug 1 17:34:31 localhost kernel: ALSA device list: Aug 1 17:34:31 localhost kernel: #0: HDA Intel at 0xd752 irq 54 Aug 1 17:34:31 localhost kernel: #1: HDA NVidia at 0xd300 irq 17 Aug 1 17:34:31 localhost kernel: hub 2-0:1.0: hub_suspend Aug 1 17:34:31 localhost kernel: usb usb2: bus auto-suspend, wakeup 1 Aug 1 17:34:31 localhost kernel: ehci_hcd :00:1d.0: suspend root hub Aug 1 17:34:31 localhost kernel: EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) Aug 1 17:34:31 localhost kernel: VFS: Mounted root (ext4 filesystem) readonly on device 8:5. Aug 1 17:34:31 localhost kernel: devtmpfs: mounted Aug 1 17:34:31 localhost kernel: Freeing unused kernel memory: 540k freed Aug 1 17:34:31 localhost kernel: Write protecting the kernel read-only data: 12288k Aug 1 17:34:31 localhost kernel: Freeing unused kernel memory: 476k freed Aug 1 17:34:31 localhost kernel: Freeing unused kernel memory: 1052k freed Aug 1 17:34:31 localhost udevd[1411]: starting version 171 Aug 1 17:34:31 localhost kernel: usb 1-1.5: usb auto-resume Aug 1 17:34:31 localhost kernel: usb 1-1.5: finish resume Aug 1 17:34:31 localhost kernel: usb 1-1.5: disable remote wakeup, status -32 Aug 1 17:34:31 localhost kernel: usb 1-1.5: link qh4-0001/8802288bb080 start 3 [1/0 us] Aug 1 17:34:31 localhost kernel: usb 1-1.5: unlink qh4-0001/8802288bb080 start 3 [1/0 us] Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: loaded firmware version 9.221.4.1 build 25532 Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: CONFIG_IWLWIFI_DEBUG disabled Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: CONFIG_IWLWIFI_DEBUGFS disabled Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: CONFIG_IWLWIFI_P2P disabled Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74 Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: L1 Disabled; Enabling L0S Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: device EEPROM VER=0x436, CALIB=0x6 Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: Device SKU: 0x1F0 Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: Valid Tx ant: 0x7, Valid Rx ant: 0x7 Aug 1 17:34:31 localhost kernel: iwlwifi :44:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels Aug 1 17:34:31 localhost kernel: Registered led device: phy0-led Aug 1 17:34:31 localhost kernel: ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' Aug 1 17:34:31 localhost kernel: pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f: Aug 1 17:34:31 localhost kernel: excluding 0xc-0xf Aug 1 17:34:31 localhost kernel: pcmcia_socket pcmcia_socket0: cs: memory probe 0xa000-0xa0ff: Aug 1 17:34:31 localhost kernel: excluding 0xa000-0xa0ff Aug 1 17:34:31 localhost kernel: pcmcia_socket pcmcia_socket0: cs: memory probe 0x6000-0x60ff: Aug 1 17:34:31 localhost kernel: excluding 0x6000-0x60ff Aug 1 17:34:31 localhost kernel: MXM: GUID detected in BIOS Aug 1 17:34:31 localhost kernel: [drm:drm_pci_init], Aug 1 17:34:31 localhost kernel: [drm:drm_get_pci_dev], Aug 1 17:34:31 localhost kernel: [drm:drm_get_minor], Aug 1 17:34:31 localhost kernel: [drm:drm_get_minor], new minor assigned 64 Aug 1 17:34:31 localhost kernel: [drm:drm_get_minor], Aug 1 17:34:31 localhost kernel: [drm:drm_get_minor], new minor assigned 0 Aug 1 17:34:31 localhost kernel: [drm] nouveau :01:00.0: nouveau_load:1045 - vendor: 0x10DE device: 0xCBC class: 0x3 Aug 1 17:34:31 localhost kernel: [drm] nouveau :01:00.0: Detected an NV50 generation card (0x0a3e00a2) Aug 1 17:34:31 localhost NetworkManager[2346]:SCPlugin-Ifnet: Initializing! Aug 1 17:34:31 localhost NetworkManager[2346]:SCPlugin-Ifnet: management mode: managed Aug 1 17:34:31 localhost NetworkMana
[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 #80 from Anthony Waters 2012-08-02 00:41:23 UTC --- I tried both patches, the one from comment 76 and the one from comment 70, neither fixed the issue with the rendering regression or the va conflict. -- 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
[RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 12:38 PM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 11:53 -0500, Rob Clark wrote: > >> Ok.. this would help. I'll take a look. I do request that >> interfaces/panels don't set any mgr/timing related registers. I had >> to comment all this stuff out in my prototype. Really we want to set >> the timings separately on the crtc (mgr) / encoder (interface) / >> connector (panel.. not sure if it is needed, though?). KMS will take >> care of propagating the timings through the pipeline. > > If we only had auto-update displays, and only the video timings were > shadow register, it'd work. Unfortunately we have other registers as > shadow registers also, like DISPC_CONTROL1, DISPC_CONFIG1 and > DISPC_DIVISOR1. well, I was kinda thinking we just do all the register access from the corresponding crtc (mgr)'s GO/apply sequencing.. so if, for example, you change resolution, then the plane, crtc, encoder, panel all queue up via omap_crtc_apply() on their associated crtc, and then at the right time from pre_apply() fxns call the appropriate omapdss/dispc function(s) for register updates. I think that would work well for everything but mgr enable/disable (which is infrequent, so ok to block for a few vblanks), and fifomerge, which I'm a bit on the fence about. > But we should think if this could be somehow be changed, so that all the > shadow register info would come from one place. I do find it a bit > unlikely with a quick thought, though. > > Well, hmm. Perhaps... Omapdrm (or omapfb etc) doesn't really need to > know about the values of those registers, it just needs to control the > GO bit. So perhaps if we had some method to inform omapdrm that these > things have changed, and omapdrm would then set the GO bit as soon as > possible. Well, what I'm doing now is basically, if I update anything in any of the omap_*_info structs, I schedule an apply, and from pre_apply callback push the changes down to dispc.. I was thinking to follow the same for encoder and probably connector. (Not sure if doing things like setting timings at hdmi need to be GO bit sync'd? Maybe this could be bypassed for the connector, but if not it is easy enough just to use the same mechanism that the plane/crtc/encoder are already using.) > But there are some tricky stuff, like the divisors... Well, we need to > think about this. I think, if I understand properly, the most tricky thing is the shared clocks.. although I'm not really sure if we can actually change things like the core clock when you plug in a 2nd display w/out loosing sync on the first? That's seems like a tricky thing either way. Anything else, that is only effecting a single crtc->encoder->connector chain can have register programming sync'd to that mgr's GO bit. BR, -R > Tomi >
[Bug 53045] Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 Anatoly Berbeka changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53045] Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 --- Comment #2 from Anatoly Berbeka 2012-08-01 17:36:12 UTC --- Thanks, this patch works for me. Now everything is fine. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 3/3] drm: Add misssing static storage class specifier in drm_fb_helper.c file
Fixes the following sparse warning:
drivers/gpu/drm/drm_fb_helper.c:239:6: warning:
symbol 'drm_fb_helper_force_kernel_mode' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/drm_fb_helper.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f546d1e..061d26d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -236,7 +236,7 @@ bool drm_fb_helper_restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
}
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode);
-bool drm_fb_helper_force_kernel_mode(void)
+static bool drm_fb_helper_force_kernel_mode(void)
{
bool ret, error = false;
struct drm_fb_helper *helper;
--
1.7.4.1
[PATCH 2/3] drm: Add missing static storage class specifier in drm_irq.c file
Fixes the following sparse warning:
drivers/gpu/drm/drm_irq.c:1239:6:
warning: symbol 'drm_handle_vblank_events' was not declared. Should it be
static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/drm_irq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 03f16f3..076c4a8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1236,7 +1236,7 @@ done:
return ret;
}
-void drm_handle_vblank_events(struct drm_device *dev, int crtc)
+static void drm_handle_vblank_events(struct drm_device *dev, int crtc)
{
struct drm_pending_vblank_event *e, *t;
struct timeval now;
--
1.7.4.1
[PATCH 1/3] drm: Add missing static storage class specifiers in drm_proc.c file
Fixes the following sparse warning:
drivers/gpu/drm/drm_proc.c:92:5:
warning: symbol 'drm_proc_create_files' was not declared. Should it be static?
drivers/gpu/drm/drm_proc.c:175:5:
warning: symbol 'drm_proc_remove_files' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/gpu/drm/drm_proc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index 371c695..da457b1 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -89,7 +89,7 @@ static const struct file_operations drm_proc_fops = {
* Create a given set of proc files represented by an array of
* gdm_proc_lists in the given root directory.
*/
-int drm_proc_create_files(struct drm_info_list *files, int count,
+static int drm_proc_create_files(struct drm_info_list *files, int count,
struct proc_dir_entry *root, struct drm_minor *minor)
{
struct drm_device *dev = minor->dev;
@@ -172,7 +172,7 @@ int drm_proc_init(struct drm_minor *minor, int minor_id,
return 0;
}
-int drm_proc_remove_files(struct drm_info_list *files, int count,
+static int drm_proc_remove_files(struct drm_info_list *files, int count,
struct drm_minor *minor)
{
struct list_head *pos, *q;
--
1.7.4.1
[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 #78 from Jerome Glisse 2012-08-01 16:59:03 UTC --- (In reply to comment #77) > (In reply to comment #70) > > Does this kernel patch help? > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html > > No, it doesn't (well not about the present bug). This patch is mostly for the lockup situation, it does not affect the va issue. My patch should definitely fix va issue. Alex patch might fix lockup on top of that. -- 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 #77 from Alexandre Demers 2012-08-01 16:09:21 UTC --- (In reply to comment #70) > Does this kernel patch help? > http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html No, it doesn't (well not about the present bug). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] staging: drm/omap: remove reclaim_buffers callback
On Wed, Aug 1, 2012 at 3:02 PM, Chandrabhanu Mahapatra
wrote:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers
> callback"
> for which the kernel compilation fails with omapdrm support. So, the callback
> for reclaim_buffers is removed from omapdrm.
>
> Signed-off-by: Chandrabhanu Mahapatra
Reviewed-by: Sumit Semwal
> ---
> drivers/staging/omapdrm/omap_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.c
> b/drivers/staging/omapdrm/omap_drv.c
> index 342645a..b8e79eb 100644
> --- a/drivers/staging/omapdrm/omap_drv.c
> +++ b/drivers/staging/omapdrm/omap_drv.c
> @@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
> .irq_postinstall = dev_irq_postinstall,
> .irq_uninstall = dev_irq_uninstall,
> .irq_handler = dev_irq_handler,
> - .reclaim_buffers = drm_core_reclaim_buffers,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = omap_debugfs_init,
> .debugfs_cleanup = omap_debugfs_cleanup,
> --
> 1.7.10
>
> --
> 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/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
AMD ACPI interface may overload the standard event
ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
userspace because the user did not press the mode switch key (the
spurious keypress confuses the DE which usually changes the
display configuration and messes up a dual-screen setup).
This patch gives the radeon driver the chance to examine the event and
block the keypress if the event is an "AMD event".
Signed-off-by: Luca Tettamanti
---
Any comment from ACPI front?
drivers/acpi/video.c | 10 --
drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..a8592c4 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
- keycode = KEY_SWITCHVIDEOMODE;
+ /* This event is also overloaded by AMD ACPI interface, don't
+* send the key press if the event has been handled elsewhere
+* (e.g. radeon DRM driver).
+*/
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
@@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+ if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
+ event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);
if (keycode) {
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 96de08d..ee0d29e 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
}
/* TODO: check other events */
- return NOTIFY_OK;
+ /* We've handled the event, stop the notifier chain. The ACPI interface
+* overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
+* userspace if the event was generated only to signal a SBIOS
+* request.
+*/
+ return NOTIFY_BAD;
}
/* Call all ACPI methods here */
--
1.7.10.4
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 12:38 PM, Tomi Valkeinen wrote: > On Wed, 2012-08-01 at 11:53 -0500, Rob Clark wrote: > >> Ok.. this would help. I'll take a look. I do request that >> interfaces/panels don't set any mgr/timing related registers. I had >> to comment all this stuff out in my prototype. Really we want to set >> the timings separately on the crtc (mgr) / encoder (interface) / >> connector (panel.. not sure if it is needed, though?). KMS will take >> care of propagating the timings through the pipeline. > > If we only had auto-update displays, and only the video timings were > shadow register, it'd work. Unfortunately we have other registers as > shadow registers also, like DISPC_CONTROL1, DISPC_CONFIG1 and > DISPC_DIVISOR1. well, I was kinda thinking we just do all the register access from the corresponding crtc (mgr)'s GO/apply sequencing.. so if, for example, you change resolution, then the plane, crtc, encoder, panel all queue up via omap_crtc_apply() on their associated crtc, and then at the right time from pre_apply() fxns call the appropriate omapdss/dispc function(s) for register updates. I think that would work well for everything but mgr enable/disable (which is infrequent, so ok to block for a few vblanks), and fifomerge, which I'm a bit on the fence about. > But we should think if this could be somehow be changed, so that all the > shadow register info would come from one place. I do find it a bit > unlikely with a quick thought, though. > > Well, hmm. Perhaps... Omapdrm (or omapfb etc) doesn't really need to > know about the values of those registers, it just needs to control the > GO bit. So perhaps if we had some method to inform omapdrm that these > things have changed, and omapdrm would then set the GO bit as soon as > possible. Well, what I'm doing now is basically, if I update anything in any of the omap_*_info structs, I schedule an apply, and from pre_apply callback push the changes down to dispc.. I was thinking to follow the same for encoder and probably connector. (Not sure if doing things like setting timings at hdmi need to be GO bit sync'd? Maybe this could be bypassed for the connector, but if not it is easy enough just to use the same mechanism that the plane/crtc/encoder are already using.) > But there are some tricky stuff, like the divisors... Well, we need to > think about this. I think, if I understand properly, the most tricky thing is the shared clocks.. although I'm not really sure if we can actually change things like the core clock when you plug in a 2nd display w/out loosing sync on the first? That's seems like a tricky thing either way. Anything else, that is only effecting a single crtc->encoder->connector chain can have register programming sync'd to that mgr's GO bit. BR, -R > Tomi > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: drm/omap: remove reclaim_buffers callback
The reclaim_buffers callback has already been removed by Daniel Vetter
with his patch "drm: kill reclaim_buffers callback"
for which the kernel compilation fails with omapdrm support. So, the callback
for reclaim_buffers is removed from omapdrm.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/staging/omapdrm/omap_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 342645a..b8e79eb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
.irq_postinstall = dev_irq_postinstall,
.irq_uninstall = dev_irq_uninstall,
.irq_handler = dev_irq_handler,
- .reclaim_buffers = drm_core_reclaim_buffers,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
--
1.7.10
[PATCH] staging: drm/omap: remove reclaim_buffers callback
Am Mittwoch, den 01.08.2012, 15:02 +0530 schrieb Chandrabhanu Mahapatra:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers
> callback"
Please add the first eight characters of the commit hash behind the
summary in parentheses.
> for which the kernel compilation fails with omapdrm support. So, the callback
> for reclaim_buffers is removed from omapdrm.
>
> Signed-off-by: Chandrabhanu Mahapatra
> ---
> drivers/staging/omapdrm/omap_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.c
> b/drivers/staging/omapdrm/omap_drv.c
> index 342645a..b8e79eb 100644
> --- a/drivers/staging/omapdrm/omap_drv.c
> +++ b/drivers/staging/omapdrm/omap_drv.c
> @@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
> .irq_postinstall = dev_irq_postinstall,
> .irq_uninstall = dev_irq_uninstall,
> .irq_handler = dev_irq_handler,
> - .reclaim_buffers = drm_core_reclaim_buffers,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = omap_debugfs_init,
> .debugfs_cleanup = omap_debugfs_cleanup,
Acked-by: Paul Menzel
Thanks,
Paul
-- 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/20120801/c430ca71/attachment.pgp>
Bug report
Problem: GPU hangs Chipset: Intel 845 GV + ICH4 Video: integrated Linux kernel: 3.3.5, 3.4.7 (no bug difference) X.Org X Server 1.7.7 How to reproduce: First Xorg start is ok, bug happens after Xorg restart Syslog: Aug 1 17:13:18 nika kernel: [ 1049.248033] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Aug 1 17:13:18 nika kernel: [ 1049.248045] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state Aug 1 17:13:20 nika kernel: [ 1051.736033] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Aug 1 17:13:20 nika kernel: [ 1051.740699] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! Aug 1 17:13:20 nika kernel: [ 1051.740706] [drm:i915_reset] *ERROR* Failed to reset chip. Aug 1 17:15:57 nika kernel: [ 1208.915038] WARNING: at /root/build_scgs/build/linux-3.4.7/drivers/gpu/drm/i915/i915_gem.c:2410 i915_gem_object_put_fence+0x5b/0x86 [i915]() Aug 1 17:15:57 nika kernel: [ 1208.915042] Hardware name: Aug 1 17:15:57 nika kernel: [ 1208.915045] Modules linked in: fuse ext3 jbd microcode i915 snx(O) i2c_i801 evdev pcspkr parport_pc parport drm_kms_helper processor drm rng_core i2c_algo_bit button intel_agp i2c_core intel_gtt video agpgart ext2 mbcache usb_storage uas usbhid hid sd_mod crc_t10dif via_rhine mii ata_piix libata uhci_hcd scsi_mod ehci_hcd usbcore thermal usb_common fan thermal_sys [last unloaded: scsi_wait_scan] Aug 1 17:15:57 nika kernel: [ 1208.915104] Pid: 1583, comm: Xorg Tainted: G O 3.4.7-1-nika #1 Aug 1 17:15:57 nika kernel: [ 1208.915107] Call Trace: Aug 1 17:15:57 nika kernel: [ 1208.915118] [] ? warn_slowpath_common+0x68/0x79 Aug 1 17:15:57 nika kernel: [ 1208.915132] [] ? i915_gem_object_put_fence+0x5b/0x86 [i915] Aug 1 17:15:57 nika kernel: [ 1208.915137] [] ? warn_slowpath_null+0xd/0x10 Aug 1 17:15:57 nika kernel: [ 1208.915150] [] ? i915_gem_object_put_fence+0x5b/0x86 [i915] Aug 1 17:15:57 nika kernel: [ 1208.915164] [] ? i915_gem_object_unbind+0x9a/0x13f [i915] Aug 1 17:15:57 nika kernel: [ 1208.915177] [] ? i915_gem_free_object_tail+0x15/0xae [i915] Aug 1 17:15:57 nika kernel: [ 1208.915195] [] ? drm_gem_object_free+0x1d/0x1e [drm] Aug 1 17:15:57 nika kernel: [ 1208.915212] [] ? drm_gem_object_unreference_unlocked+0x26/0x32 [i915] Aug 1 17:15:57 nika kernel: [ 1208.915226] [] ? intel_user_framebuffer_destroy+0x10/0x18 [i915] Aug 1 17:15:57 nika kernel: [ 1208.915240] [] ? drm_fb_release+0x3a/0x52 [drm] Aug 1 17:15:57 nika kernel: [ 1208.915250] [] ? drm_release+0x289/0x4b4 [drm] Aug 1 17:15:57 nika kernel: [ 1208.915257] [] ? fput+0xd4/0x195 Aug 1 17:15:57 nika kernel: [ 1208.915261] [] ? filp_close+0x52/0x58 Aug 1 17:15:57 nika kernel: [ 1208.915267] [] ? put_files_struct+0x4c/0x90 Aug 1 17:15:57 nika kernel: [ 1208.915271] [] ? do_exit+0x1ec/0x60f Aug 1 17:15:57 nika kernel: [ 1208.915276] [] ? restore_sigcontext+0xbf/0xec Aug 1 17:15:57 nika kernel: [ 1208.915280] [] ? sys_sigreturn+0x62/0x86 Aug 1 17:15:57 nika kernel: [ 1208.915285] [] ? do_group_exit+0x3e/0x5f Aug 1 17:15:57 nika kernel: [ 1208.915289] [] ? sys_exit_group+0x11/0x11 Aug 1 17:15:57 nika kernel: [ 1208.915294] [] ? syscall_call+0x7/0xb Aug 1 17:15:57 nika kernel: [ 1208.915298] ---[ end trace d758b3315db37a86 ]---
[PATCH] drm: refcnt drm_framebuffer
On Tue, Jul 31, 2012 at 02:28:29PM -0500, Rob Clark wrote: > 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 >> chris-wilson.co.uk> 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() Your patch would still significantly change the behavior of drm_mode_rmfb(). Currently it disables all planes and crtcs which currently use the fb, and it removes the fb id from the idr so that no new users of the fb can appear afterwards. Not that I really like the current behaviour of drm_mode_rmfb(), but it's been like that always, so changing it doesn't seem acceptable. -- Ville Syrj?l? Intel OTC
[Bug 53045] Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 --- Comment #1 from Jerome Glisse 2012-08-01 14:32:27 UTC --- Created attachment 65037 --> https://bugs.freedesktop.org/attachment.cgi?id=65037 Disable crtc after mc setup Attached kernel patch should fix your issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 53045] New: Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 Bug #: 53045 Summary: Incorrect picture with AMD 6970 Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: ekzo.tech at gmail.com I apologize for my English. I have incorrect picture. After installing Arch Linux or Opensuse 12.1 the picture seems like divided at 3 fragments, but instead [1 2 3] I have [3 1 2] or [2 3 1]. (Look the photo). No matter with which monitor - I tried 2 monitors. Sometimes I receive just black screen (1 of 3 cases, or [3 1 2] or [2 3 1]). I have this problem at TTY and X too. CPU: AMD Phenom II X4 GPU: AMD 6970 Xorg driver: xf86-video-ati 1:6.14.6-1 Photo of TTY console: http://img194.imageshack.us/img194/9861/112233d.jpg Photo of X desktop running XFCE4: http://img694.imageshack.us/img694/6843/111222333q.jpg Kernel version: Linux sirius 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux dmesg output: https://gist.github.com/3226626 lspci output: https://gist.github.com/3226632 xrandr output: https://gist.github.com/3226636 Xorg.0.log | grep EDID log: https://gist.github.com/3226645 Full Xorg.0.log: https://gist.github.com/3227022 Please, tell me which information I had to provide to help solve this problem. -- 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 Wednesday 01 August 2012 10:37:02 R?mi Denis-Courmont wrote: > On Tue, 31 Jul 2012 23:52:35 +0200, Laurent Pinchart wrote: > >> 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 ? > > As I wrote several times earlier, MMAP uses fixed number of buffers. In > some tightly controlled media pipeline with low latency, it might work. Sorry about making you repeat. > But in general, the V4L element in the pipeline does not know how fast the > downstream element(s) will consume the buffers. Thus it has to copy from > the MMAP buffers into anonymous user memory pending processing. Then any > dequeued buffer can be requeued as soon as possible. In theory, it might > also be that, even though the latency is known, the number of required > buffers exceeds the maximum MMAP buffers count of the V4L device. Either > way, user space ends up doing memory copy from MMAP to custom buffers. > > This problem does not exist with USERBUF - the V4L2 element can simply > allocate a new buffer for each dequeued buffer. What about using the CREATE_BUFS ioctl to add new MMAP buffers at runtime ? > By the way, this was already discussed a few months ago for the exact same > DMABUF patch series... -- Regards, Laurent Pinchart
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.
[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3
https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #10 from Roland Scheidegger 2012-08-01 13:07:09 UTC --- With 5b88a2a22daae4d09596804d8edc6b8796d05150 attachment 63712, 63716, 63717, 63718 are obsolete. Still unsure what to do with the others. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
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.
[RFC 0/3] solving omapdrm/omapdss layering issues
On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: > On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen > wrote: > > 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 No, that's not what omapdss tries to do. I'm not trying to hide the shadow registers and the GO bit behind the omapdss API, I'm just trying to make it work. The omapdss API was made with omapfb, so it's true that the API may not be good for omapdrm. But I'm happy to change the API. > And btw, I think the current mapping of drm_encoder to mgr in omapdrm > is not correct. I'm just in the process of shuffling things around. > I think drm/kms actually maps quite nicely to the underlying hardware > with the following arrangement: > > drm_plane -> ovl > drm_crtc -> mgr > drm_encoder -> DSI/DPI/HDMI/VENC encoder > drm_connector -> pretty much what we call a panel driver today Hmm, what was the arrangement earlier? I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems. > It would be quite useful if you could look at the omap_drm_apply > mechanism I had in omapdrm, because that seems like a quite > straightforward way to deal w/ shadowed registers. I think it will Yes, it seems straightforward, but it's not =). I had a look at your omapdrm-on-dispc-2 branch. What you are doing there is quite similar to what omapdss was doing earlier. It's not going to work reliably with multiple outputs and fifomerge. Configuring things like overlay color mode are quite simple. They only affect that one overlay. Also things like manager default bg color are simple, they affect only that one manager. But enabling/disabling an overlay or a manager, changing the destination mgr of an overlay, fifomerge... Those are not simple. You can't do them directly, as you do in your branch. As an example, consider the case of enabling an overlay (vid1), and moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll first need to take the fifo buffers from gfx, set GO, and wait for the settings to take effect. Only then you can set the fifo buffers for vid1, enable it and set GO bit. I didn't write omapdss's apply.c for fun or to make omapfb simpler. I made it because the shadow register system is complex, and we need to handle the tricky cases somewhere. So, as I said before, I believe you'll just end up writing similar code to what is currently in apply.c. It won't be as simple as your current branch. Also, as I mentioned earlier, you'll also need to handle the output side of the shadow registers. These come from the output drivers (DPI, DSI, etc, and indirectly from panel drivers). They are not currently handled in the best manner in omapdss, but Archit is working on that and in his version apply.c will handle also those properly. About your code, I see you have these pre and post apply callbacks that handle the configuration. Wouldn't it be rather easy to have omapdss's apply.c call these? And then one thing I don't think you've considered is manual update displays. Of course, one option is to not support those with omapdrm, but that's quite a big decision. omapdss's apply.c handles those also. Also, can you check again my mail "Re: OMAPDSS vsyncs/apply" Sat, 12 May 2012 10:01:24, about the request_config() suggestion. I think that would be somewhat similar to your pre/post callbacks. I'll try to write some prototype for the request_config suggestion so that it's easier to understand. 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/20120801/0354c2ea/attachment.pgp>
[PATCH] staging: drm/omap: remove reclaim_buffers callback
On Wed, Aug 1, 2012 at 8:20 AM, Chandrabhanu Mahapatra
wrote:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers
> callback"
> (b0071efe82). As a result the kernel compilation fails with omapdrm support
> and so the callback for reclaim_buffers is being removed from omapdrm.
>
> Signed-off-by: Chandrabhanu Mahapatra
Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.c
> b/drivers/staging/omapdrm/omap_drv.c
> index 342645a..b8e79eb 100644
> --- a/drivers/staging/omapdrm/omap_drv.c
> +++ b/drivers/staging/omapdrm/omap_drv.c
> @@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
> .irq_postinstall = dev_irq_postinstall,
> .irq_uninstall = dev_irq_uninstall,
> .irq_handler = dev_irq_handler,
> - .reclaim_buffers = drm_core_reclaim_buffers,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = omap_debugfs_init,
> .debugfs_cleanup = omap_debugfs_cleanup,
> --
> 1.7.10
>
> --
> 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
[RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 11:53 AM, Rob Clark wrote: > On Wed, Aug 1, 2012 at 11:46 AM, Archit Taneja wrote: >> Hi, >> >> >> On Wednesday 01 August 2012 07:55 PM, Rob Clark wrote: >>> >>> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >>> wrote: On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: > > On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen > wrote: >> 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 No, that's not what omapdss tries to do. I'm not trying to hide the shadow registers and the GO bit behind the omapdss API, I'm just trying to make it work. The omapdss API was made with omapfb, so it's true that the API may not be good for omapdrm. But I'm happy to change the API. > And btw, I think the current mapping of drm_encoder to mgr in omapdrm > is not correct. I'm just in the process of shuffling things around. > I think drm/kms actually maps quite nicely to the underlying hardware > with the following arrangement: > > drm_plane -> ovl > drm_crtc -> mgr > drm_encoder -> DSI/DPI/HDMI/VENC encoder > drm_connector -> pretty much what we call a panel driver today Hmm, what was the arrangement earlier? >>> >>> >>> it was previously: >>> >>>plane -> ovl >>>crtc -> placeholder >>>encoder -> mgr >>>connector -> dssdev (encoder+panel) >>> >>> although crtc is really the point where you should enable/disable >>> vblank irqs, so the new arrangement is somewhat cleaner (although on >>> my branch the encoder/connector part are not finished yet) >>> I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems. >>> >>> >>> Actually, I think it does map fairly well to the hardware.. at least >>> more so than to omapdss ;-) >>> >>> The one area that kms mismatches a bit is decoupling of ovl from mgr >>> that we have in our hw.. I've partially solved that a while back w/ >>> the patch in drm to add "private planes" so the omap_crtc internally >>> uses an omap_plane. It isn't exposed to userspace to be able to >>> re-use the planes from unused crtcs, although I have some ideas about >>> that (but not yet time to work on it). >>> > It would be quite useful if you could look at the omap_drm_apply > mechanism I had in omapdrm, because that seems like a quite > straightforward way to deal w/ shadowed registers. I think it will Yes, it seems straightforward, but it's not =). I had a look at your omapdrm-on-dispc-2 branch. What you are doing there is quite similar to what omapdss was doing earlier. It's not going to work reliably with multiple outputs and fifomerge. Configuring things like overlay color mode are quite simple. They only affect that one overlay. Also things like manager default bg color are simple, they affect only that one manager. But enabling/disabling an overlay or a manager, changing the destination mgr of an overlay, fifomerge... Those are not simple. You can't do them directly, as you do in your branch. As an example, consider the case of enabling an overlay (vid1), and moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll first need to take the fifo buffers from gfx, set GO, and wait for the settings to take effect. Only then you can set the fifo buffers for vid1, enable it and set GO bit. >>> >>> >>> hmm, it does sound like it needs a bit of a state machine to deal with >>> multi-step updates.. although that makes races more of a problem, >>> which was something I was trying hard to avoid. >>> >>> For enabling/disabling an output (manager+encoder), this is relatively >>> infrequent, so it can afford to block to avoid races. (Like userspace >>> enabling and then rapidly disabling an output part way through the >>> enable.) But enabling/disabling an overlay, or adjusting position or >>> scanout address must not block. And ideally, if possible, switching >>> an overlay between two managers should not block. >>> >>> For fifomerge, if I understand correctly, it shouldn't really be >>> needed for functionality, but mainly as a power optimization? If this >>> is the case I wonder about an approach of disabling fifomerge when >>> there are ongoing setting changes, and then setting it after things >>> settle down? I'll have to think about it, but I was trying to avoid >>> needing a multi-step state machine to avoid the associated race >>> conditions, but if this is not possible then it is not possible. >>> I didn't writ
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Hi, On 08/01/2012 11:39 AM, Kukjin Kim wrote: > Leela Krishna Amudala wrote: >> 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. >> > NACK. your changes are not adding just moving. So should be squashed. If > required, you could create just one patch for moving them, probably, 1st, > 3rd, 4th and 5th patches into one patch. Yes, this patch series is mainly moving files around. But to avoid git bisect breakage, it should be split as it is done now, or the whole series should be squashed into one patch. The latter might be even easier to handle, but having a single patch touching arch/arm/ and drivers/ might not be a good idea. If you're fine handling that, then we just need to squash this series into single patch. It just need to be ensured, IMO, there is no bisection breakage. -- Regards, Sylwester
[RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 11:46 AM, Archit Taneja wrote: > Hi, > > > On Wednesday 01 August 2012 07:55 PM, Rob Clark wrote: >> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> wrote: >>> >>> On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen wrote: >>> >>> > 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 >>> >>> >>> No, that's not what omapdss tries to do. I'm not trying to hide the >>> shadow registers and the GO bit behind the omapdss API, I'm just trying >>> to make it work. >>> >>> The omapdss API was made with omapfb, so it's true that the API may not >>> be good for omapdrm. But I'm happy to change the API. >>> And btw, I think the current mapping of drm_encoder to mgr in omapdrm is not correct. I'm just in the process of shuffling things around. I think drm/kms actually maps quite nicely to the underlying hardware with the following arrangement: drm_plane -> ovl drm_crtc -> mgr drm_encoder -> DSI/DPI/HDMI/VENC encoder drm_connector -> pretty much what we call a panel driver today >>> >>> >>> Hmm, what was the arrangement earlier? >> >> >> it was previously: >> >>plane -> ovl >>crtc -> placeholder >>encoder -> mgr >>connector -> dssdev (encoder+panel) >> >> although crtc is really the point where you should enable/disable >> vblank irqs, so the new arrangement is somewhat cleaner (although on >> my branch the encoder/connector part are not finished yet) >> >>> I guess the fact is that DRM concepts do not really match the OMAP DSS >>> hardware, and we'll have to use whatever gives us least problems. >> >> >> Actually, I think it does map fairly well to the hardware.. at least >> more so than to omapdss ;-) >> >> The one area that kms mismatches a bit is decoupling of ovl from mgr >> that we have in our hw.. I've partially solved that a while back w/ >> the patch in drm to add "private planes" so the omap_crtc internally >> uses an omap_plane. It isn't exposed to userspace to be able to >> re-use the planes from unused crtcs, although I have some ideas about >> that (but not yet time to work on it). >> It would be quite useful if you could look at the omap_drm_apply mechanism I had in omapdrm, because that seems like a quite straightforward way to deal w/ shadowed registers. I think it will >>> >>> >>> Yes, it seems straightforward, but it's not =). >>> >>> I had a look at your omapdrm-on-dispc-2 branch. What you are doing there >>> is quite similar to what omapdss was doing earlier. It's not going to >>> work reliably with multiple outputs and fifomerge. >>> >>> Configuring things like overlay color mode are quite simple. They only >>> affect that one overlay. Also things like manager default bg color are >>> simple, they affect only that one manager. >>> >>> But enabling/disabling an overlay or a manager, changing the destination >>> mgr of an overlay, fifomerge... Those are not simple. You can't do them >>> directly, as you do in your branch. >>> >>> As an example, consider the case of enabling an overlay (vid1), and >>> moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll >>> first need to take the fifo buffers from gfx, set GO, and wait for the >>> settings to take effect. Only then you can set the fifo buffers for >>> vid1, enable it and set GO bit. >> >> >> hmm, it does sound like it needs a bit of a state machine to deal with >> multi-step updates.. although that makes races more of a problem, >> which was something I was trying hard to avoid. >> >> For enabling/disabling an output (manager+encoder), this is relatively >> infrequent, so it can afford to block to avoid races. (Like userspace >> enabling and then rapidly disabling an output part way through the >> enable.) But enabling/disabling an overlay, or adjusting position or >> scanout address must not block. And ideally, if possible, switching >> an overlay between two managers should not block. >> >> For fifomerge, if I understand correctly, it shouldn't really be >> needed for functionality, but mainly as a power optimization? If this >> is the case I wonder about an approach of disabling fifomerge when >> there are ongoing setting changes, and then setting it after things >> settle down? I'll have to think about it, but I was trying to avoid >> needing a multi-step state machine to avoid the associated race >> conditions, but if this is not possible then it is not possible. >> >>> I didn't write omapdss's apply.c for fun or to make omapfb simpler. I >>> made it because the shadow register system is complex, and we need to >>> handle the tricky cases somewhere
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans,
>>
>> I do not see any good point in using v4l2_plane. What would be the meaning
>> of bytesused, length, data_offset in case of DMABUF exporting?
>>
>> The field reserved0 was introduced to be replaced by __u32 memory if other
>> means
>> of buffer description would be needed. The reserved fields at the end of
>> the structure could be used for auxiliary parameters other then offset and
>> flags.
>> The flags field is expected to be used by all exporting types therefore the
>> layout could be reorganized to:
>>
>> struct v4l2_exportbuffers {
>> __u32 fd;
>> __u32 flags;
>> __u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
>> alignment */
>> __u32 mem_offset; /* what do you thing about using 64-bit field? */
>> __u32 reserved1[11];
>> };
>>
>> What is your opinion about this idea?
>
> You're missing the point of my argument. How does v4l2_buffer work currently:
> you
> have a memory field and a union. The memory field determines which field of
> the
> union is to be used. In order to be able to use VIDIOC_EXPBUF you need to be
> able to add new memory types in the future. Currently only MMAP makes sense
> here,
> so all you need is the offset, but in order to be able to support future
> memory
> types you need to make sure that you can extend v4l2_exportbuffers with the
> largest possible value that v4l2_buffers can contain in the union, and that's
> an unsigned long/pointer. That won't fit in the current proposal since there
> is only
> a u32.
>
> So I would propose this:
>
> struct v4l2_exportbuffers {
> __u32 fd;
> __u32 memory;
> union {
> __u32 mem_offset;
> void *reserved; /* ensure that we can handle pointers in the
> future */
> } m;
> __u32 flags;
> __u32 reserved1[11];
> };
The layout about prevents adding any auxiliary fields other then mem_offset if
expbuf.memory == V4L2_MEMORY_MMAP. This could be fixed by the layout below
(it might be considered ugly by some people):
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 memory;
__u32 reserved;
union {
struct v4l2_exportbyoffset {
__u32 mem_offset;
__u32 reserved[11];
} byoffset;
struct v4l2_exportbyuserptr {
__u64 userptr;
__u32 reserved[10];
} byuserptr;
__u32 reserved[12];
};
};
Notice that the structure above in binary compatible with:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2];
__u32 mem_offset;
__u32 reserved1[11];
};
>
> That way an application can just do:
>
> struct v4l2_buffer buf;
> struct v4l2_exportbuffers expbuf;
>
> expbuf.memory = buf.memory;
> memcpy(&expbuf.m, &buf.m, sizeof(expbuf.m));
>
> and VIDIOC_EXPBUF will return an error if expbuf.memory != V4L2_MEMORY_MMAP.
The other question is if we should use V4L2_MEMORY_MMAP as expbuf.memory.
I think that new enums should be introduced for this purpose. Exporting is
very different from buffer requesting or queuing. One could envision
extension to VIDIOC_EXPBUF for exporting a buffer as entity different then
DMABUF file. In such a case, the fd and flags should go to a separate union.
This argument supports *not* using any v4l2_buffer related structs for
VIDIOC_EXPBUF.
It should use its own structures. Likely, no extra structs are needed at the
moment.
>
> I was actually wondering whether it might not be an idea to pass a v4l2_buffer
> directly to VIDIOC_EXPBUF. In order to support that you would have to add fd
> fields to v4l2_buffer and v4l2_plane and those would be filled in by
> VIDIOC_EXPBUF.
> For the flags field in exportbuffers you would have to add new V4L2_BUF_FLAG_
> flags.
>
> That way you don't need to introduce a new struct and all planes are also
> automatically exported. It's just an idea...
One may not want to create DMABUF descriptors for all the planes.
The number of file descriptors is limited for the process.
Why creating file descriptor if they are going to closed or
(even worse) not used?
The mmap is called on each plane separately. So why VIDIOC_EXPBUF should
behave differently?
Regards,
Tomasz Stanislawski
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Leela Krishna Amudala wrote: > > 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. > (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > 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%)
[PATCH V2 4/5] driver: Include the modified FIMD header file
Leela Krishna Amudala wrote: > > 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(-) > [...] > --- a/drivers/video/s3c-fb.c > +++ b/drivers/video/s3c-fb.c > @@ -26,7 +26,7 @@ > #include > > #include > -#include > +#include > #include > See my previous comments. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
Leela Krishna Amudala wrote: > > 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 NO! Don't just replace it. Please put the inclusions with the same kind like following. diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index ea785fc..90d8daa 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -29,6 +29,7 @@ #include #include +#include #include #include #include @@ -39,7 +40,6 @@ #include #include -#include #include #include #include Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
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) > -- > 1.7.0.4 All of EXYNOS5 SoCs including upcoming SoCs _really_ have same address like above? I don't think so. You need to consider its flexibility or some compatibility when definitions are added. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH libdrm] Add configure option --with/--without-valgrind
On 31 July 2012 17:39, Eric Anholt wrote: > Daniel Martin writes: >> 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. > > How would you have the valgrind .pc file but be unable to build with > valgrind? .pc files should come with the parts necessary to build. It was a bug in our build system, which didn't exported the include path correctly. But, regardless of this homebrewn bug. I like to leave decissions up to the user: If it is possible to build without valgrind - make it an option. The same goes for the tests. Where I would like to create a patch too.
[PATCH V2 1/5] include/video: Add samsung FIMD register header
Leela Krishna Amudala wrote: > > 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 > Firstly, please check my comment on your previous patches. And I don't see following definitions are needed and used now. If some definitions are not needed, they can be removed. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
Massive power regression going 3.4->3.5
On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley HansenPartnership.com> wrote: > > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley > > HansenPartnership.com> wrote: > > > > I got the attached to apply and it doesn't really improve the idle power > > > > much (12.5W). > > > > > > That's good to know. Next step is to try overriding i915.semaphores. > > > Can you please test with i915.semaphores=0 and i915.semaphores=1? > > > > There's not much point doing i915_semaphores=1 since that's the default > > on gen 6 hardware, but i915_semaphores=0 recovers and idle power of > > ~6.5W > > It is only the default if iommu is off, and changing the default > was one of the side-effects of the patch you bisected. > > Can you please login to the desktop, let it idle, record > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > Then trace-cmd record -e i915 sleep 10s, and follow up with a new pair > of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > This will let us see whether the pm counters are truly advancing and > what activity the driver is performing whilst idle. OK, so here it is James --- jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo GT_PERF_STATUS: 0x16c7 RPSTAT1: 0x0004160d Render p-state ratio: 22 Render p-state VID: 199 Render p-state limit: 255 CAGF: 1100MHz RP CUR UP EI: 96491us RP CUR UP: 252us RP PREV UP: 0us RP CUR DOWN EI: 0us RP CUR DOWN: 513us 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_drpc_info RC information inaccurate because somebody holds a forcewake reference 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: on Core Power Down: no RC6 "Locked to RPn" residency since boot: 0 RC6 residency since boot: 360123443 RC6+ residency since boot: 0 RC6++ residency since boot: 0 jejb at dabdike> ./git/trace-cmd/trace-cmd record -e i915 sleep 10s trace-cmd: Permission denied opening '/sys/kernel/debug/tracing/tracing_on' jejb at dabdike> sudo ./git/trace-cmd/trace-cmd record -e i915 sleep 10s /sys/kernel/debug/tracing/events/i915/filter /sys/kernel/debug/tracing/events/*/i915/filter Kernel buffer statistics: Note: "entries" are the entries left in the kernel ring buffer and are not recorded in the trace data. They should all be zero. CPU: 0 entries: 0 overrun: 0 commit overrun: 0 bytes: 1080 oldest event ts: 1076.352744 now ts: 1076.651396 CPU: 1 entries: 0 overrun: 0 commit overrun: 0 bytes: 932 oldest event ts: 1067.676405 now ts: 1076.651452 CPU: 2 entries: 0 overrun: 0 commit overrun: 0 bytes: 3784 oldest event ts: 1076.090225 now ts: 1076.651501 CPU: 3 entries: 0 overrun: 0 commit overrun: 0 bytes: 0 oldest event ts: 15281105439.050279 now ts: 1076.651550 CPU0 data recorded at offset=0x39a000 221184 bytes in size CPU1 data recorded at offset=0x3d 16384 bytes in size CPU2 data recorded at offset=0x3d4000 32768 bytes in size CPU3 data recorded at offset=0x3dc000 0 bytes in size jejb at dabdike> cat /sys/kernel/debug/dri/0/i915_cur_delayinfo GT_PERF_STATUS: 0x16c7 RPSTAT1: 0x0004160d Render p-state ratio: 22 Render p-state VID: 199 Render p-state limit: 255 CAGF: 1100MHz RP CUR UP EI: 49171us RP CUR UP: 122us RP PREV UP: 0us RP CUR DOWN EI: 0us RP CUR DOWN: 562us 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_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: 362653127 RC6+ residency since boot: 0 RC6++ residency since boot: 0
[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 #79 from Alexandre Demers 2012-08-01 18:06:40 UTC --- (In reply to comment #78) > (In reply to comment #77) > > (In reply to comment #70) > > > Does this kernel patch help? > > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html > > > > No, it doesn't (well not about the present bug). > > This patch is mostly for the lockup situation, it does not affect the va > issue. > My patch should definitely fix va issue. Alex patch might fix lockup on top of > that. OK, so I should try them together then. I should be able to test it tonight. As of this morning with Alex's patch only, va issue was still reported but I had no time to test it further for lockups. -- 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 Wed, 01 Aug 2012 10:38:36 +0100, James Bottomley wrote: > On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: > > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley > HansenPartnership.com> wrote: > > > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > > > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley > > > HansenPartnership.com> wrote: > > > > > I got the attached to apply and it doesn't really improve the idle > > > > > power > > > > > much (12.5W). > > > > > > > > That's good to know. Next step is to try overriding i915.semaphores. > > > > Can you please test with i915.semaphores=0 and i915.semaphores=1? > > > > > > There's not much point doing i915_semaphores=1 since that's the default > > > on gen 6 hardware, but i915_semaphores=0 recovers and idle power of > > > ~6.5W > > > > It is only the default if iommu is off, and changing the default > > was one of the side-effects of the patch you bisected. > > > > Can you please login to the desktop, let it idle, record > > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > Then trace-cmd record -e i915 sleep 10s, > > OK, what is trace-cmd? It looks similar to perf tools ... is that it? Yes, it is roughly equivalent and you should be able to achieve the same with perf trace - except I haven't done it before so I don't have quick advice on how to drive it. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
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%) Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Tue, Jul 31, 2012 at 05:33:16PM -0400, Alex Deucher wrote: > 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. Looks ok, I lost one fix along the road though, I'm attaching the patch. Luca -- next part -- >From 0f71d5b56b9e5eee3194b5b926767511281ea0a6 Mon Sep 17 00:00:00 2001 From: Luca Tettamanti Date: Wed, 1 Aug 2012 10:53:19 +0200 Subject: [PATCH] drm/radeon: fix, enable notifications with device specific command code Signed-off-by: Luca Tettamanti --- drivers/gpu/drm/radeon/radeon_acpi.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c b/drivers/gpu/drm/radeon/radeon_acpi.c index 14ae8aa..a812b9a 100644 --- a/drivers/gpu/drm/radeon/radeon_acpi.c +++ b/drivers/gpu/drm/radeon/radeon_acpi.c @@ -214,6 +214,7 @@ static int radeon_atif_get_notification_params(acpi_handle handle, err = -EINVAL; goto out; } + n->enabled = true; n->command_code = params.command_code; } -- 1.7.10.4
[PATCH 1/3] Move FIMD register headers to include/video/
Marek Szyprowski wrote:
>
> Hello,
>
Hi all,
[...]
> > 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.
>
Yes, I agree. And how about changing the name of s3c_fb_drvierdata to
xxx_fimd_v8 not xxx_fimd_exynos5? It's time to use independent from SoC name
because we don't have any guarantee of same address on all of EXYNOS5 SoCs.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH 1/3] Move FIMD register headers to include/video/
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. > I don't agree. Do you _really_ think the address will be fixed on other SoCs including upcoming SoCs? I'd prefer to use the version or something for it. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
On Tuesday, July 31, 2012 9:23 PM 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 */ ^ Please insert one space between '/*' and 'EXYNOS5'. As Sylwester Nawrocki mentioned, the following seems to be better. /* EXYNOS5 specific register offset definitions */ Best regards, Jingoo Han > +#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 1/3] Move FIMD register headers to include/video/
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 > + I have some comments on this. [...] > +/* VIDCON0 */ I don't think above comment is needed because everybody knows that from the name of VIDCON0_. > + > +#define VIDCON0 (0x00) > +#define VIDCON0_INTERLACE(1 << 29) > +#define VIDCON0_VIDOUT_MASK (0x3 << 26) > +#define VIDCON0_VIDOUT_SHIFT (26) I think, you can use either of the following. +#define VIDCON0_VIDOUT_SHIFT (26) +#define VIDCON0_VIDOUT_MASK(0x3 << VIDCON0_VIDOUT_SHIFT) Or just without XXX_SHIFT if the XXX_SHIFT is not used somewhere else, +#define VIDCON0_VIDOUT_MASK(0x3 << 26) [...] Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
[PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
On Tuesday, July 31, 2012 9:23 PM Leela Krishna Amudala wrote: > > 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 Please move header include to proper place as bellows, including other machine files such as origen, smdk, and so on. #include #include #include #include Best regards, Jingoo Han > 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/a
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, 2012-08-01 at 11:53 -0500, Rob Clark wrote: > Ok.. this would help. I'll take a look. I do request that > interfaces/panels don't set any mgr/timing related registers. I had > to comment all this stuff out in my prototype. Really we want to set > the timings separately on the crtc (mgr) / encoder (interface) / > connector (panel.. not sure if it is needed, though?). KMS will take > care of propagating the timings through the pipeline. If we only had auto-update displays, and only the video timings were shadow register, it'd work. Unfortunately we have other registers as shadow registers also, like DISPC_CONTROL1, DISPC_CONFIG1 and DISPC_DIVISOR1. But we should think if this could be somehow be changed, so that all the shadow register info would come from one place. I do find it a bit unlikely with a quick thought, though. Well, hmm. Perhaps... Omapdrm (or omapfb etc) doesn't really need to know about the values of those registers, it just needs to control the GO bit. So perhaps if we had some method to inform omapdrm that these things have changed, and omapdrm would then set the GO bit as soon as possible. But there are some tricky stuff, like the divisors... Well, we need to think about this. Tomi signature.asc Description: This is a digitally signed message part ___ 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 Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley HansenPartnership.com> wrote: > > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley > > HansenPartnership.com> wrote: > > > > I got the attached to apply and it doesn't really improve the idle power > > > > much (12.5W). > > > > > > That's good to know. Next step is to try overriding i915.semaphores. > > > Can you please test with i915.semaphores=0 and i915.semaphores=1? > > > > There's not much point doing i915_semaphores=1 since that's the default > > on gen 6 hardware, but i915_semaphores=0 recovers and idle power of > > ~6.5W > > It is only the default if iommu is off, and changing the default > was one of the side-effects of the patch you bisected. > > Can you please login to the desktop, let it idle, record > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > Then trace-cmd record -e i915 sleep 10s, OK, what is trace-cmd? It looks similar to perf tools ... is that it? James > and follow up with a new pair > of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > This will let us see whether the pm counters are truly advancing and > what activity the driver is performing whilst idle. > -Chris >
[Bug 53045] Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 Anatoly Berbeka changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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
On Tue, 31 Jul 2012 23:52:35 +0200, Laurent Pinchart wrote: >> 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 ? As I wrote several times earlier, MMAP uses fixed number of buffers. In some tightly controlled media pipeline with low latency, it might work. But in general, the V4L element in the pipeline does not know how fast the downstream element(s) will consume the buffers. Thus it has to copy from the MMAP buffers into anonymous user memory pending processing. Then any dequeued buffer can be requeued as soon as possible. In theory, it might also be that, even though the latency is known, the number of required buffers exceeds the maximum MMAP buffers count of the V4L device. Either way, user space ends up doing memory copy from MMAP to custom buffers. This problem does not exist with USERBUF - the V4L2 element can simply allocate a new buffer for each dequeued buffer. By the way, this was already discussed a few months ago for the exact same DMABUF patch series... -- R?mi Denis-Courmont Sent from my collocated server
[Bug 53045] Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 --- Comment #2 from Anatoly Berbeka 2012-08-01 17:36:12 UTC --- Thanks, this patch works for me. Now everything is fine. -- 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 V2 4/5] driver: Include the modified FIMD header file
On Tuesday, July 31, 2012 9:23 PM Leela Krishna Amudala wrote: > > 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 Please move header include to proper place as bellows: #include #include #include #include Best regards, Jingoo Han > > /* This driver will export a number of framebuffer interfaces depending > -- > 1.7.0.4
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Wed 1 August 2012 10:01:45 Tomasz Stanislawski wrote:
> Hi Hans,
>
> On 07/31/2012 02:11 PM, Hans Verkuil wrote:
> > 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.
> >
>
> I do not see any good point in using v4l2_plane. What would be the meaning
> of bytesused, length, data_offset in case of DMABUF exporting?
>
> The field reserved0 was introduced to be replaced by __u32 memory if other
> means
> of buffer description would be needed. The reserved fields at the end of
> the structure could be used for auxiliary parameters other then offset and
> flags.
> The flags field is expected to be used by all exporting types therefore the
> layout could be reorganized to:
>
> struct v4l2_exportbuffers {
> __u32 fd;
> __u32 flags;
> __u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
> alignment */
> __u32 mem_offset; /* what do you thing about using 64-bit field? */
> __u32 reserved1[11];
> };
>
> What is your opinion about this idea?
You're missing the point of my argument. How does v4l2_buffer work currently:
you
have a memory field and a union. The memory field determines which field of the
union is to be used. In order to be able to use VIDIOC_EXPBUF you need to be
able to add new memory types in the future. Currently only MMAP makes sense
here,
so all you need is the offset, but in order to be able to support future memory
types you need to make sure that you can extend v4l2_exportbuffers with the
largest possible value that v4l2_buffers can contain in the union, and that's
an unsigned long/pointer. That won't fit in the current proposal since there is
only
a u32.
So I would propose this:
struct v4l2_exportbuffers {
__u32 fd;
__u32 memory;
union {
__u32 mem_offset;
void *reserved; /* ensure that we can handle pointers in the
future */
} m;
__u32 flags;
__u32 reserved1[11];
};
That way an application can just do:
struct v4l2_buffer buf;
struct v4l2_exportbuffers expbuf;
expbuf.memory = buf.memory;
memcpy(&expbuf.m, &buf.m, sizeof(expbuf.m));
and VIDIOC_EXPBUF will return an error if expbuf.memory != V4L2_MEMORY_MMAP.
I was actually wondering whether it might not be an idea to pass a v4l2_buffer
directly to VIDIOC_EXPBUF. In order to support that you would have to add fd
fields to v4l2_buffer and v4l2_plane and those would be filled in by
VIDIOC_EXPBUF.
For the flags field in exportbuffers you would have to add new V4L2_BUF_FLAG_
flags.
That way you don't need to introduce a new struct and all plane
Re: [PATCH] staging: drm/omap: remove reclaim_buffers callback
On Wed, Aug 1, 2012 at 8:20 AM, Chandrabhanu Mahapatra
wrote:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers callback"
> (b0071efe82). As a result the kernel compilation fails with omapdrm support
> and so the callback for reclaim_buffers is being removed from omapdrm.
>
> Signed-off-by: Chandrabhanu Mahapatra
Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.c
> b/drivers/staging/omapdrm/omap_drv.c
> index 342645a..b8e79eb 100644
> --- a/drivers/staging/omapdrm/omap_drv.c
> +++ b/drivers/staging/omapdrm/omap_drv.c
> @@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
> .irq_postinstall = dev_irq_postinstall,
> .irq_uninstall = dev_irq_uninstall,
> .irq_handler = dev_irq_handler,
> - .reclaim_buffers = drm_core_reclaim_buffers,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = omap_debugfs_init,
> .debugfs_cleanup = omap_debugfs_cleanup,
> --
> 1.7.10
>
> --
> 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 Wed, 01 Aug 2012 10:07:23 +0100, James Bottomley wrote: > > Can you please login to the desktop, let it idle, record > > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > Then trace-cmd record -e i915 sleep 10s, and follow up with a new pair > > of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > > > This will let us see whether the pm counters are truly advancing and > > what activity the driver is performing whilst idle. > > With or without i915_semaphore=0? With semaphores enabled so that we can see if they are active during the idle period or if merely having used them at some point is enough to trigger the issue. And to see if the pm counters bear any relation to reality. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Tomasz,
On Wednesday 01 August 2012 10:01:45 Tomasz Stanislawski wrote:
> On 07/31/2012 02:11 PM, Hans Verkuil wrote:
> > On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
> >> 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.
>
> I do not see any good point in using v4l2_plane. What would be the meaning
> of bytesused, length, data_offset in case of DMABUF exporting?
I don't think Hans meant using v4l2_plane directly, but to use the same union
as in v4l2_plane.
> The field reserved0 was introduced to be replaced by __u32 memory if other
> means of buffer description would be needed. The reserved fields at the end
> of the structure could be used for auxiliary parameters other then offset
> and flags. The flags field is expected to be used by all exporting types
> therefore the layout could be reorganized to:
>
> struct v4l2_exportbuffers {
> __u32 fd;
> __u32 flags;
> __u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
alignment
> */ __u32 mem_offset; /* what do you thing about using 64-bit field? */
> __u32 reserved1[11];
> };
>
> What is your opinion about this idea?
>
> >>> 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.
> It would be difficult. Currently there is no safe/portable way to transform
> a userptr into a scatterlist mappable for other devices. The most trouble
> some examples are userspace-mapping of IO memory like framebuffers.
> How reference management is going to work if there are no struct pages
> describing mapped memory?
>
> The VB2 uses a workaround by keeping a copy of vma that is used to call
> open/close callbacks. I am not sure how reliable this solution is.
>
> Who knows, maybe in future someone will introduce a mechanism for creation
> of DMABUF descriptor from a userptr without any help of client APIs.
> In such a case, it will be the part of DMABUF api not V4L2 :).
--
Regards,
Laurent Pinchart
Massive power regression going 3.4->3.5
On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley HansenPartnership.com> wrote: > > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley > > HansenPartnership.com> wrote: > > > > I got the attached to apply and it doesn't really improve the idle power > > > > much (12.5W). > > > > > > That's good to know. Next step is to try overriding i915.semaphores. > > > Can you please test with i915.semaphores=0 and i915.semaphores=1? > > > > There's not much point doing i915_semaphores=1 since that's the default > > on gen 6 hardware, but i915_semaphores=0 recovers and idle power of > > ~6.5W > > It is only the default if iommu is off, and changing the default > was one of the side-effects of the patch you bisected. Sandybridge mobile doesn't have an iommu (or at least, if it does, the kernel doesn't detect it). > Can you please login to the desktop, let it idle, record > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > Then trace-cmd record -e i915 sleep 10s, and follow up with a new pair > of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > This will let us see whether the pm counters are truly advancing and > what activity the driver is performing whilst idle. With or without i915_semaphore=0? James
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 11:53 AM, Rob Clark wrote: > On Wed, Aug 1, 2012 at 11:46 AM, Archit Taneja wrote: >> Hi, >> >> >> On Wednesday 01 August 2012 07:55 PM, Rob Clark wrote: >>> >>> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >>> wrote: On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: > > On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen > wrote: >> 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 No, that's not what omapdss tries to do. I'm not trying to hide the shadow registers and the GO bit behind the omapdss API, I'm just trying to make it work. The omapdss API was made with omapfb, so it's true that the API may not be good for omapdrm. But I'm happy to change the API. > And btw, I think the current mapping of drm_encoder to mgr in omapdrm > is not correct. I'm just in the process of shuffling things around. > I think drm/kms actually maps quite nicely to the underlying hardware > with the following arrangement: > > drm_plane -> ovl > drm_crtc -> mgr > drm_encoder -> DSI/DPI/HDMI/VENC encoder > drm_connector -> pretty much what we call a panel driver today Hmm, what was the arrangement earlier? >>> >>> >>> it was previously: >>> >>>plane -> ovl >>>crtc -> placeholder >>>encoder -> mgr >>>connector -> dssdev (encoder+panel) >>> >>> although crtc is really the point where you should enable/disable >>> vblank irqs, so the new arrangement is somewhat cleaner (although on >>> my branch the encoder/connector part are not finished yet) >>> I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems. >>> >>> >>> Actually, I think it does map fairly well to the hardware.. at least >>> more so than to omapdss ;-) >>> >>> The one area that kms mismatches a bit is decoupling of ovl from mgr >>> that we have in our hw.. I've partially solved that a while back w/ >>> the patch in drm to add "private planes" so the omap_crtc internally >>> uses an omap_plane. It isn't exposed to userspace to be able to >>> re-use the planes from unused crtcs, although I have some ideas about >>> that (but not yet time to work on it). >>> > It would be quite useful if you could look at the omap_drm_apply > mechanism I had in omapdrm, because that seems like a quite > straightforward way to deal w/ shadowed registers. I think it will Yes, it seems straightforward, but it's not =). I had a look at your omapdrm-on-dispc-2 branch. What you are doing there is quite similar to what omapdss was doing earlier. It's not going to work reliably with multiple outputs and fifomerge. Configuring things like overlay color mode are quite simple. They only affect that one overlay. Also things like manager default bg color are simple, they affect only that one manager. But enabling/disabling an overlay or a manager, changing the destination mgr of an overlay, fifomerge... Those are not simple. You can't do them directly, as you do in your branch. As an example, consider the case of enabling an overlay (vid1), and moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll first need to take the fifo buffers from gfx, set GO, and wait for the settings to take effect. Only then you can set the fifo buffers for vid1, enable it and set GO bit. >>> >>> >>> hmm, it does sound like it needs a bit of a state machine to deal with >>> multi-step updates.. although that makes races more of a problem, >>> which was something I was trying hard to avoid. >>> >>> For enabling/disabling an output (manager+encoder), this is relatively >>> infrequent, so it can afford to block to avoid races. (Like userspace >>> enabling and then rapidly disabling an output part way through the >>> enable.) But enabling/disabling an overlay, or adjusting position or >>> scanout address must not block. And ideally, if possible, switching >>> an overlay between two managers should not block. >>> >>> For fifomerge, if I understand correctly, it shouldn't really be >>> needed for functionality, but mainly as a power optimization? If this >>> is the case I wonder about an approach of disabling fifomerge when >>> there are ongoing setting changes, and then setting it after things >>> settle down? I'll have to think about it, but I was trying to avoid >>> needing a multi-step state machine to avoid the associated race >>> conditions, but if this is not possible then it is not possible. >>> I didn't writ
[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On Wed, Aug 1, 2012 at 9:49 AM, Luca Tettamanti wrote: > AMD ACPI interface may overload the standard event > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > userspace because the user did not press the mode switch key (the > spurious keypress confuses the DE which usually changes the > display configuration and messes up a dual-screen setup). > This patch gives the radeon driver the chance to examine the event and > block the keypress if the event is an "AMD event". > > Signed-off-by: Luca Tettamanti Looks good to me, but I'm certainly not an ACPI expert. Acked-by: Alex Deucher
[PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans,
On 07/31/2012 02:11 PM, Hans Verkuil wrote:
> 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.
>
I do not see any good point in using v4l2_plane. What would be the meaning
of bytesused, length, data_offset in case of DMABUF exporting?
The field reserved0 was introduced to be replaced by __u32 memory if other means
of buffer description would be needed. The reserved fields at the end of
the structure could be used for auxiliary parameters other then offset and
flags.
The flags field is expected to be used by all exporting types therefore the
layout could be reorganized to:
struct v4l2_exportbuffers {
__u32 fd;
__u32 flags;
__u32 reserved0[2]; /* place for '__u32 memory' + forcing 64 bit
alignment */
__u32 mem_offset; /* what do you thing about using 64-bit field? */
__u32 reserved1[11];
};
What is your opinion about this idea?
>>> 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.
It would be difficult. Currently there is no safe/portable way to transform
a userptr into a scatterlist mappable for other devices. The most trouble
some examples are userspace-mapping of IO memory like framebuffers.
How reference management is going to work if there are no struct pages
describing mapped memory?
The VB2 uses a workaround by keeping a copy of vma that is used to call
open/close callbacks. I am not sure how reliable this solution is.
Who knows, maybe in future someone will introduce a mechanism for creation of
DMABUF descriptor from a userptr without any help of client APIs.
In such a case, it will be the part of DMABUF api not V4L2 :).
Regards,
Tomasz Stanislawski
>
> 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.
>>
>>
[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 #78 from Jerome Glisse 2012-08-01 16:59:03 UTC --- (In reply to comment #77) > (In reply to comment #70) > > Does this kernel patch help? > > http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html > > No, it doesn't (well not about the present bug). This patch is mostly for the lockup situation, it does not affect the va issue. My patch should definitely fix va issue. Alex patch might fix lockup on top of that. -- 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 V2 0/5] arm: samsung: Move FIMD headers to include/video/
On 08/01/2012 02:28 AM, Kukjin Kim wrote: > Leela Krishna Amudala wrote: >> >> 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. >> > (Cc'ed Florian Tobias Schandinat) > > Yeah, since it's merge window, this series could be created against on > mainline. And IMO, would be helpful to us if this series could be sent to > upstream via samsung tree after reviewing, because this touches too many > files in samsung tree and just adds include/video/samsung_fimd.h. But I'm > not sure the added inclusion will be used in other file of drivers/video. If > so, I can provide some topic branch can be merged into Florian's tree. > Florian, how about? Using a topic branch to merge it in both trees sounds like a good plan to me. Best regards, Florian Tobias Schandinat > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > >> 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%) > >
Massive power regression going 3.4->3.5
On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley wrote: > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley > HansenPartnership.com> wrote: > > > I got the attached to apply and it doesn't really improve the idle power > > > much (12.5W). > > > > That's good to know. Next step is to try overriding i915.semaphores. > > Can you please test with i915.semaphores=0 and i915.semaphores=1? > > There's not much point doing i915_semaphores=1 since that's the default > on gen 6 hardware, but i915_semaphores=0 recovers and idle power of > ~6.5W It is only the default if iommu is off, and changing the default was one of the side-effects of the patch you bisected. Can you please login to the desktop, let it idle, record /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. Then trace-cmd record -e i915 sleep 10s, and follow up with a new pair of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. This will let us see whether the pm counters are truly advancing and what activity the driver is performing whilst idle. -Chris -- Chris Wilson, Intel Open Source Technology Centre
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
Hi, On Wednesday 01 August 2012 07:55 PM, Rob Clark wrote: On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote: On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen wrote: 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 No, that's not what omapdss tries to do. I'm not trying to hide the shadow registers and the GO bit behind the omapdss API, I'm just trying to make it work. The omapdss API was made with omapfb, so it's true that the API may not be good for omapdrm. But I'm happy to change the API. And btw, I think the current mapping of drm_encoder to mgr in omapdrm is not correct. I'm just in the process of shuffling things around. I think drm/kms actually maps quite nicely to the underlying hardware with the following arrangement: drm_plane -> ovl drm_crtc -> mgr drm_encoder -> DSI/DPI/HDMI/VENC encoder drm_connector -> pretty much what we call a panel driver today Hmm, what was the arrangement earlier? it was previously: plane -> ovl crtc -> placeholder encoder -> mgr connector -> dssdev (encoder+panel) although crtc is really the point where you should enable/disable vblank irqs, so the new arrangement is somewhat cleaner (although on my branch the encoder/connector part are not finished yet) I guess the fact is that DRM concepts do not really match the OMAP DSS hardware, and we'll have to use whatever gives us least problems. Actually, I think it does map fairly well to the hardware.. at least more so than to omapdss ;-) The one area that kms mismatches a bit is decoupling of ovl from mgr that we have in our hw.. I've partially solved that a while back w/ the patch in drm to add "private planes" so the omap_crtc internally uses an omap_plane. It isn't exposed to userspace to be able to re-use the planes from unused crtcs, although I have some ideas about that (but not yet time to work on it). It would be quite useful if you could look at the omap_drm_apply mechanism I had in omapdrm, because that seems like a quite straightforward way to deal w/ shadowed registers. I think it will Yes, it seems straightforward, but it's not =). I had a look at your omapdrm-on-dispc-2 branch. What you are doing there is quite similar to what omapdss was doing earlier. It's not going to work reliably with multiple outputs and fifomerge. Configuring things like overlay color mode are quite simple. They only affect that one overlay. Also things like manager default bg color are simple, they affect only that one manager. But enabling/disabling an overlay or a manager, changing the destination mgr of an overlay, fifomerge... Those are not simple. You can't do them directly, as you do in your branch. As an example, consider the case of enabling an overlay (vid1), and moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll first need to take the fifo buffers from gfx, set GO, and wait for the settings to take effect. Only then you can set the fifo buffers for vid1, enable it and set GO bit. hmm, it does sound like it needs a bit of a state machine to deal with multi-step updates.. although that makes races more of a problem, which was something I was trying hard to avoid. For enabling/disabling an output (manager+encoder), this is relatively infrequent, so it can afford to block to avoid races. (Like userspace enabling and then rapidly disabling an output part way through the enable.) But enabling/disabling an overlay, or adjusting position or scanout address must not block. And ideally, if possible, switching an overlay between two managers should not block. For fifomerge, if I understand correctly, it shouldn't really be needed for functionality, but mainly as a power optimization? If this is the case I wonder about an approach of disabling fifomerge when there are ongoing setting changes, and then setting it after things settle down? I'll have to think about it, but I was trying to avoid needing a multi-step state machine to avoid the associated race conditions, but if this is not possible then it is not possible. I didn't write omapdss's apply.c for fun or to make omapfb simpler. I made it because the shadow register system is complex, and we need to handle the tricky cases somewhere. So, as I said before, I believe you'll just end up writing similar code to what is currently in apply.c. It won't be as simple as your current branch. Also, as I mentioned earlier, you'll also need to handle the output side of the shadow registers. These come from the output drivers (DPI, DSI, etc, and indirectly from panel drivers). They are not currently handled in the best manner in omapdss, but Archit is working on that and in his version
[PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Wed, Aug 1, 2012 at 4:57 AM, Luca Tettamanti wrote: > On Tue, Jul 31, 2012 at 05:33:16PM -0400, Alex Deucher wrote: >> 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. > > Looks ok, I lost one fix along the road though, I'm attaching the patch. Thanks, I rolled it into your original patch. New tree: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches Alex > > Luca
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 11:46 AM, Archit Taneja wrote: > Hi, > > > On Wednesday 01 August 2012 07:55 PM, Rob Clark wrote: >> >> On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen >> wrote: >>> >>> On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen wrote: >>> >>> > 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 >>> >>> >>> No, that's not what omapdss tries to do. I'm not trying to hide the >>> shadow registers and the GO bit behind the omapdss API, I'm just trying >>> to make it work. >>> >>> The omapdss API was made with omapfb, so it's true that the API may not >>> be good for omapdrm. But I'm happy to change the API. >>> And btw, I think the current mapping of drm_encoder to mgr in omapdrm is not correct. I'm just in the process of shuffling things around. I think drm/kms actually maps quite nicely to the underlying hardware with the following arrangement: drm_plane -> ovl drm_crtc -> mgr drm_encoder -> DSI/DPI/HDMI/VENC encoder drm_connector -> pretty much what we call a panel driver today >>> >>> >>> Hmm, what was the arrangement earlier? >> >> >> it was previously: >> >>plane -> ovl >>crtc -> placeholder >>encoder -> mgr >>connector -> dssdev (encoder+panel) >> >> although crtc is really the point where you should enable/disable >> vblank irqs, so the new arrangement is somewhat cleaner (although on >> my branch the encoder/connector part are not finished yet) >> >>> I guess the fact is that DRM concepts do not really match the OMAP DSS >>> hardware, and we'll have to use whatever gives us least problems. >> >> >> Actually, I think it does map fairly well to the hardware.. at least >> more so than to omapdss ;-) >> >> The one area that kms mismatches a bit is decoupling of ovl from mgr >> that we have in our hw.. I've partially solved that a while back w/ >> the patch in drm to add "private planes" so the omap_crtc internally >> uses an omap_plane. It isn't exposed to userspace to be able to >> re-use the planes from unused crtcs, although I have some ideas about >> that (but not yet time to work on it). >> It would be quite useful if you could look at the omap_drm_apply mechanism I had in omapdrm, because that seems like a quite straightforward way to deal w/ shadowed registers. I think it will >>> >>> >>> Yes, it seems straightforward, but it's not =). >>> >>> I had a look at your omapdrm-on-dispc-2 branch. What you are doing there >>> is quite similar to what omapdss was doing earlier. It's not going to >>> work reliably with multiple outputs and fifomerge. >>> >>> Configuring things like overlay color mode are quite simple. They only >>> affect that one overlay. Also things like manager default bg color are >>> simple, they affect only that one manager. >>> >>> But enabling/disabling an overlay or a manager, changing the destination >>> mgr of an overlay, fifomerge... Those are not simple. You can't do them >>> directly, as you do in your branch. >>> >>> As an example, consider the case of enabling an overlay (vid1), and >>> moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll >>> first need to take the fifo buffers from gfx, set GO, and wait for the >>> settings to take effect. Only then you can set the fifo buffers for >>> vid1, enable it and set GO bit. >> >> >> hmm, it does sound like it needs a bit of a state machine to deal with >> multi-step updates.. although that makes races more of a problem, >> which was something I was trying hard to avoid. >> >> For enabling/disabling an output (manager+encoder), this is relatively >> infrequent, so it can afford to block to avoid races. (Like userspace >> enabling and then rapidly disabling an output part way through the >> enable.) But enabling/disabling an overlay, or adjusting position or >> scanout address must not block. And ideally, if possible, switching >> an overlay between two managers should not block. >> >> For fifomerge, if I understand correctly, it shouldn't really be >> needed for functionality, but mainly as a power optimization? If this >> is the case I wonder about an approach of disabling fifomerge when >> there are ongoing setting changes, and then setting it after things >> settle down? I'll have to think about it, but I was trying to avoid >> needing a multi-step state machine to avoid the associated race >> conditions, but if this is not possible then it is not possible. >> >>> I didn't write omapdss's apply.c for fun or to make omapfb simpler. I >>> made it because the shadow register system is complex, and we need to >>> handle the tricky cases somewhere
Massive power regression going 3.4->3.5
On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley HansenPartnership.com> wrote: > > I got the attached to apply and it doesn't really improve the idle power > > much (12.5W). > > That's good to know. Next step is to try overriding i915.semaphores. > Can you please test with i915.semaphores=0 and i915.semaphores=1? There's not much point doing i915_semaphores=1 since that's the default on gen 6 hardware, but i915_semaphores=0 recovers and idle power of ~6.5W James
Fwd: Brightness on HP EliteBook 8460p
On Tuesday 31 July 2012 12:17:05 Alex Deucher wrote: > 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 I looked at display again and 0 only turn backlight off (or adjust minimum value). If I look at display correctly (in dark room) I can recognize that display is still on and I can see window manager decorations (but text is not readable). Value 255 when ALS is on has same effect as 0 - adjust minimum value (instead maximum). -- 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/20120801/6f4f11e7/attachment.pgp>
[RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote: > On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: >> On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen >> wrote: > >> > 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 > > No, that's not what omapdss tries to do. I'm not trying to hide the > shadow registers and the GO bit behind the omapdss API, I'm just trying > to make it work. > > The omapdss API was made with omapfb, so it's true that the API may not > be good for omapdrm. But I'm happy to change the API. > >> And btw, I think the current mapping of drm_encoder to mgr in omapdrm >> is not correct. I'm just in the process of shuffling things around. >> I think drm/kms actually maps quite nicely to the underlying hardware >> with the following arrangement: >> >> drm_plane -> ovl >> drm_crtc -> mgr >> drm_encoder -> DSI/DPI/HDMI/VENC encoder >> drm_connector -> pretty much what we call a panel driver today > > Hmm, what was the arrangement earlier? it was previously: plane -> ovl crtc -> placeholder encoder -> mgr connector -> dssdev (encoder+panel) although crtc is really the point where you should enable/disable vblank irqs, so the new arrangement is somewhat cleaner (although on my branch the encoder/connector part are not finished yet) > I guess the fact is that DRM concepts do not really match the OMAP DSS > hardware, and we'll have to use whatever gives us least problems. Actually, I think it does map fairly well to the hardware.. at least more so than to omapdss ;-) The one area that kms mismatches a bit is decoupling of ovl from mgr that we have in our hw.. I've partially solved that a while back w/ the patch in drm to add "private planes" so the omap_crtc internally uses an omap_plane. It isn't exposed to userspace to be able to re-use the planes from unused crtcs, although I have some ideas about that (but not yet time to work on it). >> It would be quite useful if you could look at the omap_drm_apply >> mechanism I had in omapdrm, because that seems like a quite >> straightforward way to deal w/ shadowed registers. I think it will > > Yes, it seems straightforward, but it's not =). > > I had a look at your omapdrm-on-dispc-2 branch. What you are doing there > is quite similar to what omapdss was doing earlier. It's not going to > work reliably with multiple outputs and fifomerge. > > Configuring things like overlay color mode are quite simple. They only > affect that one overlay. Also things like manager default bg color are > simple, they affect only that one manager. > > But enabling/disabling an overlay or a manager, changing the destination > mgr of an overlay, fifomerge... Those are not simple. You can't do them > directly, as you do in your branch. > > As an example, consider the case of enabling an overlay (vid1), and > moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll > first need to take the fifo buffers from gfx, set GO, and wait for the > settings to take effect. Only then you can set the fifo buffers for > vid1, enable it and set GO bit. hmm, it does sound like it needs a bit of a state machine to deal with multi-step updates.. although that makes races more of a problem, which was something I was trying hard to avoid. For enabling/disabling an output (manager+encoder), this is relatively infrequent, so it can afford to block to avoid races. (Like userspace enabling and then rapidly disabling an output part way through the enable.) But enabling/disabling an overlay, or adjusting position or scanout address must not block. And ideally, if possible, switching an overlay between two managers should not block. For fifomerge, if I understand correctly, it shouldn't really be needed for functionality, but mainly as a power optimization? If this is the case I wonder about an approach of disabling fifomerge when there are ongoing setting changes, and then setting it after things settle down? I'll have to think about it, but I was trying to avoid needing a multi-step state machine to avoid the associated race conditions, but if this is not possible then it is not possible. > I didn't write omapdss's apply.c for fun or to make omapfb simpler. I > made it because the shadow register system is complex, and we need to > handle the tricky cases somewhere. > > So, as I said before, I believe you'll just end up writing similar code > to what is currently in apply.c. It won't be as simple as your current > branch. > > Also, as I mentioned earlier, you'll also need to handle the output side > of the shadow registers. These come from the output drivers (DPI, DSI, > etc, and indirectly from panel drivers). They are not currently handled > in the best manner
Massive power regression going 3.4->3.5
On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley wrote: > I got the attached to apply and it doesn't really improve the idle power > much (12.5W). That's good to know. Next step is to try overriding i915.semaphores. Can you please test with i915.semaphores=0 and i915.semaphores=1? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[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 #77 from Alexandre Demers 2012-08-01 16:09:21 UTC --- (In reply to comment #70) > Does this kernel patch help? > http://lists.freedesktop.org/archives/dri-devel/2012-July/025704.html No, it doesn't (well not about the present bug). -- 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, 2012-07-31 at 20:24 +0100, Chris Wilson wrote:
> On Tue, 31 Jul 2012 11:14:17 +0100, Chris Wilson chris-wilson.co.uk> 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;
> }
Your patch doesn't apply ... I think because in v3.5 this line is
displaced by about 200 lines in the file.
patching file drivers/gpu/drm/i915/i915_gem.c
Hunk #1 FAILED at 3067.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/gpu/drm/i915/i915_gem.c.rej
I got the attached to apply and it doesn't really improve the idle power
much (12.5W).
James
---
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 288d7b8..2f3f279 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2869,7 +2869,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
return ret;
if (pipelined != obj->ring) {
- ret = i915_gem_object_sync(obj, pipelined);
+ ret = i915_gem_object_wait_rendering(obj);
if (ret)
return ret;
}
[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 majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm: refcnt drm_framebuffer
On Wed, Aug 1, 2012 at 6:36 AM, Ville Syrj?l? wrote: > On Tue, Jul 31, 2012 at 02:28:29PM -0500, Rob Clark wrote: >> 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 > >> chris-wilson.co.uk> 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() > > Your patch would still significantly change the behavior of > drm_mode_rmfb(). Currently it disables all planes and crtcs which > currently use the fb, and it removes the fb id from the idr so that > no new users of the fb can appear afterwards. > > Not that I really like the current behaviour of drm_mode_rmfb(), but > it's been like that always, so changing it doesn't seem acceptable. yeah, I'm working on an update that decouples the crtc/plane shutdown from deleting the fb, which should address these issues BR, -R > -- > Ville Syrj?l? > Intel OTC > -- > 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
[Bug 53045] Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 --- Comment #1 from Jerome Glisse 2012-08-01 14:32:27 UTC --- Created attachment 65037 --> https://bugs.freedesktop.org/attachment.cgi?id=65037 Disable crtc after mc setup Attached kernel patch should fix your issue. -- 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
Re: [RFC 0/3] solving omapdrm/omapdss layering issues
On Wed, Aug 1, 2012 at 4:21 AM, Tomi Valkeinen wrote: > On Tue, 2012-07-31 at 09:45 -0500, Rob Clark wrote: >> On Tue, Jul 31, 2012 at 8:40 AM, Tomi Valkeinen >> wrote: > >> > 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 > > No, that's not what omapdss tries to do. I'm not trying to hide the > shadow registers and the GO bit behind the omapdss API, I'm just trying > to make it work. > > The omapdss API was made with omapfb, so it's true that the API may not > be good for omapdrm. But I'm happy to change the API. > >> And btw, I think the current mapping of drm_encoder to mgr in omapdrm >> is not correct. I'm just in the process of shuffling things around. >> I think drm/kms actually maps quite nicely to the underlying hardware >> with the following arrangement: >> >> drm_plane -> ovl >> drm_crtc -> mgr >> drm_encoder -> DSI/DPI/HDMI/VENC encoder >> drm_connector -> pretty much what we call a panel driver today > > Hmm, what was the arrangement earlier? it was previously: plane -> ovl crtc -> placeholder encoder -> mgr connector -> dssdev (encoder+panel) although crtc is really the point where you should enable/disable vblank irqs, so the new arrangement is somewhat cleaner (although on my branch the encoder/connector part are not finished yet) > I guess the fact is that DRM concepts do not really match the OMAP DSS > hardware, and we'll have to use whatever gives us least problems. Actually, I think it does map fairly well to the hardware.. at least more so than to omapdss ;-) The one area that kms mismatches a bit is decoupling of ovl from mgr that we have in our hw.. I've partially solved that a while back w/ the patch in drm to add "private planes" so the omap_crtc internally uses an omap_plane. It isn't exposed to userspace to be able to re-use the planes from unused crtcs, although I have some ideas about that (but not yet time to work on it). >> It would be quite useful if you could look at the omap_drm_apply >> mechanism I had in omapdrm, because that seems like a quite >> straightforward way to deal w/ shadowed registers. I think it will > > Yes, it seems straightforward, but it's not =). > > I had a look at your omapdrm-on-dispc-2 branch. What you are doing there > is quite similar to what omapdss was doing earlier. It's not going to > work reliably with multiple outputs and fifomerge. > > Configuring things like overlay color mode are quite simple. They only > affect that one overlay. Also things like manager default bg color are > simple, they affect only that one manager. > > But enabling/disabling an overlay or a manager, changing the destination > mgr of an overlay, fifomerge... Those are not simple. You can't do them > directly, as you do in your branch. > > As an example, consider the case of enabling an overlay (vid1), and > moving fifo buffers from currently enabled overlay (gfx) to vid1: you'll > first need to take the fifo buffers from gfx, set GO, and wait for the > settings to take effect. Only then you can set the fifo buffers for > vid1, enable it and set GO bit. hmm, it does sound like it needs a bit of a state machine to deal with multi-step updates.. although that makes races more of a problem, which was something I was trying hard to avoid. For enabling/disabling an output (manager+encoder), this is relatively infrequent, so it can afford to block to avoid races. (Like userspace enabling and then rapidly disabling an output part way through the enable.) But enabling/disabling an overlay, or adjusting position or scanout address must not block. And ideally, if possible, switching an overlay between two managers should not block. For fifomerge, if I understand correctly, it shouldn't really be needed for functionality, but mainly as a power optimization? If this is the case I wonder about an approach of disabling fifomerge when there are ongoing setting changes, and then setting it after things settle down? I'll have to think about it, but I was trying to avoid needing a multi-step state machine to avoid the associated race conditions, but if this is not possible then it is not possible. > I didn't write omapdss's apply.c for fun or to make omapfb simpler. I > made it because the shadow register system is complex, and we need to > handle the tricky cases somewhere. > > So, as I said before, I believe you'll just end up writing similar code > to what is currently in apply.c. It won't be as simple as your current > branch. > > Also, as I mentioned earlier, you'll also need to handle the output side > of the shadow registers. These come from the output drivers (DPI, DSI, > etc, and indirectly from panel drivers). They are not currently handled > in the best manner
[Bug 53045] New: Incorrect picture with AMD 6970
https://bugs.freedesktop.org/show_bug.cgi?id=53045 Bug #: 53045 Summary: Incorrect picture with AMD 6970 Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ekzo.t...@gmail.com I apologize for my English. I have incorrect picture. After installing Arch Linux or Opensuse 12.1 the picture seems like divided at 3 fragments, but instead [1 2 3] I have [3 1 2] or [2 3 1]. (Look the photo). No matter with which monitor - I tried 2 monitors. Sometimes I receive just black screen (1 of 3 cases, or [3 1 2] or [2 3 1]). I have this problem at TTY and X too. CPU: AMD Phenom II X4 GPU: AMD 6970 Xorg driver: xf86-video-ati 1:6.14.6-1 Photo of TTY console: http://img194.imageshack.us/img194/9861/112233d.jpg Photo of X desktop running XFCE4: http://img694.imageshack.us/img694/6843/111222333q.jpg Kernel version: Linux sirius 3.4.7-1-ARCH #1 SMP PREEMPT Sun Jul 29 22:02:56 CEST 2012 x86_64 GNU/Linux dmesg output: https://gist.github.com/3226626 lspci output: https://gist.github.com/3226632 xrandr output: https://gist.github.com/3226636 Xorg.0.log | grep EDID log: https://gist.github.com/3226645 Full Xorg.0.log: https://gist.github.com/3227022 Please, tell me which information I had to provide to help solve this problem. -- 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
Re: [PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
On Wed, Aug 1, 2012 at 9:49 AM, Luca Tettamanti wrote: > AMD ACPI interface may overload the standard event > ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such > cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the > userspace because the user did not press the mode switch key (the > spurious keypress confuses the DE which usually changes the > display configuration and messes up a dual-screen setup). > This patch gives the radeon driver the chance to examine the event and > block the keypress if the event is an "AMD event". > > Signed-off-by: Luca Tettamanti Looks good to me, but I'm certainly not an ACPI expert. Acked-by: Alex Deucher ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: add new AMD ACPI header and update relevant code
On Wed, Aug 1, 2012 at 4:57 AM, Luca Tettamanti wrote: > On Tue, Jul 31, 2012 at 05:33:16PM -0400, Alex Deucher wrote: >> 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. > > Looks ok, I lost one fix along the road though, I'm attaching the patch. Thanks, I rolled it into your original patch. New tree: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches Alex > > Luca ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC] drm/radeon: ACPI: veto the keypress on ATIF events
AMD ACPI interface may overload the standard event
ACPI_VIDEO_NOTIFY_PROBE (0x81) to signal AMD-specific events. In such
cases we don't want to send the keypress (KEY_SWITCHVIDEOMODE) to the
userspace because the user did not press the mode switch key (the
spurious keypress confuses the DE which usually changes the
display configuration and messes up a dual-screen setup).
This patch gives the radeon driver the chance to examine the event and
block the keypress if the event is an "AMD event".
Signed-off-by: Luca Tettamanti
---
Any comment from ACPI front?
drivers/acpi/video.c | 10 --
drivers/gpu/drm/radeon/radeon_acpi.c |7 ++-
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 1e0a9e1..a8592c4 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1457,7 +1457,12 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
acpi_video_device_enumerate(video);
acpi_video_device_rebind(video);
acpi_bus_generate_proc_event(device, event, 0);
- keycode = KEY_SWITCHVIDEOMODE;
+ /* This event is also overloaded by AMD ACPI interface, don't
+* send the key press if the event has been handled elsewhere
+* (e.g. radeon DRM driver).
+*/
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
break;
case ACPI_VIDEO_NOTIFY_CYCLE: /* Cycle Display output hotkey pressed.
*/
@@ -1479,7 +1484,8 @@ static void acpi_video_bus_notify(struct acpi_device
*device, u32 event)
break;
}
- if (event != ACPI_VIDEO_NOTIFY_SWITCH)
+ if (event != ACPI_VIDEO_NOTIFY_SWITCH &&
+ event != ACPI_VIDEO_NOTIFY_PROBE)
acpi_notifier_call_chain(device, event, 0);
if (keycode) {
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 96de08d..ee0d29e 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -273,7 +273,12 @@ int radeon_atif_handler(struct radeon_device *rdev,
}
/* TODO: check other events */
- return NOTIFY_OK;
+ /* We've handled the event, stop the notifier chain. The ACPI interface
+* overloads ACPI_VIDEO_NOTIFY_PROBE, we don't want to send that to
+* userspace if the event was generated only to signal a SBIOS
+* request.
+*/
+ return NOTIFY_BAD;
}
/* Call all ACPI methods here */
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: drm/omap: remove reclaim_buffers callback
On Wed, Aug 1, 2012 at 4:32 AM, Chandrabhanu Mahapatra
wrote:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers
> callback"
> for which the kernel compilation fails with omapdrm support. So, the callback
> for reclaim_buffers is removed from omapdrm.
>
> Signed-off-by: Chandrabhanu Mahapatra
Signed-off-by: Rob Clark
> ---
> drivers/staging/omapdrm/omap_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.c
> b/drivers/staging/omapdrm/omap_drv.c
> index 342645a..b8e79eb 100644
> --- a/drivers/staging/omapdrm/omap_drv.c
> +++ b/drivers/staging/omapdrm/omap_drv.c
> @@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
> .irq_postinstall = dev_irq_postinstall,
> .irq_uninstall = dev_irq_uninstall,
> .irq_handler = dev_irq_handler,
> - .reclaim_buffers = drm_core_reclaim_buffers,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = omap_debugfs_init,
> .debugfs_cleanup = omap_debugfs_cleanup,
> --
> 1.7.10
>
> --
> 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] staging: drm/omap: remove reclaim_buffers callback
The reclaim_buffers callback has already been removed by Daniel Vetter
with his patch "drm: kill reclaim_buffers callback"
(b0071efe82). As a result the kernel compilation fails with omapdrm support
and so the callback for reclaim_buffers is being removed from omapdrm.
Signed-off-by: Chandrabhanu Mahapatra
---
drivers/staging/omapdrm/omap_drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 342645a..b8e79eb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
.irq_postinstall = dev_irq_postinstall,
.irq_uninstall = dev_irq_uninstall,
.irq_handler = dev_irq_handler,
- .reclaim_buffers = drm_core_reclaim_buffers,
#ifdef CONFIG_DEBUG_FS
.debugfs_init = omap_debugfs_init,
.debugfs_cleanup = omap_debugfs_cleanup,
--
1.7.10
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 51658] r200 (& possibly radeon) DRI fixes for gnome shell on Mesa 8.0.3
https://bugs.freedesktop.org/show_bug.cgi?id=51658 --- Comment #10 from Roland Scheidegger 2012-08-01 13:07:09 UTC --- With 5b88a2a22daae4d09596804d8edc6b8796d05150 attachment 63712, 63716, 63717, 63718 are obsolete. Still unsure what to do with the others. -- 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
Re: [PATCH] drm: refcnt drm_framebuffer
On Wed, Aug 1, 2012 at 6:36 AM, Ville Syrjälä wrote: > On Tue, Jul 31, 2012 at 02:28:29PM -0500, Rob Clark wrote: >> 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() > > Your patch would still significantly change the behavior of > drm_mode_rmfb(). Currently it disables all planes and crtcs which > currently use the fb, and it removes the fb id from the idr so that > no new users of the fb can appear afterwards. > > Not that I really like the current behaviour of drm_mode_rmfb(), but > it's been like that always, so changing it doesn't seem acceptable. yeah, I'm working on an update that decouples the crtc/plane shutdown from deleting the fb, which should address these issues BR, -R > -- > Ville Syrjälä > Intel OTC > -- > 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: [PATCH] staging: drm/omap: remove reclaim_buffers callback
Am Mittwoch, den 01.08.2012, 15:02 +0530 schrieb Chandrabhanu Mahapatra:
> The reclaim_buffers callback has already been removed by Daniel Vetter
> with his patch "drm: kill reclaim_buffers callback"
Please add the first eight characters of the commit hash behind the
summary in parentheses.
> for which the kernel compilation fails with omapdrm support. So, the callback
> for reclaim_buffers is removed from omapdrm.
>
> Signed-off-by: Chandrabhanu Mahapatra
> ---
> drivers/staging/omapdrm/omap_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/staging/omapdrm/omap_drv.c
> b/drivers/staging/omapdrm/omap_drv.c
> index 342645a..b8e79eb 100644
> --- a/drivers/staging/omapdrm/omap_drv.c
> +++ b/drivers/staging/omapdrm/omap_drv.c
> @@ -778,7 +778,6 @@ static struct drm_driver omap_drm_driver = {
> .irq_postinstall = dev_irq_postinstall,
> .irq_uninstall = dev_irq_uninstall,
> .irq_handler = dev_irq_handler,
> - .reclaim_buffers = drm_core_reclaim_buffers,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = omap_debugfs_init,
> .debugfs_cleanup = omap_debugfs_cleanup,
Acked-by: Paul Menzel
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
