[Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
On Tue, Dec 06, 2011 at 11:12:26PM +0100, Benjamin Tissoires wrote: > Hi Baptiste, Hi, > On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez > wrote: > > The second screen works fine with the attached patch. It actually is > > 6 months old but seems to have been lost in the wild... > > You don't have the problem of the second backlight still off? > On our Iconia, we need to trigger a special DMI command to set it up > (SDSS, IIRC). No, with the patch, it worked out-of-the-box. I can even control the brightness in `/sys/class/backlight/acpi_video0/brightness' (it affects both displays at the same time though). But even at 0, it's still perfectly readable. Maybe this a bug that got fixed recently? I've actually tried the 3.1 kernel (and then the 3.2-rc4) because I noticed a lot of commits and improvements in the i915 driver recently. > > Thanks Benjamin! > > All the credits are from Ajax and somebody else on IRC I don't recall, > really sorry. Thanks to them. > > Cheers, > Benjamin. Regards, Baptiste
[Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
Hi Baptiste, On Tue, Dec 6, 2011 at 22:51, Baptiste Jonglez wrote: > On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: >> Add Cc. to platform-driver-x86 and linux-acpi >> >> Hi Baptiste >> >> ? ??2011-12-04 ? 17:07 +0100?Baptiste Jonglez ??? >> > Hi, >> > >> > I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't >> > have a keyboard, but two displays with touchscreens) >> > >> > The Intel GPU is integrated into the Core i5-480M CPU: it's a bit >> > older than Sandybridge, as it seems to be based on the Arrandale >> > micro-architecture. >> > >> > In the BIOS, both displays work fine; but as soon as the kernel boots >> > up, the second display (i.e. the one where you usually find a >> > keyboard) is turned off. The main display works as expected. >> > >> > xrandr reports two LVDS displays: LVDS1, which is connected, and >> > LVDS2, which is marked as "disconnected". No matter what I tried, I >> > can't bring that second display up. >> > >> > During the boot, just after the drm is set up, the following message >> > shows up: >> > >> > [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions >> > >> > (attached is the relevant part of dmesg [1]) > > The second screen works fine with the attached patch. It actually is > 6 months old but seems to have been lost in the wild... You don't have the problem of the second backlight still off? On our Iconia, we need to trigger a special DMI command to set it up (SDSS, IIRC). > > Thanks Benjamin! All the credits are from Ajax and somebody else on IRC I don't recall, really sorry. Thanks to them. Cheers, Benjamin. > > There is still the issue of unhandled acer-wmi events, but it's far > less incapacitating. I wonder what's the best way to report events to > userspace, though (e.g. for the "keyboard" button, userspace might > want to know when it is pressed in order to display a virtual keyboard > or any other fancy stuff) > > Joey, if you need more logs for acer-wmi, I'll be happy to provide. > > > Baptiste
Noise in games on Intel HD Graphics 2000
Hi, I'm running on Intel i3 2100 integrated graphics, I'm getting some strange noise particles in games like Minecraft and Speed Dreams (mostly noticeable in Minecraft) after playing a while, like half an hour. After that restarting game doesn't help, only computer restart have the effect of returning graphics to normal. Some screenshots bellow: Normal graphics: http://i1129.photobucket.com/albums/m506/semiRocket/2011-12-06_215907.png After a while: http://i1129.photobucket.com/albums/m506/semiRocket/2011-12-06_223010.png http://i1129.photobucket.com/albums/m506/semiRocket/2011-12-06_224500.png I'm running Fedora 16. On Fedora 15 I have experienced the same issue. Best regards
[Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off [3.2-rc4+]
On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote:
> Add Cc. to platform-driver-x86 and linux-acpi
>
> Hi Baptiste
>
> ? ??2011-12-04 ? 17:07 +0100?Baptiste Jonglez ???
> > Hi,
> >
> > I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't
> > have a keyboard, but two displays with touchscreens)
> >
> > The Intel GPU is integrated into the Core i5-480M CPU: it's a bit
> > older than Sandybridge, as it seems to be based on the Arrandale
> > micro-architecture.
> >
> > In the BIOS, both displays work fine; but as soon as the kernel boots
> > up, the second display (i.e. the one where you usually find a
> > keyboard) is turned off. The main display works as expected.
> >
> > xrandr reports two LVDS displays: LVDS1, which is connected, and
> > LVDS2, which is marked as "disconnected". No matter what I tried, I
> > can't bring that second display up.
> >
> > During the boot, just after the drm is set up, the following message
> > shows up:
> >
> > [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions
> >
> > (attached is the relevant part of dmesg [1])
The second screen works fine with the attached patch. It actually is
6 months old but seems to have been lost in the wild...
Thanks Benjamin!
There is still the issue of unhandled acer-wmi events, but it's far
less incapacitating. I wonder what's the best way to report events to
userspace, though (e.g. for the "keyboard" button, userspace might
want to know when it is pressed in order to display a virtual keyboard
or any other fancy stuff)
Joey, if you need more logs for acer-wmi, I'll be happy to provide.
Baptiste
-- next part --
Original patch by Chris Wilson [1], here slightly adapted for the latest tree.
[1] https://bugs.freedesktop.org/attachment.cgi?id=49069
We were checking whether the supplied edid matched the connector it was
read from. We do this in case a DDC read returns an EDID for another
device on a multifunction or otherwise interesting card. However, we
failed to include LVDS as a digital device and so rejecting an otherwise
valid EDID.
Fixes the detection of the secondary SDVO LVDS panel on the Libretto
W105.
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 3003fb2..ac322fb 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -50,6 +50,7 @@
#define IS_TMDS(c) (c->output_flag & SDVO_TMDS_MASK)
#define IS_LVDS(c) (c->output_flag & SDVO_LVDS_MASK)
#define IS_TV_OR_LVDS(c) (c->output_flag & (SDVO_TV_MASK | SDVO_LVDS_MASK))
+#define IS_DIGITAL(c) (c->output_flag & (SDVO_TMDS_MASK | SDVO_LVDS_MASK))
static const char *tv_format_names[] = {
@@ -1314,6 +1315,18 @@ intel_sdvo_tmds_sink_detect(struct drm_connector
*connector)
return status;
}
+static bool
+intel_sdvo_connector_matches_edid(struct intel_sdvo_connector *sdvo,
+ struct edid *edid)
+{
+ bool monitor_is_digital = !!(edid->input & DRM_EDID_INPUT_DIGITAL);
+ bool connector_is_digital = !!IS_DIGITAL(sdvo);
+
+ DRM_DEBUG_KMS("connector_is_digital? %d, monitor_is_digital? %d\n",
+ connector_is_digital, monitor_is_digital);
+ return connector_is_digital == monitor_is_digital;
+}
+
static enum drm_connector_status
intel_sdvo_detect(struct drm_connector *connector, bool force)
{
@@ -1358,10 +1371,11 @@ intel_sdvo_detect(struct drm_connector *connector, bool
force)
if (edid == NULL)
edid = intel_sdvo_get_analog_edid(connector);
if (edid != NULL) {
- if (edid->input & DRM_EDID_INPUT_DIGITAL)
- ret = connector_status_disconnected;
- else
+ if
(intel_sdvo_connector_matches_edid(intel_sdvo_connector,
+ edid))
ret = connector_status_connected;
+ else
+ ret = connector_status_disconnected;
connector->display_info.raw_edid = NULL;
kfree(edid);
} else
@@ -1402,11 +1416,8 @@ static void intel_sdvo_get_ddc_modes(struct
drm_connector *connector)
edid = intel_sdvo_get_analog_edid(connector);
if (edid != NULL) {
- struct intel_sdvo_connector *intel_sdvo_connector =
to_intel_sdvo_connector(connector);
- bool monitor_is_digital = !!(edid->input &
DRM_EDID_INPUT_DIGITAL);
- bool connector_is_digital = !!IS_TMDS(intel_sdvo_connector);
-
- if (connector_is_digital == monitor_is_digital) {
+ if
(intel_sdvo_connector_matches_edid(to_intel_sdvo_connector(connector),
+ edid)) {
drm_mode_connector_update_edid_property(connector,
[PATCH 2/2] drm/omap: add GEM support for tiled/dmm buffers
On Tue, Dec 6, 2011 at 5:30 AM, Alan Cox wrote:
> On Mon, ?5 Dec 2011 19:19:22 -0600
> Rob Clark wrote:
>
>> + ? ? usergart = kzalloc(3 * sizeof(*usergart), GFP_KERNEL);
>> +
>> + ? ? /* reserve 4k aligned/wide regions for userspace mappings: */
>> + ? ? for (i = 0; i < ARRAY_SIZE(fmts); i++) {
>> + ? ? ? ? ? ? uint16_t h = 1, w = PAGE_SIZE >> i;
>> + ? ? ? ? ? ? tiler_align(fmts[i], , );
>> + ? ? ? ? ? ? /* note: since each region is 1 4kb page wide, and minimum
>> + ? ? ? ? ? ? ?* number of rows, the height ends up being the same as the
>> + ? ? ? ? ? ? ?* # of pages in the region
>> + ? ? ? ? ? ? ?*/
>> + ? ? ? ? ? ? usergart[i].height = h;
>> + ? ? ? ? ? ? usergart[i].height_shift = ilog2(h);
>
> Seems to be missing anallocation failure check
>
oh, woops.. I've fixed that.. will give a couple more days to see if
there are any other comments and then send v2..
BR,
-R
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #11 from Tomas Schlosser 2011-12-06 10:59:29 PST --- Oh, sorry, I posted the copied the bugreport I created for wine. I tried again with correct version of proprietary drivers installed and the problem was gone. I also tried compiling the mesa drivers by tutorial on www.mesa3d.org and the game didn't even start then (gave me Access violation). I still have a few ideas how to run it on mesa from git, but it requires more try-fail attempts. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43426] gallium3d makes krita crash
https://bugs.freedesktop.org/show_bug.cgi?id=43426 --- Comment #2 from Michel D?nzer 2011-12-06 10:26:29 PST --- Does running krita with the environment variable DRAW_USE_LLVM=0 work around the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #8 from Michel D?nzer 2011-12-06 09:19:44 PST --- (In reply to comment #7) > Now the performance thing seems solved. Great, resolving. > Should I rename this report or start a new one for the laggyness due to the > high variance of fps? The latter, if anything. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43018] (NI Turks Pro) : UT2004-demo crashes after few minutes of launch
https://bugs.freedesktop.org/show_bug.cgi?id=43018 --- Comment #5 from Michel D?nzer 2011-12-06 09:16:12 PST --- (In reply to comment #4) > Created attachment 53642 [details] > backtrace Thanks, but I can't see an actual backtrace of the crash. Ideal would be if you could run ut2004-demo in gdb (or attach gdb to the running process) and get a backtrace that way. Alternatively, there might be a backtrace in the ut2004-demo log file. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[git pull] drm fixes
> > What the heck is up? Well I do care about kexec but only due to being forced into caring about it for a certain enterprise distro that uses it a lot, so maybe I was a bit biased in this case, and I dislike random memory corruptions due to my subsystem even in the kexec case. Writing a random 0 dword somewhere in memory isn't that pretty and no fun to track down, when the kexec looks like it succeeds. But I've no problem leaving it sitting around until -next. The kzalloc->kcalloc ones are partly better integer overflow defence where userspace passes in a number of objects but I just need to make sure they are that and not cleanups, but I haven't gotten around to it yet. Cool I'll resend just the Intel and obvious radeon one and stick the others into -next. Dave.
[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 06, 2011 at 01:16:58PM +, Arnd Bergmann wrote: > On Monday 05 December 2011, Rob Clark wrote: > > > On the topic of a coherency model for dmabuf, I think we need to look at > > > dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and > > > cpu_finish or whatever they might get called) as barriers: > > > > > > So after a dma_buf_map, all previsously completed dma operations (i.e. > > > unmap already called) and any cpu writes (i.e. cpu_finish called) will be > > > coherent. Similar rule holds for cpu access through the userspace mmap, > > > only writes completed before the cpu_start will show up. > > > > > > Similar, writes done by the device are only guaranteed to show up after > > > the _unmap. Dito for cpu writes and cpu_finish. > > > > > > In short we always need two function calls to denote the start/end of the > > > "critical section". > > > > Yup, this was exactly my assumption. But I guess it is better to spell it > > out. > > I still don't understand how this is going to help you if you let > multiple drivers enter and leave the critical section without serializing > against one another. That doesn't sound like what I know as critical > section. I already regret to having added that last "critical section" remark. Think barriers. It's just that you need a barrier in both directions that bracket the actual usage. In i915-land we call the first one generally invalidate (so that caches on the target domain don't contain stale data) and that second one flush (to get any data out of caches). > Given some reasonable constraints (all devices must be in the same coherency > domain, for instance), you can probably define it in a way that you can > have multiple devices mapping the same buffer at the same time, and > when no device has mapped the buffer you can have as many concurrent > kernel and user space accesses on the same buffer as you like. But you > must still guarantee that no software touches a noncoherent buffer while > it is mapped into any device and vice versa. > > Why can't we just mandate that all mappings into the kernel must be > coherent and that user space accesses must either be coherent as well > or be done by user space that uses explicit serialization with all > DMA accesses? I agree with your points here, afaics the contentious issue is just whether dma_buf should _enforce_ this strict ordering. I'm leading towards a "no" for the following reasons: - gpu people love nonblocking interfaces (and love to come up with abuses). In the generic case we'd need some more functions to properly flush everything while 2 devices access a buffer concurrently (which is imo a bit unrealistic). But e.g. 2 gpus rendering in SLI mode very much want to access the same buffer at the same time (and the kernel+userspace gpu driver already needs all the information about caches to make that happen, at least on x86). - Buffer sharing alone has already some great potential for deadlock and lock recursion issues. Making dma_buf into something that very much acts like a new locking primitive itself (even exposed to userspace) will make this much worse. I've seen some of the kernel/userspace shared hwlock code of dri1 yonder, and it's horrible (and at least for the case of the dri1 hwlock, totally broken). - All current subsystem already have the concept to pass the ownership of a buffer between the device and userspace (sometimes even more than just 2 domains, like in i915 ...). Userspace already needs to use this interface to get anything resembling correct data. I don't see any case where userspace can't enforce passing around buffer ownership if multiple devices are involved (we obviously need to clarify subsystem interfaces to make it clear when a buffer is in use and when another device taking part in the sharing could use it). So I don't see how the kernel enforcing strict access ordering helps implementing correct userspace. - I don't see any security needs that would make it necessary for the kernel to enforce any consistency guarantees for concurrent access - we're only dealing with pixel data in all the currently discussed generic use-cases. So I think garbage as an end-result is acceptable if userspace does stupid things (or fails at trying to be clever). Cheers, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[git pull] drm fixes
Hi Linus, 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been testing, and one kexec fix from Jerome for an issue reported on the list where the gpu writeback engines need to be switched off, along with a trivial fix from Alex. Due to the size of the kexec fix I've decided to keep this pull small. (I have some kzalloc->kcalloc fixes to check on). Dave. The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4: Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id Daniel Vetter (1): drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a Jerome Glisse (1): drm/radeon: disable possible GPU writeback early v3 drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/radeon/evergreen.c |2 ++ drivers/gpu/drm/radeon/ni.c | 18 ++ drivers/gpu/drm/radeon/nid.h | 19 +++ drivers/gpu/drm/radeon/r100.c| 20 ++-- drivers/gpu/drm/radeon/r520.c|2 +- drivers/gpu/drm/radeon/r600.c| 16 drivers/gpu/drm/radeon/radeon_asic.h |2 ++ drivers/gpu/drm/radeon/radeon_encoders.c |7 +++ drivers/gpu/drm/radeon/rs600.c | 20 +++- drivers/gpu/drm/radeon/rs600d.h | 21 + drivers/gpu/drm/radeon/rs690.c |2 +- drivers/gpu/drm/radeon/rv515.c |2 +- drivers/gpu/drm/radeon/rv770.c | 16 drivers/gpu/drm/radeon/rv770d.h | 20 15 files changed, 151 insertions(+), 23 deletions(-)
[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe
https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #6 from Dave Airlie 2011-12-06 08:12:01 PST --- check mesa is built with radeon drm support. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe
https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #5 from Michel D?nzer 2011-12-06 07:46:32 PST --- Looks like /usr/lib64/dri/r600_dri.so's dri2CreateNewScreen() hook fails, but it's not clear why. Maybe you can try running glxinfo in gdb, setting a breakpoint at dri2CreateNewScreen and tracing where the failure is coming from. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] libdrm: update drm headers from kernel, including new overlay ioctls & structs
On Tue, 6 Dec 2011 15:23:57 -0800 Jesse Barnes wrote: > Add structs and functions necessary for the new plane and fb handling code, > including a new header, drm_fourcc.h, that includes the surface formats > supported by various DRM drivers. > > Signed-off-by: Jesse Barnes > --- Arg some misc other stuff got pulled in... I'll repost with just the plane stuff. -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111206/bc1ec57b/attachment.pgp>
[PATCH 1/2] libdrm: update drm headers from kernel, including new overlay ioctls & structs
Add structs and functions necessary for the new plane and fb handling code,
including a new header, drm_fourcc.h, that includes the surface formats
supported by various DRM drivers.
Signed-off-by: Jesse Barnes
---
include/drm/Makefile.am |1 +
include/drm/drm.h| 13 -
include/drm/drm_fourcc.h | 130 +++
include/drm/drm_mode.h | 100 --
xf86drmMode.c| 153 ++
xf86drmMode.h| 33 ++
6 files changed, 411 insertions(+), 19 deletions(-)
create mode 100644 include/drm/drm_fourcc.h
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 43695bd..2923ab4 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -26,6 +26,7 @@ klibdrmincludedir = ${includedir}/libdrm
klibdrminclude_HEADERS = \
drm.h \
drm_mode.h \
+ drm_fourcc.h \
drm_sarea.h \
i915_drm.h \
mga_drm.h \
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5fd24fc..bb2dea8 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -467,12 +467,15 @@ struct drm_irq_busid {
enum drm_vblank_seq_type {
_DRM_VBLANK_ABSOLUTE = 0x0, /**< Wait for specific vblank sequence
number */
_DRM_VBLANK_RELATIVE = 0x1, /**< Wait for given number of vblanks */
+ /* bits 1-6 are reserved for high crtcs */
+ _DRM_VBLANK_HIGH_CRTC_MASK = 0x003e,
_DRM_VBLANK_EVENT = 0x400, /**< Send event instead of blocking */
_DRM_VBLANK_FLIP = 0x800, /**< Scheduled buffer swap should flip
*/
_DRM_VBLANK_NEXTONMISS = 0x1000,/**< If missed, wait for next
vblank */
_DRM_VBLANK_SECONDARY = 0x2000, /**< Secondary display
controller */
_DRM_VBLANK_SIGNAL = 0x4000 /**< Send signal instead of blocking,
unsupported */
};
+#define _DRM_VBLANK_HIGH_CRTC_SHIFT 1
#define _DRM_VBLANK_TYPES_MASK (_DRM_VBLANK_ABSOLUTE | _DRM_VBLANK_RELATIVE)
#define _DRM_VBLANK_FLAGS_MASK (_DRM_VBLANK_EVENT | _DRM_VBLANK_SIGNAL | \
@@ -674,6 +677,8 @@ struct drm_get_cap {
#define DRM_IOCTL_UNLOCK DRM_IOW( 0x2b, struct drm_lock)
#define DRM_IOCTL_FINISH DRM_IOW( 0x2c, struct drm_lock)
+#define DRM_IOCTL_GEM_PRIME_OPENDRM_IOWR(0x2e, struct drm_gem_open)
+
#define DRM_IOCTL_AGP_ACQUIRE DRM_IO( 0x30)
#define DRM_IOCTL_AGP_RELEASE DRM_IO( 0x31)
#define DRM_IOCTL_AGP_ENABLE DRM_IOW( 0x32, struct drm_agp_mode)
@@ -713,6 +718,10 @@ struct drm_get_cap {
#define DRM_IOCTL_MODE_CREATE_DUMB DRM_IOWR(0xB2, struct drm_mode_create_dumb)
#define DRM_IOCTL_MODE_MAP_DUMBDRM_IOWR(0xB3, struct drm_mode_map_dumb)
#define DRM_IOCTL_MODE_DESTROY_DUMBDRM_IOWR(0xB4, struct
drm_mode_destroy_dumb)
+#define DRM_IOCTL_MODE_GETPLANERESOURCES DRM_IOWR(0xB5, struct
drm_mode_get_plane_res)
+#define DRM_IOCTL_MODE_GETPLANEDRM_IOWR(0xB6, struct
drm_mode_get_plane)
+#define DRM_IOCTL_MODE_SETPLANEDRM_IOWR(0xB7, struct
drm_mode_set_plane)
+#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
/**
* Device specific ioctls should only be in their respective headers
@@ -755,9 +764,10 @@ struct drm_event_vblank {
};
#define DRM_CAP_DUMB_BUFFER 0x1
-#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
/* typedef area */
+#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
typedef struct drm_drawable_info drm_drawable_info_t;
typedef struct drm_tex_region drm_tex_region_t;
@@ -799,5 +809,6 @@ typedef struct drm_agp_binding drm_agp_binding_t;
typedef struct drm_agp_info drm_agp_info_t;
typedef struct drm_scatter_gather drm_scatter_gather_t;
typedef struct drm_set_version drm_set_version_t;
+#endif
#endif
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
new file mode 100644
index 000..b1107cb
--- /dev/null
+++ b/include/drm/drm_fourcc.h
@@ -0,0 +1,130 @@
+/*
+ * Copyright 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR
[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) -> llvm pipe
https://bugs.freedesktop.org/show_bug.cgi?id=43448 Michel D?nzer changed: What|Removed |Added Attachment #54049|1 |0 is patch|| Attachment #54049|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 42067] [r600g] Compiz overlay icons corrupted on cayman (buggy s3tc support)
https://bugs.freedesktop.org/show_bug.cgi?id=42067 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Alex Deucher 2011-12-06 05:56:36 PST --- *** This bug has been marked as a duplicate of bug 38173 *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38173] DXT3 and DXT5 broken on Cayman gpu
https://bugs.freedesktop.org/show_bug.cgi?id=38173 Alex Deucher changed: What|Removed |Added CC||h.judt at gmx.at --- Comment #1 from Alex Deucher 2011-12-06 05:56:36 PST --- *** Bug 42067 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[BUG] i915/intel-acpi.c: failed to get supported _DSM functions (was: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off)
On Mon, Dec 05, 2011 at 09:56:47PM +0100, Baptiste Jonglez wrote: > CC-ing intel-gfx at lists.freedesktop.org (see below) > On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: > > > [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions > > > > > > (attached is the relevant part of dmesg [1]) > > > > > > > > > > Have no idea for this _DSM error, need help from drm and acpi experts. > > It definitely looks like an ACPI issue. > That function is defined in `drivers/gpu/drm/i915/intel_acpi.c'. > The whole file was added more than a year ago by commit 723bfd707a97 > (see the relevant thread on intel-gfx@ [1]) to "add _DSM support". > One of the first comment is about "Calpella", which is exactly the > platform of my laptop (as shown by lshw) Ignore that - it's entirely harmless. -- Matthew Garrett | mjg59 at srcf.ucam.org
[RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Monday 05 December 2011, Rob Clark wrote: > > On the topic of a coherency model for dmabuf, I think we need to look at > > dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and > > cpu_finish or whatever they might get called) as barriers: > > > > So after a dma_buf_map, all previsously completed dma operations (i.e. > > unmap already called) and any cpu writes (i.e. cpu_finish called) will be > > coherent. Similar rule holds for cpu access through the userspace mmap, > > only writes completed before the cpu_start will show up. > > > > Similar, writes done by the device are only guaranteed to show up after > > the _unmap. Dito for cpu writes and cpu_finish. > > > > In short we always need two function calls to denote the start/end of the > > "critical section". > > Yup, this was exactly my assumption. But I guess it is better to spell it > out. I still don't understand how this is going to help you if you let multiple drivers enter and leave the critical section without serializing against one another. That doesn't sound like what I know as critical section. Given some reasonable constraints (all devices must be in the same coherency domain, for instance), you can probably define it in a way that you can have multiple devices mapping the same buffer at the same time, and when no device has mapped the buffer you can have as many concurrent kernel and user space accesses on the same buffer as you like. But you must still guarantee that no software touches a noncoherent buffer while it is mapped into any device and vice versa. Why can't we just mandate that all mappings into the kernel must be coherent and that user space accesses must either be coherent as well or be done by user space that uses explicit serialization with all DMA accesses? Arnd
[radeon] EDID checksum is invalid
On 12/5/11 3:39 PM, Alexander Beregalov wrote: > At boot time: > [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 206 > Raw EDID: > 27 0f 01 03 80 26 1e 78 2a de 95 a3 54 4c 99 26 > 0f 50 54 bf ef 80 81 80 81 40 71 4f 01 01 01 01 > 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 > 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4b 1e > 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 > 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff > 00 48 53 47 59 39 30 37 30 33 32 0a 20 20 00 59 > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff This looks like an EDID fetch of bytes 16 through 143, instead of 0 through 127 (ie, skip the first 16, last 16 filled with -1). > Few days after that: > [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 38 > Raw EDID: > 30 2a 00 98 51 00 2a 40 30 70 13 00 78 2d 11 00 > 00 1e 00 00 00 fd 00 38 4b 1e 51 0e 00 0a 20 20 > 20 20 20 20 00 00 00 fc 00 53 79 6e 63 4d 61 73 > 74 65 72 0a 20 20 00 00 00 ff 00 48 53 47 59 39 > 30 37 30 33 32 0a 20 20 00 59 ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Offset of 54 bytes here, which is weirder. Possibly the i2c code isn't resetting the index to 0 when it needs to. - ajax
[Bug 42067] [r600g] Compiz overlay icons corrupted on cayman (buggy s3tc support)
https://bugs.freedesktop.org/show_bug.cgi?id=42067 Harald Judt changed: What|Removed |Added Summary|[r600g] Compiz emblem icons |[r600g] Compiz overlay |corrupted on cayman |icons corrupted on cayman ||(buggy s3tc support) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
drm: Branch 'master' - 2 commits
On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt wrote: > On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ickle at kemper.freedesktop.org > (Chris Wilson) wrote: > > configure.ac |2 +- > > intel/intel_bufmgr_gem.c | 27 +-- > > 2 files changed, 22 insertions(+), 7 deletions(-) > > > > New commits: > > commit e73161a02b604742e3da3bca8f13cff81276de43 > > Author: Chris Wilson > > Date: Mon Dec 5 10:30:52 2011 + > > > > configure: Bump version to 2.4.28 > > > > So that we can pull a couple of Intel bug fixes into xf86-video-intel. > > > > Signed-off-by: Chris Wilson > > Performance before: > [ 0] glfirefox-talos-gfx 17.866 17.915 0.14%4/4 > after: > [ 0] glfirefox-talos-gfx 22.173 22.251 0.20%4/4 > > There's a pretty obvious opportunity to keep the performance win of the > userspace caching that you've broken here, but you gave none of us a > chance to review it before you pushed the patch *and shipped a release > with it*. This is not acceptable. Please revert and bump the release, > and fix it correctly. No, what was unacceptable was a vma leak impacting a critical system application, and for the library API to be broken by design. The onus is to improve performance without regressing system stability, not the other way around. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 42067] [r600g] Compiz emblem icons corrupted on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=42067 --- Comment #5 from Harald Judt 2011-12-06 04:43:47 PST --- This problem is still there in linux-3.2-rc4, and clearly related to using s3tc libtxc_dxtn, as it does not happen when the library is not available. Fixing this would also make it possible to play games on cayman gpus that require s3tc. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter Reviewed-by: Chris Wilson # we built better bikesheds, but this keeps the rain off for now --- drivers/gpu/drm/i915/i915_gem.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 036bc58..d7d5801 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2026,8 +2026,13 @@ i915_wait_request(struct intel_ring_buffer *ring, * to handle this, the waiter on a request often wants an associated * buffer to have made it to the inactive list, and we would need * a separate wait queue to handle that. +* +* To avoid a recursion with the ilk VT-d workaround (that calls +* gpu_idle when unbinding objects with interruptible==false) don't +* retire requests in that case (because it might call unbind if the +* active list holds the last reference to the object). */ - if (ret == 0) + if (ret == 0 && dev_priv->mm.interruptible) i915_gem_retire_requests_ring(ring); return ret; -- 1.7.6.4
[PATCH 2/2] drm/omap: add GEM support for tiled/dmm buffers
On Mon, 5 Dec 2011 19:19:22 -0600
Rob Clark wrote:
> + usergart = kzalloc(3 * sizeof(*usergart), GFP_KERNEL);
> +
> + /* reserve 4k aligned/wide regions for userspace mappings: */
> + for (i = 0; i < ARRAY_SIZE(fmts); i++) {
> + uint16_t h = 1, w = PAGE_SIZE >> i;
> + tiler_align(fmts[i], , );
> + /* note: since each region is 1 4kb page wide, and minimum
> + * number of rows, the height ends up being the same as the
> + * # of pages in the region
> + */
> + usergart[i].height = h;
> + usergart[i].height_shift = ilog2(h);
Seems to be missing anallocation failure check
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #10 from Michel D?nzer 2011-12-06 10:24:38 UTC --- (In reply to comment #10) > I also tried kmod-catalyst (proprietary drivers) and running it with wine64 > none of which helped. If the problem is the same with the proprietary drivers, then it's more likely a Gothic / Wine / configuration issue, as it's very unlikely that both drivers would have exactly the same problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Make ib allocation size function of cs size
On Mon, Dec 5, 2011 at 6:39 PM, wrote: > Two following patch are on top of > http://cgit.freedesktop.org/~glisse/linux > > They make the ib allocation size a function of the cs size, this > allow to avoid wasting pool space and avoid to trigger fence_wait > in ib_get. I am still evaluating how much fence_wait we avoid > with this. Both patches are lightly tested and Reviewed-by: Alex Deucher > > Cheers, > Jerome > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: > The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts. > > Every time we go through this we need a > - active object that can be retired > - and there are no other references to that object than the one from > the active list, so that it gets unbound and freed immediately. > Otherwise the recursion stops. So the recursion is only limited by the > number of objects that fit these requirements sitting in the active list > any time retire_request is called. > > Issue exercised by tests/gem_unref_active_buffers from i-g-t. > > There's been a decent bikeshed discussion whether it wouldn't be > better to pass around a flag, but imo this is o.k. for such a limited > case that only supports a w/a. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Chris Wilson # we built better > bikesheds, but this keeps the rain off for now > --- What about: http://lists.freedesktop.org/archives/intel-gfx/2011-October/012984.html Did someone prove that doesn't work?
No subject
Windows. There are only two physical keys: - power-on button - "keyboard"-labeled button, which seems to do nothing hardware-related; it triggers an event caught up by acer_wmi. I think all it does is telling the OS: "hey, pull up the software virtual keyboard on the second display". > > - there are a some unhandled WMI events logged from the acer-wmi > >module [3] when closing the lid, opening it, and most importantly, > >when the (main) screen is turned on or off by DPMS. > > > > I will look at your dsdt and log from acer-wmi then try to improve > acer-wmi. Thanks a lot! > > What do you think? I haven't really succeeded in nailing the source of > > the issue down, but here are a few possibilities I'm thinking of: > > > > - the driver is not aware it can drive two LVDS displays (not very > >likely, and it has worked once, see above) > > > > - there is some kind of switch that is able to turn the second screen > >on or off (I'm thinking of something like rfkill). If so, it looks > >like something non-standard and undocumented. This would explain > >the WMI events (see the last note above) > > > > What's the behavior of Windows? I meant an internal switch that would be controlled by GPIO or such. It doesn't seem very likely though... > > - buggy ACPI implementation. I tried to extract then recompile the > >DSDT [4], and iasl spews out 17 errors and 12 warnings. Also worth > >noticing is that line in dmesg: > > "pci:00: ACPI _OSC request failed (AE_ERROR), returned control mask: > > 0x1d" > > > > > > The Archlinux userland is: > > - libdrm 2.4.27 > > - xorg-server 1.11.2 > > - intel-dri 7.11.1 > > - xf86-video-intel 2.17.0 > > > > > > Please let me know if there are any other details I should provide. > > Regards, > > Baptiste > > > > Attachments: > > [1] dmesg-DSM-functions.log - drm errors when booting normally > > [2] dmesg-video-lvds2.log - drm errors when forcing LVDS2 on the cmdline > > [3] acer_wmi.log - WMI events that land in dmesg > > [4] dsdt - /sys/firmware/acpi/tables/DSDT > > Please also attached on dmidecode log. See [3] for dmidecode, I've also provided the dsdt [4] again. Here is also everything related to ACPI in dmesg [5]. > Thank's a lot! > Joey Lee Let me know if there's anything else I can provide, Baptiste [1] http://lists.freedesktop.org/archives/intel-gfx/2010-October/008339.html [2] https://bugs.freedesktop.org/show_bug.cgi?id=29821 [3] http://zorun.tonbnc.fr/lkml/dmidecode [4] http://zorun.tonbnc.fr/lkml/dsdt [5] http://zorn.tonbnc.fr/lkml/dmesg-acpi.log
[radeon] EDID checksum is invalid
On Mon, Dec 5, 2011 at 3:39 PM, Alexander Beregalov wrote: > Hi > > 3.2.0-rc3-00015-gaaa0b4f Is this a regression? If so can you bisect? Are you just having problems with one particular monitor or all monitors? You might try this patch: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-dce3-add-support-for-hw-i2c-using-ato.patch Alex
[git pull] drm fixes
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie wrote:
>
> Well I do care about kexec but only due to being forced into caring
> about it for a certain enterprise distro that uses it a lot, so maybe
> I was a bit biased in this case, and I dislike random memory
> corruptions due to my subsystem even in the kexec case. Writing a
> random 0 dword somewhere in memory isn't that pretty and no fun to
> track down, when the kexec looks like it succeeds.
So having looked at the patch itself, I don't dislike the notion of
making sure certain fields are nicely initialized. So I don't hate the
patch itself, but quite frankly, to me it doesn't smell even
*remotely* like "regression fix". I don't think this is something that
has ever worked.
And I do realize that some enterprise distros want to use kexec, but
at the same time I say "that's *their* problem". We know kexec hasn't
been horribly reliable, anybody who uses it should have be taking that
into account.
I hope kexec gets more reliable, but I *also* really hope that our RC
series will calm down, and on the whole, weighing the two concerns,
when we're talking about something that has never worked before
either, I think the thing is pretty clear.
That said, if there is some other real use-case ("this fixes problems
with the BIOS from Xyz initializing things to random crap"), I'd have
no real objections to the patch itself.
So my complaint is really a "I want to be more anal about the later
-rc patches, I feel we're slipping", not a "I hate the patch per se".
Linus
[git pull] drm fixes
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie wrote: > > 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been > testing, and one kexec fix from Jerome for an issue reported on the list > where the gpu writeback engines need to be switched off, along with a > trivial fix from Alex. Quite frankly, I think it's too late for something like a kexec bugfix. Nobody cares. So kexec doesn't work - that's not something new. This doesn't smell like a regression to me. And the kcalloc things you mention *sound* like some kind of cleanup crap. The DRM layer has been fairly good for a few releases, but I'm getting the feeling that I need to start pushing back, because I'm getting stuff that I don't think matters, and shouldn't be sent to me after -rc4. So I'm not pulling this. What the heck is up? By now, I want fixes that either fix real regressions that people *care* about, or that help new unreleased hardware that people *will* care about and that cannot possibly mess up old users. kexec? Who the f*ck cares? Really? Linus
[radeon] EDID checksum is invalid
Hi 3.2.0-rc3-00015-gaaa0b4f dmesg |egrep drm|radeon Command line: root=/dev/sda2 radeon.modeset=1 ro Kernel command line: root=/dev/sda2 radeon.modeset=1 ro [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. radeon :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 radeon :01:00.0: setting latency timer to 64 [drm] initializing kernel modesetting (RV730 0x1002:0x9490 0x174B:0xE100). [drm] register mmio base: 0xF500 [drm] register mmio size: 65536 radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M used) radeon :01:00.0: GTT: 512M 0x2000 - 0x3FFF [drm] Detected VRAM RAM=512M, BAR=256M [drm] RAM width 128bits DDR [drm] radeon: 512M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [drm] Driver supports precise vblank timestamp query. radeon :01:00.0: irq 46 for MSI/MSI-X radeon :01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode [drm] PCIE GART of 512M enabled (table at 0x0004). radeon :01:00.0: WB enabled [drm] ring test succeeded in 0 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e20 0x7e20 0x7e24 0x7e24 0x7e28 0x7e28 0x7e2c 0x7e2c [drm] Encoders: [drm] CRT2: INTERNAL_KLDSCP_DAC2 [drm] Connector 1: [drm] HDMI-A [drm] HPD2 [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY1 [drm] Connector 2: [drm] DVI-I [drm] HPD1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] DFP1: INTERNAL_UNIPHY [drm] Internal thermal controller with fan control [drm] radeon: power management initialized [drm] fb mappable at 0xE0142000 [drm] vram apper at 0xE000 [drm] size 5242880 [drm] fb depth is 24 [drm]pitch is 5120 fbcon: radeondrmfb (fb0) is primary device fb0: radeondrmfb frame buffer device drm: registered panic notifier [drm] Initialized radeon 2.12.0 20080528 for :01:00.0 on minor 0 At boot time: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 206 Raw EDID: 27 0f 01 03 80 26 1e 78 2a de 95 a3 54 4c 99 26 0f 50 54 bf ef 80 81 80 81 40 71 4f 01 01 01 01 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4b 1e 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff 00 48 53 47 59 39 30 37 30 33 32 0a 20 20 00 59 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 Raw EDID: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Few days after that: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 38 Raw EDID: 30 2a 00 98 51 00 2a 40 30 70 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4b 1e 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff 00 48 53 47 59 39 30 37 30 33 32 0a 20 20 00 59 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Card is ATI Technologies Inc RV730XT [Radeon HD 4670] [1002:9490] (prog-if 00 [VGA controller]) get-edid |parse-edid get-edid: get-edid version 2.0.0 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0xc01dc ATI ATOMBIOS VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call successful parse-edid: EDID checksum passed. # EDID version 1
[BUG] i915/intel-acpi.c: failed to get supported _DSM functions (was: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off)
CC-ing intel-...@lists.freedesktop.org (see below) On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: Add Cc. to platform-driver-x86 and linux-acpi Hi Baptiste 於 日，2011-12-04 於 17:07 +0100，Baptiste Jonglez 提到： Hi, I've got a lot of troubles with a dual-LVDS Acer laptop (it doesn't have a keyboard, but two displays with touchscreens) The Intel GPU is integrated into the Core i5-480M CPU: it's a bit older than Sandybridge, as it seems to be based on the Arrandale micro-architecture. In the BIOS, both displays work fine; but as soon as the kernel boots up, the second display (i.e. the one where you usually find a keyboard) is turned off. The main display works as expected. xrandr reports two LVDS displays: LVDS1, which is connected, and LVDS2, which is marked as disconnected. No matter what I tried, I can't bring that second display up. During the boot, just after the drm is set up, the following message shows up: [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions (attached is the relevant part of dmesg [1]) Have no idea for this _DSM error, need help from drm and acpi experts. It definitely looks like an ACPI issue. That function is defined in `drivers/gpu/drm/i915/intel_acpi.c'. The whole file was added more than a year ago by commit 723bfd707a97 (see the relevant thread on intel-gfx@ [1]) to add _DSM support. One of the first comment is about Calpella, which is exactly the platform of my laptop (as shown by lshw) However, I honestly don't know what is wrong with that code... Is there anything I can provide to sort things out? I then tried booting with video=LVDS-2:e. The same message shows up while booting, with these two following: [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:4] fbcon_init: detected unhandled fb_set_par error, error code -22 (attached is the relevant part of dmesg [2]) With that kernel command line forcing LVDS2, the drm_crtc_helper_set_config error shows up each time I switch tty; additionally, X does not want to start anymore (spewing out the aforementioned error multiple times before giving up) I'm currently using the latest 3.2 kernel from linus' tree (af968e29acd91ebeb4224e899202c46c93171ecd), but the behavior was similar with a vanilla 3.1.2. Other notes about this issue: - with an Ubuntu 2.6.35 kernel, the second display is on but flickering (with the picture distorted like an old analog TV...). The main display is working fine, as always. I just bumped on bug report #29821 on freedesktop.org [2] which dates the flicker bug around 2.6.35. I guess the ubuntu kernel doesn't have the fix (and actually, the fix might be responsible for the lack of output on the second display with later kernels.) I'll try with an older kernel to see what it does. - with an Archlinux 2.6.37.5 kernel, the behavior is the same as with 3.2, the main display is ok and the second one is off. - I did succeed, only once and out of pure luck, to get the second screen to work with the 3.1.2 kernel. I haven't been able to reproduce that... I had booted with video=LVDS-2:e and let the laptop running ; pressing a key a few hours later turned back *both* displays on (the main display had been turned off by DPMS, and the second, well, was off from the start, as always) While not very helpful, it shows that it's definitely possible. What does Windows platform's behavior? Does there have any physical key that can turn on/off the second LVDS on Windows? Actually, the first thing I did was wiping Windows out :) From what I've seen, both screens seem to work out-of-the-box on Windows. There are only two physical keys: - power-on button - keyboard-labeled button, which seems to do nothing hardware-related; it triggers an event caught up by acer_wmi. I think all it does is telling the OS: hey, pull up the software virtual keyboard on the second display. - there are a some unhandled WMI events logged from the acer-wmi module [3] when closing the lid, opening it, and most importantly, when the (main) screen is turned on or off by DPMS. I will look at your dsdt and log from acer-wmi then try to improve acer-wmi. Thanks a lot! What do you think? I haven't really succeeded in nailing the source of the issue down, but here are a few possibilities I'm thinking of: - the driver is not aware it can drive two LVDS displays (not very likely, and it has worked once, see above) - there is some kind of switch that is able to turn the second screen on or off (I'm thinking of something like rfkill). If so, it looks like something non-standard and undocumented. This would explain the WMI events (see the last note above) What's the behavior of Windows? I meant an internal switch that would be controlled by GPIO or such.
Re: i915: eDP regression
On Mon, Dec 05, 2011 at 09:37:15AM -0500, Adam Jackson wrote: On Sat, 2011-12-03 at 19:35 +0200, Kirill A. Shutemov wrote: Hi, Commit dc22ee6 introduces regression on my laptop HP EliteBook 8440p. I see nothing on the panel after mode setting. Reverting the commit fixes the issue. Try this patch (might need rediffing): http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg05889.html Rediffing looks not trivial (hunk #2 of drivers/gpu/drm/i915/intel_dp.c). Could you provide a patch? -- Kirill A. Shutemov ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
The recursion loop goes retire_requests-unbind-gpu_idle-retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson chris@chris-wilson # we built better bikesheds, but this keeps the rain off for now --- drivers/gpu/drm/i915/i915_gem.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 036bc58..d7d5801 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2026,8 +2026,13 @@ i915_wait_request(struct intel_ring_buffer *ring, * to handle this, the waiter on a request often wants an associated * buffer to have made it to the inactive list, and we would need * a separate wait queue to handle that. +* +* To avoid a recursion with the ilk VT-d workaround (that calls +* gpu_idle when unbinding objects with interruptible==false) don't +* retire requests in that case (because it might call unbind if the +* active list holds the last reference to the object). */ - if (ret == 0) + if (ret == 0 dev_priv-mm.interruptible) i915_gem_retire_requests_ring(ring); return ret; -- 1.7.6.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/omap: add GEM support for tiled/dmm buffers
On Mon, 5 Dec 2011 19:19:22 -0600
Rob Clark rob.cl...@linaro.org wrote:
+ usergart = kzalloc(3 * sizeof(*usergart), GFP_KERNEL);
+
+ /* reserve 4k aligned/wide regions for userspace mappings: */
+ for (i = 0; i ARRAY_SIZE(fmts); i++) {
+ uint16_t h = 1, w = PAGE_SIZE i;
+ tiler_align(fmts[i], w, h);
+ /* note: since each region is 1 4kb page wide, and minimum
+ * number of rows, the height ends up being the same as the
+ * # of pages in the region
+ */
+ usergart[i].height = h;
+ usergart[i].height_shift = ilog2(h);
Seems to be missing anallocation failure check
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42067] [r600g] Compiz overlay icons corrupted on cayman (buggy s3tc support)
https://bugs.freedesktop.org/show_bug.cgi?id=42067 Harald Judt h.j...@gmx.at changed: What|Removed |Added Summary|[r600g] Compiz emblem icons |[r600g] Compiz overlay |corrupted on cayman |icons corrupted on cayman ||(buggy s3tc support) -- 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 v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Monday 05 December 2011, Rob Clark wrote: On the topic of a coherency model for dmabuf, I think we need to look at dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and cpu_finish or whatever they might get called) as barriers: So after a dma_buf_map, all previsously completed dma operations (i.e. unmap already called) and any cpu writes (i.e. cpu_finish called) will be coherent. Similar rule holds for cpu access through the userspace mmap, only writes completed before the cpu_start will show up. Similar, writes done by the device are only guaranteed to show up after the _unmap. Dito for cpu writes and cpu_finish. In short we always need two function calls to denote the start/end of the critical section. Yup, this was exactly my assumption. But I guess it is better to spell it out. I still don't understand how this is going to help you if you let multiple drivers enter and leave the critical section without serializing against one another. That doesn't sound like what I know as critical section. Given some reasonable constraints (all devices must be in the same coherency domain, for instance), you can probably define it in a way that you can have multiple devices mapping the same buffer at the same time, and when no device has mapped the buffer you can have as many concurrent kernel and user space accesses on the same buffer as you like. But you must still guarantee that no software touches a noncoherent buffer while it is mapped into any device and vice versa. Why can't we just mandate that all mappings into the kernel must be coherent and that user space accesses must either be coherent as well or be done by user space that uses explicit serialization with all DMA accesses? Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: Branch 'master' - 2 commits
On Mon, 05 Dec 2011 14:23:55 -0800, Eric Anholt e...@anholt.net wrote: On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris Wilson) wrote: configure.ac |2 +- intel/intel_bufmgr_gem.c | 27 +-- 2 files changed, 22 insertions(+), 7 deletions(-) New commits: commit e73161a02b604742e3da3bca8f13cff81276de43 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Mon Dec 5 10:30:52 2011 + configure: Bump version to 2.4.28 So that we can pull a couple of Intel bug fixes into xf86-video-intel. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Performance before: [ 0] glfirefox-talos-gfx 17.866 17.915 0.14%4/4 after: [ 0] glfirefox-talos-gfx 22.173 22.251 0.20%4/4 There's a pretty obvious opportunity to keep the performance win of the userspace caching that you've broken here, but you gave none of us a chance to review it before you pushed the patch *and shipped a release with it*. This is not acceptable. Please revert and bump the release, and fix it correctly. No, what was unacceptable was a vma leak impacting a critical system application, and for the library API to be broken by design. The onus is to improve performance without regressing system stability, not the other way around. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] i915/intel-acpi.c: failed to get supported _DSM functions (was: [Dual-LVDS Acer Iconia laptop] i915/DRM issue: one screen stays off)
On Mon, Dec 05, 2011 at 09:56:47PM +0100, Baptiste Jonglez wrote: CC-ing intel-...@lists.freedesktop.org (see below) On Mon, Dec 05, 2011 at 11:00:41AM +0800, joeyli wrote: [drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions (attached is the relevant part of dmesg [1]) Have no idea for this _DSM error, need help from drm and acpi experts. It definitely looks like an ACPI issue. That function is defined in `drivers/gpu/drm/i915/intel_acpi.c'. The whole file was added more than a year ago by commit 723bfd707a97 (see the relevant thread on intel-gfx@ [1]) to add _DSM support. One of the first comment is about Calpella, which is exactly the platform of my laptop (as shown by lshw) Ignore that - it's entirely harmless. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [radeon] EDID checksum is invalid
On Mon, Dec 5, 2011 at 3:39 PM, Alexander Beregalov a.berega...@gmail.com wrote: Hi 3.2.0-rc3-00015-gaaa0b4f Is this a regression? If so can you bisect? Are you just having problems with one particular monitor or all monitors? You might try this patch: http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-dce3-add-support-for-hw-i2c-using-ato.patch Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42067] [r600g] Compiz overlay icons corrupted on cayman (buggy s3tc support)
https://bugs.freedesktop.org/show_bug.cgi?id=42067 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Alex Deucher ag...@yahoo.com 2011-12-06 05:56:36 PST --- *** This bug has been marked as a duplicate of bug 38173 *** -- 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: Make ib allocation size function of cs size
On Mon, Dec 5, 2011 at 6:39 PM, j.gli...@gmail.com wrote: Two following patch are on top of http://cgit.freedesktop.org/~glisse/linux They make the ib allocation size a function of the cs size, this allow to avoid wasting pool space and avoid to trigger fence_wait in ib_get. I am still evaluating how much fence_wait we avoid with this. Both patches are lightly tested and Reviewed-by: Alex Deucher alexander.deuc...@amd.com Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe
https://bugs.freedesktop.org/show_bug.cgi?id=43448 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Attachment #54049|1 |0 is patch|| Attachment #54049|0 |1 is obsolete|| -- 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 v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 06, 2011 at 01:16:58PM +, Arnd Bergmann wrote: On Monday 05 December 2011, Rob Clark wrote: On the topic of a coherency model for dmabuf, I think we need to look at dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and cpu_finish or whatever they might get called) as barriers: So after a dma_buf_map, all previsously completed dma operations (i.e. unmap already called) and any cpu writes (i.e. cpu_finish called) will be coherent. Similar rule holds for cpu access through the userspace mmap, only writes completed before the cpu_start will show up. Similar, writes done by the device are only guaranteed to show up after the _unmap. Dito for cpu writes and cpu_finish. In short we always need two function calls to denote the start/end of the critical section. Yup, this was exactly my assumption. But I guess it is better to spell it out. I still don't understand how this is going to help you if you let multiple drivers enter and leave the critical section without serializing against one another. That doesn't sound like what I know as critical section. I already regret to having added that last critical section remark. Think barriers. It's just that you need a barrier in both directions that bracket the actual usage. In i915-land we call the first one generally invalidate (so that caches on the target domain don't contain stale data) and that second one flush (to get any data out of caches). Given some reasonable constraints (all devices must be in the same coherency domain, for instance), you can probably define it in a way that you can have multiple devices mapping the same buffer at the same time, and when no device has mapped the buffer you can have as many concurrent kernel and user space accesses on the same buffer as you like. But you must still guarantee that no software touches a noncoherent buffer while it is mapped into any device and vice versa. Why can't we just mandate that all mappings into the kernel must be coherent and that user space accesses must either be coherent as well or be done by user space that uses explicit serialization with all DMA accesses? I agree with your points here, afaics the contentious issue is just whether dma_buf should _enforce_ this strict ordering. I'm leading towards a no for the following reasons: - gpu people love nonblocking interfaces (and love to come up with abuses). In the generic case we'd need some more functions to properly flush everything while 2 devices access a buffer concurrently (which is imo a bit unrealistic). But e.g. 2 gpus rendering in SLI mode very much want to access the same buffer at the same time (and the kernel+userspace gpu driver already needs all the information about caches to make that happen, at least on x86). - Buffer sharing alone has already some great potential for deadlock and lock recursion issues. Making dma_buf into something that very much acts like a new locking primitive itself (even exposed to userspace) will make this much worse. I've seen some of the kernel/userspace shared hwlock code of dri1 yonder, and it's horrible (and at least for the case of the dri1 hwlock, totally broken). - All current subsystem already have the concept to pass the ownership of a buffer between the device and userspace (sometimes even more than just 2 domains, like in i915 ...). Userspace already needs to use this interface to get anything resembling correct data. I don't see any case where userspace can't enforce passing around buffer ownership if multiple devices are involved (we obviously need to clarify subsystem interfaces to make it clear when a buffer is in use and when another device taking part in the sharing could use it). So I don't see how the kernel enforcing strict access ordering helps implementing correct userspace. - I don't see any security needs that would make it necessary for the kernel to enforce any consistency guarantees for concurrent access - we're only dealing with pixel data in all the currently discussed generic use-cases. So I think garbage as an end-result is acceptable if userspace does stupid things (or fails at trying to be clever). Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe
https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #5 from Michel Dänzer mic...@daenzer.net 2011-12-06 07:46:32 PST --- Looks like /usr/lib64/dri/r600_dri.so's dri2CreateNewScreen() hook fails, but it's not clear why. Maybe you can try running glxinfo in gdb, setting a breakpoint at dri2CreateNewScreen and tracing where the failure is coming from. -- 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 43448] No native 3D acceleration with Radeon FirePro M7740 (m97 / rv740) - llvm pipe
https://bugs.freedesktop.org/show_bug.cgi?id=43448 --- Comment #6 from Dave Airlie airl...@freedesktop.org 2011-12-06 08:12:01 PST --- check mesa is built with radeon drm support. -- 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
[git pull] drm fixes
Hi Linus, 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been testing, and one kexec fix from Jerome for an issue reported on the list where the gpu writeback engines need to be switched off, along with a trivial fix from Alex. Due to the size of the kexec fix I've decided to keep this pull small. (I have some kzalloc-kcalloc fixes to check on). Dave. The following changes since commit 45e713efe2fa574b6662e7fb63fae9497c5e03d4: Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2011-12-05 16:54:15 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alex Deucher (1): drm/radeon/kms: fix return type for radeon_encoder_get_dp_bridge_encoder_id Daniel Vetter (1): drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a Jerome Glisse (1): drm/radeon: disable possible GPU writeback early v3 drivers/gpu/drm/i915/i915_gem.c |7 ++- drivers/gpu/drm/radeon/evergreen.c |2 ++ drivers/gpu/drm/radeon/ni.c | 18 ++ drivers/gpu/drm/radeon/nid.h | 19 +++ drivers/gpu/drm/radeon/r100.c| 20 ++-- drivers/gpu/drm/radeon/r520.c|2 +- drivers/gpu/drm/radeon/r600.c| 16 drivers/gpu/drm/radeon/radeon_asic.h |2 ++ drivers/gpu/drm/radeon/radeon_encoders.c |7 +++ drivers/gpu/drm/radeon/rs600.c | 20 +++- drivers/gpu/drm/radeon/rs600d.h | 21 + drivers/gpu/drm/radeon/rs690.c |2 +- drivers/gpu/drm/radeon/rv515.c |2 +- drivers/gpu/drm/radeon/rv770.c | 16 drivers/gpu/drm/radeon/rv770d.h | 20 15 files changed, 151 insertions(+), 23 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
On Tue, Dec 6, 2011 at 8:21 AM, Dave Airlie airl...@linux.ie wrote: 3 fixes, one for an ongoing Intel VT-d/Ironlake GPU that I've been testing, and one kexec fix from Jerome for an issue reported on the list where the gpu writeback engines need to be switched off, along with a trivial fix from Alex. Quite frankly, I think it's too late for something like a kexec bugfix. Nobody cares. So kexec doesn't work - that's not something new. This doesn't smell like a regression to me. And the kcalloc things you mention *sound* like some kind of cleanup crap. The DRM layer has been fairly good for a few releases, but I'm getting the feeling that I need to start pushing back, because I'm getting stuff that I don't think matters, and shouldn't be sent to me after -rc4. So I'm not pulling this. What the heck is up? By now, I want fixes that either fix real regressions that people *care* about, or that help new unreleased hardware that people *will* care about and that cannot possibly mess up old users. kexec? Who the f*ck cares? Really? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
What the heck is up? Well I do care about kexec but only due to being forced into caring about it for a certain enterprise distro that uses it a lot, so maybe I was a bit biased in this case, and I dislike random memory corruptions due to my subsystem even in the kexec case. Writing a random 0 dword somewhere in memory isn't that pretty and no fun to track down, when the kexec looks like it succeeds. But I've no problem leaving it sitting around until -next. The kzalloc-kcalloc ones are partly better integer overflow defence where userspace passes in a number of objects but I just need to make sure they are that and not cleanups, but I haven't gotten around to it yet. Cool I'll resend just the Intel and obvious radeon one and stick the others into -next. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes
On Tue, Dec 6, 2011 at 8:36 AM, Dave Airlie airl...@gmail.com wrote: Well I do care about kexec but only due to being forced into caring about it for a certain enterprise distro that uses it a lot, so maybe I was a bit biased in this case, and I dislike random memory corruptions due to my subsystem even in the kexec case. Writing a random 0 dword somewhere in memory isn't that pretty and no fun to track down, when the kexec looks like it succeeds. So having looked at the patch itself, I don't dislike the notion of making sure certain fields are nicely initialized. So I don't hate the patch itself, but quite frankly, to me it doesn't smell even *remotely* like regression fix. I don't think this is something that has ever worked. And I do realize that some enterprise distros want to use kexec, but at the same time I say that's *their* problem. We know kexec hasn't been horribly reliable, anybody who uses it should have be taking that into account. I hope kexec gets more reliable, but I *also* really hope that our RC series will calm down, and on the whole, weighing the two concerns, when we're talking about something that has never worked before either, I think the thing is pretty clear. That said, if there is some other real use-case (this fixes problems with the BIOS from Xyz initializing things to random crap), I'd have no real objections to the patch itself. So my complaint is really a I want to be more anal about the later -rc patches, I feel we're slipping, not a I hate the patch per se. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43018] (NI Turks Pro) : UT2004-demo crashes after few minutes of launch
https://bugs.freedesktop.org/show_bug.cgi?id=43018 --- Comment #5 from Michel Dänzer mic...@daenzer.net 2011-12-06 09:16:12 PST --- (In reply to comment #4) Created attachment 53642 [details] backtrace Thanks, but I can't see an actual backtrace of the crash. Ideal would be if you could run ut2004-demo in gdb (or attach gdb to the running process) and get a backtrace that way. Alternatively, there might be a backtrace in the ut2004-demo log file. -- 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 43000] huge performance regression in ut2004 since 7.11
https://bugs.freedesktop.org/show_bug.cgi?id=43000 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #8 from Michel Dänzer mic...@daenzer.net 2011-12-06 09:19:44 PST --- (In reply to comment #7) Now the performance thing seems solved. Great, resolving. Should I rename this report or start a new one for the laggyness due to the high variance of fps? The latter, if anything. -- 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: [Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: The recursion loop goes retire_requests-unbind-gpu_idle-retire_reqeusts. Every time we go through this we need a - active object that can be retired - and there are no other references to that object than the one from the active list, so that it gets unbound and freed immediately. Otherwise the recursion stops. So the recursion is only limited by the number of objects that fit these requirements sitting in the active list any time retire_request is called. Issue exercised by tests/gem_unref_active_buffers from i-g-t. There's been a decent bikeshed discussion whether it wouldn't be better to pass around a flag, but imo this is o.k. for such a limited case that only supports a w/a. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson chris@chris-wilson # we built better bikesheds, but this keeps the rain off for now --- What about: http://lists.freedesktop.org/archives/intel-gfx/2011-October/012984.html Did someone prove that doesn't work? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #10 from Michel Dänzer mic...@daenzer.net 2011-12-06 10:24:38 UTC --- (In reply to comment #10) I also tried kmod-catalyst (proprietary drivers) and running it with wine64 none of which helped. If the problem is the same with the proprietary drivers, then it's more likely a Gothic / Wine / configuration issue, as it's very unlikely that both drivers would have exactly the same 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
[Bug 43426] gallium3d makes krita crash
https://bugs.freedesktop.org/show_bug.cgi?id=43426 --- Comment #2 from Michel Dänzer mic...@daenzer.net 2011-12-06 10:26:29 PST --- Does running krita with the environment variable DRAW_USE_LLVM=0 work around the 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
[Bug 43395] Game running in wine stops rendering
https://bugs.freedesktop.org/show_bug.cgi?id=43395 --- Comment #11 from Tomas Schlosser schlosse...@seznam.cz 2011-12-06 10:59:29 PST --- Oh, sorry, I posted the copied the bugreport I created for wine. I tried again with correct version of proprietary drivers installed and the problem was gone. I also tried compiling the mesa drivers by tutorial on www.mesa3d.org and the game didn't even start then (gave me Access violation). I still have a few ideas how to run it on mesa from git, but it requires more try-fail attempts. -- 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: [radeon] EDID checksum is invalid
On 12/5/11 3:39 PM, Alexander Beregalov wrote: At boot time: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 206 Raw EDID: 27 0f 01 03 80 26 1e 78 2a de 95 a3 54 4c 99 26 0f 50 54 bf ef 80 81 80 81 40 71 4f 01 01 01 01 01 01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4b 1e 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff 00 48 53 47 59 39 30 37 30 33 32 0a 20 20 00 59 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff This looks like an EDID fetch of bytes 16 through 143, instead of 0 through 127 (ie, skip the first 16, last 16 filled with -1). Few days after that: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 38 Raw EDID: 30 2a 00 98 51 00 2a 40 30 70 13 00 78 2d 11 00 00 1e 00 00 00 fd 00 38 4b 1e 51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff 00 48 53 47 59 39 30 37 30 33 32 0a 20 20 00 59 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Offset of 54 bytes here, which is weirder. Possibly the i2c code isn't resetting the index to 0 when it needs to. - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] libdrm: update drm headers from kernel, including new overlay ioctls structs
Add structs and functions necessary for the new plane and fb handling code,
including a new header, drm_fourcc.h, that includes the surface formats
supported by various DRM drivers.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/Makefile.am |1 +
include/drm/drm.h| 13 -
include/drm/drm_fourcc.h | 130 +++
include/drm/drm_mode.h | 100 --
xf86drmMode.c| 153 ++
xf86drmMode.h| 33 ++
6 files changed, 411 insertions(+), 19 deletions(-)
create mode 100644 include/drm/drm_fourcc.h
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 43695bd..2923ab4 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -26,6 +26,7 @@ klibdrmincludedir = ${includedir}/libdrm
klibdrminclude_HEADERS = \
drm.h \
drm_mode.h \
+ drm_fourcc.h \
drm_sarea.h \
i915_drm.h \
mga_drm.h \
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 5fd24fc..bb2dea8 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -467,12 +467,15 @@ struct drm_irq_busid {
enum drm_vblank_seq_type {
_DRM_VBLANK_ABSOLUTE = 0x0, /** Wait for specific vblank sequence
number */
_DRM_VBLANK_RELATIVE = 0x1, /** Wait for given number of vblanks */
+ /* bits 1-6 are reserved for high crtcs */
+ _DRM_VBLANK_HIGH_CRTC_MASK = 0x003e,
_DRM_VBLANK_EVENT = 0x400, /** Send event instead of blocking */
_DRM_VBLANK_FLIP = 0x800, /** Scheduled buffer swap should flip
*/
_DRM_VBLANK_NEXTONMISS = 0x1000,/** If missed, wait for next
vblank */
_DRM_VBLANK_SECONDARY = 0x2000, /** Secondary display
controller */
_DRM_VBLANK_SIGNAL = 0x4000 /** Send signal instead of blocking,
unsupported */
};
+#define _DRM_VBLANK_HIGH_CRTC_SHIFT 1
#define _DRM_VBLANK_TYPES_MASK (_DRM_VBLANK_ABSOLUTE | _DRM_VBLANK_RELATIVE)
#define _DRM_VBLANK_FLAGS_MASK (_DRM_VBLANK_EVENT | _DRM_VBLANK_SIGNAL | \
@@ -674,6 +677,8 @@ struct drm_get_cap {
#define DRM_IOCTL_UNLOCK DRM_IOW( 0x2b, struct drm_lock)
#define DRM_IOCTL_FINISH DRM_IOW( 0x2c, struct drm_lock)
+#define DRM_IOCTL_GEM_PRIME_OPENDRM_IOWR(0x2e, struct drm_gem_open)
+
#define DRM_IOCTL_AGP_ACQUIRE DRM_IO( 0x30)
#define DRM_IOCTL_AGP_RELEASE DRM_IO( 0x31)
#define DRM_IOCTL_AGP_ENABLE DRM_IOW( 0x32, struct drm_agp_mode)
@@ -713,6 +718,10 @@ struct drm_get_cap {
#define DRM_IOCTL_MODE_CREATE_DUMB DRM_IOWR(0xB2, struct drm_mode_create_dumb)
#define DRM_IOCTL_MODE_MAP_DUMBDRM_IOWR(0xB3, struct drm_mode_map_dumb)
#define DRM_IOCTL_MODE_DESTROY_DUMBDRM_IOWR(0xB4, struct
drm_mode_destroy_dumb)
+#define DRM_IOCTL_MODE_GETPLANERESOURCES DRM_IOWR(0xB5, struct
drm_mode_get_plane_res)
+#define DRM_IOCTL_MODE_GETPLANEDRM_IOWR(0xB6, struct
drm_mode_get_plane)
+#define DRM_IOCTL_MODE_SETPLANEDRM_IOWR(0xB7, struct
drm_mode_set_plane)
+#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
/**
* Device specific ioctls should only be in their respective headers
@@ -755,9 +764,10 @@ struct drm_event_vblank {
};
#define DRM_CAP_DUMB_BUFFER 0x1
-#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
+#define DRM_CAP_VBLANK_HIGH_CRTC 0x2
/* typedef area */
+#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
typedef struct drm_drawable_info drm_drawable_info_t;
typedef struct drm_tex_region drm_tex_region_t;
@@ -799,5 +809,6 @@ typedef struct drm_agp_binding drm_agp_binding_t;
typedef struct drm_agp_info drm_agp_info_t;
typedef struct drm_scatter_gather drm_scatter_gather_t;
typedef struct drm_set_version drm_set_version_t;
+#endif
#endif
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
new file mode 100644
index 000..b1107cb
--- /dev/null
+++ b/include/drm/drm_fourcc.h
@@ -0,0 +1,130 @@
+/*
+ * Copyright 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS
Re: [PATCH 1/2] libdrm: update drm headers from kernel, including new overlay ioctls structs
On Tue, 6 Dec 2011 15:23:57 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Add structs and functions necessary for the new plane and fb handling code, including a new header, drm_fourcc.h, that includes the surface formats supported by various DRM drivers. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- Arg some misc other stuff got pulled in... I'll repost with just the plane stuff. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/benchmark: common modes sweep ignores 640x480@32
From: Chen Jie ch...@lemote.com Sweep common_modes array should start with index 0. Signed-off-by: Chen Jie ch...@lemote.com --- drivers/gpu/drm/radeon/radeon_benchmark.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_benchmark.c b/drivers/gpu/drm/radeon/radeon_benchmark.c index 17e1a9b..d1cea8d 100644 --- a/drivers/gpu/drm/radeon/radeon_benchmark.c +++ b/drivers/gpu/drm/radeon/radeon_benchmark.c @@ -229,21 +229,21 @@ void radeon_benchmark(struct radeon_device *rdev, int test_number) break; case 6: /* GTT to VRAM, buffer size sweep, common modes */ - for (i = 1; i RADEON_BENCHMARK_COMMON_MODES_N; i++) + for (i = 0; i RADEON_BENCHMARK_COMMON_MODES_N; i++) radeon_benchmark_move(rdev, common_modes[i], RADEON_GEM_DOMAIN_GTT, RADEON_GEM_DOMAIN_VRAM); break; case 7: /* VRAM to GTT, buffer size sweep, common modes */ - for (i = 1; i RADEON_BENCHMARK_COMMON_MODES_N; i++) + for (i = 0; i RADEON_BENCHMARK_COMMON_MODES_N; i++) radeon_benchmark_move(rdev, common_modes[i], RADEON_GEM_DOMAIN_VRAM, RADEON_GEM_DOMAIN_GTT); break; case 8: /* VRAM to VRAM, buffer size sweep, common modes */ - for (i = 1; i RADEON_BENCHMARK_COMMON_MODES_N; i++) + for (i = 0; i RADEON_BENCHMARK_COMMON_MODES_N; i++) radeon_benchmark_move(rdev, common_modes[i], RADEON_GEM_DOMAIN_VRAM, RADEON_GEM_DOMAIN_VRAM); -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/omap: add GEM support for tiled/dmm buffers
On Tue, Dec 6, 2011 at 5:30 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Mon, 5 Dec 2011 19:19:22 -0600
Rob Clark rob.cl...@linaro.org wrote:
+ usergart = kzalloc(3 * sizeof(*usergart), GFP_KERNEL);
+
+ /* reserve 4k aligned/wide regions for userspace mappings: */
+ for (i = 0; i ARRAY_SIZE(fmts); i++) {
+ uint16_t h = 1, w = PAGE_SIZE i;
+ tiler_align(fmts[i], w, h);
+ /* note: since each region is 1 4kb page wide, and minimum
+ * number of rows, the height ends up being the same as the
+ * # of pages in the region
+ */
+ usergart[i].height = h;
+ usergart[i].height_shift = ilog2(h);
Seems to be missing anallocation failure check
oh, woops.. I've fixed that.. will give a couple more days to see if
there are any other comments and then send v2..
BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
Hi Arnd,
Thanks for your review!
On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have about things I spotted.
Do you have prototype exporter and consumer drivers that you can post
for clarification?
In the patch 2, you have a section about migration that mentions that
it is possible to export a buffer that can be migrated after it
is already mapped into one user driver. How does that work when
the physical addresses are mapped into a consumer device already?
I guess I need to clear it up in the documentation - when I said once
all ongoing access is completed - I meant to say once all current
users have finished accessing and have unmapped this buffer. So I
agree with Rob - the migration would only be possible for attached
but unmapped buffers. I will update the documentation.
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 21cf46f..07d8095 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,14 @@ config SYS_HYPERVISOR
source drivers/base/regmap/Kconfig
+config DMA_SHARED_BUFFER
+ bool Buffer framework to be shared between drivers
+ default n
+ depends on ANON_INODES
I would make this 'select ANON_INODES', like the other users of this
feature.
Sure.
+ return dmabuf;
+}
+EXPORT_SYMBOL(dma_buf_export);
I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL,
because it's really a low-level function that I would expect
to get used by in-kernel subsystems providing the feature to
users and having back-end drivers, but it's not the kind of thing
we want out-of-tree drivers to mess with.
Agreed.
+/**
+ * dma_buf_fd - returns a file descriptor for the given dma_buf
+ * @dmabuf: [in] pointer to dma_buf for which fd is required.
+ *
+ * On success, returns an associated 'fd'. Else, returns error.
+ */
+int dma_buf_fd(struct dma_buf *dmabuf)
+{
+ int error, fd;
+
+ if (!dmabuf-file)
+ return -EINVAL;
+
+ error = get_unused_fd_flags(0);
Why not simply get_unused_fd()?
:) oversight. Will correct.
+/**
+ * dma_buf_attach - Add the device to dma_buf's attachments list;
optionally,
+ * calls attach() of dma_buf_ops to allow device-specific attach
functionality
+ * @dmabuf: [in] buffer to attach device to.
+ * @dev: [in] device to be attached.
+ *
+ * Returns struct dma_buf_attachment * for this attachment; may return NULL.
+ *
Or may return a negative error code. It's better to be consistent here:
either always return NULL on error, or change the allocation error to
ERR_PTR(-ENOMEM).
Ok, that makes sense.
+ */
+struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+ struct dma_buf_attachment *attach;
+ int ret;
+
+ BUG_ON(!dmabuf || !dev);
+
+ attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
+ if (attach == NULL)
+ goto err_alloc;
+
+ mutex_lock(dmabuf-lock);
+
+ attach-dev = dev;
+ attach-dmabuf = dmabuf;
+ if (dmabuf-ops-attach) {
+ ret = dmabuf-ops-attach(dmabuf, dev, attach);
+ if (!ret)
+ goto err_attach;
You probably mean if (ret) here instead of if (!ret), right?
yes - a stupid one! will correct.
+ /* allow allocator to take care of cache ops */
+ void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
+ void (*sync_sg_for_device)(struct dma_buf *, struct device *);
I don't see how this works with multiple consumers: For the streaming
DMA mapping, there must be exactly one owner, either the device or
the CPU. Obviously, this rule needs to be extended when you get to
multiple devices and multiple device drivers, plus possibly user
mappings. Simply assigning the buffer to the device from one
driver does not block other drivers from touching the buffer, and
assigning it to the cpu does not stop other hardware that the
code calling sync_sg_for_cpu is not aware of.
The only way to solve this that I can think of right now is to
mandate that the mappings are all coherent (i.e. noncachable
on noncoherent architectures like ARM). If you do that, you no
longer need the sync_sg_for_* calls.
I will take yours and Daniel's suggestion, and remove these; if at all
they're needed, we can add them back again later, with
/s/device/attachment as suggested by Daniel.
+#ifdef CONFIG_DMA_SHARED_BUFFER
Do you have a use case for making the interface compile-time disabled?
I had assumed that any code using it would make no sense if it's not
available so you don't actually need this.
Ok. Though if we keep the interface compile-time disabled, the users
can actually check and
