[Bug 46866] New: Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 Bug #: 46866 Summary: Piglit:Multiple failures observed while running quick-driver.tests Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Driver Stack Details: = 1)Kernel-3.0.0-12-generice-pae 2)drm-2.4.31 3)Mesa-8.1-devel (git-897af1d) 4)Xorg-server-1.11.4 5)xf86-video-ati- master System Environment: === Asic : EG CedarPro O.S. : Ubuntu-11.10 (32 bit) Processor: AMD Athlon(tm) 64 X2 @ 1 GHz Memory : 2 GB Steps to Reproduce: === 1) Install piglit from git clone git://anongit.freedesktop.org/git/piglit 2) #./piglit-run.py tests/quick-driver.tests results/quick-driver.results #./piglit-summary-html.py summary/quick-driver results/quick-driver.results Observation : Multiple failures observed while running quick-driver.tests === -- 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 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 --- Comment #1 from samit vats 2012-03-02 00:42:41 PST --- Created attachment 57898 --> https://bugs.freedesktop.org/attachment.cgi?id=57898 piglit-log -- 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 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 --- Comment #2 from samit vats 2012-03-02 00:43:15 PST --- Created attachment 57899 --> https://bugs.freedesktop.org/attachment.cgi?id=57899 dmesg -- 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 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 --- Comment #3 from samit vats 2012-03-02 00:43:38 PST --- Created attachment 57900 --> https://bugs.freedesktop.org/attachment.cgi?id=57900 Xorg.log -- 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 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 samit vats changed: What|Removed |Added Priority|medium |high -- 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 22195] app crashed to desktop with Radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=22195 dre changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- 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
libdrm and platform devices?
Hi All, I have a drm device on the platform bus, similar to the exynos driver. right now libdrm (at least the tests included in libdrm) refuses to open the device because i915, nouveau, radeon and vmwgfx is all they know about. Looking at the libdrm code it is not obvious how to fix this (except for adding "exynos", "mydevice", "myotherdevice" to the module table which seems awkward and not very futureproof). Any hints or thoughts how to proceed here? Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: libdrm and platform devices?
> > I have a drm device on the platform bus, similar to the exynos driver. > right now libdrm (at least the tests included in libdrm) refuses to open > the device because i915, nouveau, radeon and vmwgfx is all they know > about. Looking at the libdrm code it is not obvious how to fix this > (except for adding "exynos", "mydevice", "myotherdevice" to the module > table which seems awkward and not very futureproof). Any hints or > thoughts how to proceed here? libdrm tests aren't really used that much, and it might be easier to just not care. people just hack on them for their platforms and sometimes someone pushes one in. You more likely want specific tests for your platform like intel-gpu-tools. Dave. > > Thanks > Sascha > > > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > ___ > 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
Re: libdrm and platform devices?
On Fri, Mar 02, 2012 at 12:02:21PM +, Dave Airlie wrote:
> >
> > I have a drm device on the platform bus, similar to the exynos driver.
> > right now libdrm (at least the tests included in libdrm) refuses to open
> > the device because i915, nouveau, radeon and vmwgfx is all they know
> > about. Looking at the libdrm code it is not obvious how to fix this
> > (except for adding "exynos", "mydevice", "myotherdevice" to the module
> > table which seems awkward and not very futureproof). Any hints or
> > thoughts how to proceed here?
>
> libdrm tests aren't really used that much, and it might be easier to
> just not care.
>
> people just hack on them for their platforms and sometimes someone
> pushes one in.
Ok, I can keep a local hack. What are your plans for the
xf86-modesetting driver? It works nicely after I commented out some
pci specific things and replaced drmOpen(NULL, BusID) with
open("/dev/dri/card0", O_RDWR). Do you plan to continue on the driver
and would accept patches for it?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: libdrm and platform devices?
On Fri, Mar 2, 2012 at 1:06 PM, Sascha Hauer wrote:
> On Fri, Mar 02, 2012 at 12:02:21PM +, Dave Airlie wrote:
>> >
>> > I have a drm device on the platform bus, similar to the exynos driver.
>> > right now libdrm (at least the tests included in libdrm) refuses to open
>> > the device because i915, nouveau, radeon and vmwgfx is all they know
>> > about. Looking at the libdrm code it is not obvious how to fix this
>> > (except for adding "exynos", "mydevice", "myotherdevice" to the module
>> > table which seems awkward and not very futureproof). Any hints or
>> > thoughts how to proceed here?
>>
>> libdrm tests aren't really used that much, and it might be easier to
>> just not care.
>>
>> people just hack on them for their platforms and sometimes someone
>> pushes one in.
>
> Ok, I can keep a local hack. What are your plans for the
> xf86-modesetting driver? It works nicely after I commented out some
> pci specific things and replaced drmOpen(NULL, BusID) with
> open("/dev/dri/card0", O_RDWR). Do you plan to continue on the driver
> and would accept patches for it?
might be why I added busid to the usb, my memory of why is hazy.
you should have been able to specify /dev/dri/card0 in the xorg.conf
Option "kmsdev"
and yes I'll continue working on it, I have to hook it in as a linux
fallback driver in the X server.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42727] radeon KMS with CRT TV
https://bugzilla.kernel.org/show_bug.cgi?id=42727 --- Comment #30 from Egor Y. Egorov 2012-03-02 13:34:22 --- Created an attachment (id=72515) --> (https://bugzilla.kernel.org/attachment.cgi?id=72515) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42727] radeon KMS with CRT TV
https://bugzilla.kernel.org/show_bug.cgi?id=42727 --- Comment #31 from Egor Y. Egorov 2012-03-02 13:35:40 --- I run # ./radeonreg regset 0x04f4 0x8062 OLD: 0x04f4 (04f4) 0x8062 (-2147483550) NEW: 0x04f4 (04f4) 0x8062 (-2147483550) EGOROV radeontool # ./radeonreg regset 0x5e00 0x0001 OLD: 0x5e00 (5e00) 0x0001 (1) NEW: 0x5e00 (5e00) 0x0001 (1) EGOROV radeontool # ./radeonreg regset 0x6810 0x OLD: 0x6810 (6810) 0x (0) NEW: 0x6810 (6810) 0x (0) EGOROV radeontool # ./radeonreg regset 0x6830 0x OLD: 0x6830 (6830) 0x (0) NEW: 0x6830 (6830) 0x (0) EGOROV radeontool # ./radeonreg regset 0x6880 0x00010101 OLD: 0x6880 (6880) 0x00010101 (65793) NEW: 0x6880 (6880) 0x00010101 (65793) EGOROV radeontool # ./radeonreg regset 0x6884 0x OLD: 0x6884 (6884) 0x (0) NEW: 0x6884 (6884) 0x (0) EGOROV radeontool # ./radeonreg regset 0x7a00 0x0001 OLD: 0x7a00 (7a00) 0x0001 (1) NEW: 0x7a00 (7a00) 0x0001 (1) EGOROV radeontool # but everything remains as before -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Block: use a freezable workqueue for disk-event polling
On 02/17/2012 10:22 PM, Alan Stern wrote: > This patch (as1519) fixes a bug in the block layer's disk-events > polling. The polling is done by a work routine queued on the > system_nrt_wq workqueue. Since that workqueue isn't freezable, the > polling continues even in the middle of a system sleep transition. > > Obviously, polling a suspended drive for media changes and such isn't > a good thing to do; in the case of USB mass-storage devices it can > lead to real problems requiring device resets and even re-enumeration. > > The patch fixes things by creating a new system-wide, non-reentrant, > freezable workqueue and using it for disk-events polling. Thanks Alan, picked up. -- Jens Axboe ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #31 from Harald Judt 2012-03-02 07:10:27 PST --- Using current git of kernel, xorg-server, xf86-video-ati and mesa, the screen still freezes every once in a while and dmesg shows these messages: radeon :01:00.0: offset 0x20 is in reserved area 0x80 radeon :01:00.0: offset 0x20 is in reserved area 0x80 -- 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: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart: > Hello everybody, > > First of all, I would like to thank all the attendees for their > participation in the mini-summit that helped make the meeting a success. > > Here are my consolidated notes that cover both the Linaro Connect meeting > and the ELC meeting. They're also available at > http://www.ideasonboard.org/media/meetings/. > > > Kernel Display and Video API Consolidation mini-summit at ELC 2012 > -- > [...] > *** Display Panel Drivers *** > > Goal: Sharing display panel drivers between display controllers from > different vendors. > > Panels are connected to the display controller through a standard bus > with a control channel (DSI and eDP are two major such buses). Various > vendors have created proprietary interfaces for panel drivers: > > - TI on OMAP (drivers/video/omap2/displays). > - Samsung on Exynos (drivers/video/exynos). > - ST-Ericsson on MCDE > (http://www.igloocommunity.org/gitweb/?p=kernel/igloo- > kernel.git;a=tree;f=drivers/video/mcde) > - Renesas is working on a similar interface for SH Mobile. > > HDMI-on-DSI transmitters, while not panels per-se, can be supported > through the same API. > > A Low level Linux Display Framework (https://lkml.org/lkml/2011/9/15/107) > has been proposed and overlaps with this topic. > > For DSI, a possible abstraction level would be a DCS (Display Command > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be > implemented as DCS drivers. > > Action points: > - Marcus to work on a proposal for DCS-based panels (with Tomi Valkeinen > and Morimoto-san). It would also be interesting to see something similar for MIPI-DBI (type B for me) [aka rfbi on omap], as most epaper displays use this to transmit data and currently use half-baked interfaces. So hopefully I'll be able to follow the discussion and can then try to convert your findings to the dbi case. Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
On 2 March 2012 15:23, Heiko Stübner wrote:
> Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart:
> [...]
> > For DSI, a possible abstraction level would be a DCS (Display Command
> > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be
> > implemented as DCS drivers.
> >
> > Action points:
> > - Marcus to work on a proposal for DCS-based panels (with Tomi
> Valkeinen
> > and Morimoto-san).
>
> It would also be interesting to see something similar for MIPI-DBI (type B
> for
> me) [aka rfbi on omap], as most epaper displays use this to transmit data
> and
> currently use half-baked interfaces.
>
> So hopefully I'll be able to follow the discussion and can then try to
> convert
> your findings to the dbi case.
>
> Heiko
>
The idea is to abstract the DSI/DBI-2 type of transport and focus on the
DCS command set level. The driver should be able to select between DBI and
DSI by providing some "struct dcs_device { ifc = DSI/DBI2, ... }" data to
the DCS bus.
Something like a stripped version of
www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=include/video/mcde.h#l113,
but for DBI/DSI only.
/BR
/Marcus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] Don't require pciaccess if Intel is disabled
On Thu, 1 Mar 2012 12:21:17 -0500, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> configure.ac | 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 97bbcb7..71a596c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)
> AC_SUBST(PTHREADSTUBS_CFLAGS)
> AC_SUBST(PTHREADSTUBS_LIBS)
>
> -PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> -AC_SUBST(PCIACCESS_CFLAGS)
> -AC_SUBST(PCIACCESS_LIBS)
> -
> pkgconfigdir=${libdir}/pkgconfig
> AC_SUBST(pkgconfigdir)
> AC_ARG_ENABLE([udev],
> @@ -261,6 +257,12 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
> fi
> fi
>
> +if test "x$INTEL" != "xno"; then
> + PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> +fi
> +AC_SUBST(PCIACCESS_CFLAGS)
> +AC_SUBST(PCIACCESS_LIBS)
Reviewed-by: Eric Anholt
pgpmeAspP1ECn.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dma-buf: don't hold the mutex around map/unmap calls
On Thu, Mar 1, 2012 at 9:35 AM, Daniel Vetter wrote:
> The mutex protects the attachment list and hence needs to be held
> around the callbakc to the exporters (optional) attach/detach
> functions.
>
> Holding the mutex around the map/unmap calls doesn't protect any
> dma_buf state. Exporters need to properly protect any of their own
> state anyway (to protect against calls from their own interfaces).
> So this only makes the locking messier (and lockdep easier to anger).
>
> Therefore let's just drop this.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> drivers/base/dma-buf.c | 4
> include/linux/dma-buf.h | 2 +-
> 2 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index e38ad24..1b11192 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -258,10 +258,8 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> if (WARN_ON(!attach || !attach->dmabuf || !attach->dmabuf->ops))
> return ERR_PTR(-EINVAL);
>
> - mutex_lock(&attach->dmabuf->lock);
> if (attach->dmabuf->ops->map_dma_buf)
> sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> - mutex_unlock(&attach->dmabuf->lock);
>
> return sg_table;
> }
> @@ -282,10 +280,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> || !attach->dmabuf->ops))
> return;
>
> - mutex_lock(&attach->dmabuf->lock);
> if (attach->dmabuf->ops->unmap_dma_buf)
> attach->dmabuf->ops->unmap_dma_buf(attach, sg_table);
> - mutex_unlock(&attach->dmabuf->lock);
>
> }
> EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index f8ac076..f7ad2ca 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -86,7 +86,7 @@ struct dma_buf {
> struct file *file;
> struct list_head attachments;
> const struct dma_buf_ops *ops;
> - /* mutex to serialize list manipulation and other ops */
> + /* mutex to serialize list manipulation and attach/detach */
> struct mutex lock;
> void *priv;
> };
> --
> 1.7.7.5
>
> ___
> 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
Re: [PATCH 2/3] dma-buf: add support for kernel cpu access
On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do everything required so that
> the kmap calls can succeed (like swapin/backing storage allocation,
> flushing, ...).
>
> More in-depth explanations will follow in the follow-up documentation
> patch.
>
> Changes in v2:
>
> - Clear up begin_cpu_access confusion noticed by Sumit Semwal.
> - Don't automatically fallback from the _atomic variants to the
> non-atomic variants. The _atomic callbacks are not allowed to
> sleep, so we want exporters to make this decision explicit. The
> function signatures are explicit, so simpler exporters can still
> use the same function for both.
> - Make the unmap functions optional. Simpler exporters with permanent
> mappings don't need to do anything at unmap time.
>
> Signed-Off-by: Daniel Vetter
> ---
> drivers/base/dma-buf.c | 120
> +++
> include/linux/dma-buf.h | 60 +++
> 2 files changed, 180 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 1b11192..bf54b89 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -285,3 +285,123 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
>
> }
> EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> +
> +
> +/**
> + * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from
> the
> + * cpu in the kernel context. Calls begin_cpu_access to allow
> exporter-specific
> + * preparations. Coherency is only guaranteed in the specified range for the
> + * specified access direction.
> + * @dma_buf: [in] buffer to prepare cpu access for.
> + * @start: [in] start of range for cpu access.
> + * @len: [in] length of range for cpu access.
> + * @direction: [in] length of range for cpu access.
> + *
> + * Can return negative error values, returns 0 on success.
> + */
> +int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t
> len,
> + enum dma_data_direction direction)
> +{
> + int ret = 0;
> +
> + if (WARN_ON(!dmabuf || !dmabuf->ops))
> + return EINVAL;
> +
> + if (dmabuf->ops->begin_cpu_access)
> + ret = dmabuf->ops->begin_cpu_access(dmabuf, start, len,
> direction);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
> +
> +/**
> + * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the
> + * cpu in the kernel context. Calls end_cpu_access to allow exporter-specific
> + * actions. Coherency is only guaranteed in the specified range for the
> + * specified access direction.
> + * @dma_buf: [in] buffer to complete cpu access for.
> + * @start: [in] start of range for cpu access.
> + * @len: [in] length of range for cpu access.
> + * @direction: [in] length of range for cpu access.
> + *
> + * This call must always succeed.
> + */
> +void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
> + enum dma_data_direction direction)
> +{
> + WARN_ON(!dmabuf || !dmabuf->ops);
> +
> + if (dmabuf->ops->end_cpu_access)
> + dmabuf->ops->end_cpu_access(dmabuf, start, len, direction);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
> +
> +/**
> + * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address
> + * space. The same restrictions as for kmap_atomic and friends apply.
> + * @dma_buf: [in] buffer to map page from.
> + * @page_num: [in] page in PAGE_SIZE units to map.
> + *
> + * This call must always succeed, any necessary preparations that might fail
> + * need to be done in begin_cpu_access.
> + */
> +void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
> +{
> + WARN_ON(!dmabuf || !dmabuf->ops);
> +
> + return dmabuf->ops->kmap_atomic(dmabuf, page_num);
Perhaps we should check somewhere for required dmabuf ops fxns (like
kmap_atomic here), rather than just calling unconditionally what might
be a null ptr. At least put it in the WARN_ON(), but it might be
nicer to catch a missing required fxns at export time, rather than
waiting for an importer to try and call it. Less likely that way, for
newly added required functions go unnoticed.
(same comment applies below for the non-atomic variant.. and possibly
some other existing dmabuf ops)
BR,
-R
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
> +
> +/**
> + * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
> + * @dma_buf: [in] buffer to unmap page from.
> + * @page_num: [in] page in PAGE_SIZE units to unmap.
> + * @vaddr: [in] kernel space pointer obtained from
> dma_buf_km
Re: [PATCH 3/3] dma_buf: Add documentation for the new cpu access support
minor comments from the typo-police.. On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter wrote: > Signed-off-by: Daniel Vetter > --- > Documentation/dma-buf-sharing.txt | 102 +++- > 1 files changed, 99 insertions(+), 3 deletions(-) > > diff --git a/Documentation/dma-buf-sharing.txt > b/Documentation/dma-buf-sharing.txt > index 225f96d..f12542b 100644 > --- a/Documentation/dma-buf-sharing.txt > +++ b/Documentation/dma-buf-sharing.txt > @@ -32,8 +32,12 @@ The buffer-user > *IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details] > For this first version, A buffer shared using the dma_buf sharing API: > - *may* be exported to user space using "mmap" *ONLY* by exporter, outside of > - this framework. > -- may be used *ONLY* by importers that do not need CPU access to the buffer. > + this framework. > +- with this new iteration of the dma-buf api cpu access from the kernel has > been > + enable, see below for the details. > + > +dma-buf operations for device dma only > +-- > > The dma_buf buffer sharing API usage contains the following steps: > > @@ -219,7 +223,99 @@ NOTES: > If the exporter chooses not to allow an attach() operation once a > map_dma_buf() API has been called, it simply returns an error. > > -Miscellaneous notes: > +Kernel cpu access to a dma-buf buffer object > + > + > +The motivation to allow cpu access from the kernel to a dma-buf object from > the > +importers side are: > +- fallback operations, e.g. if the devices is connected to a usb bus and the > + kernel needs to shuffle the data around first before sending it away. > +- full transperancy for existing users on the importer side, i.e. userspace s/transperancy/transparency/ > + should not notice the difference between a normal object from that > subsystem > + and an imported one backed by a dma-buf. This is really important for drm > + opengl drivers that expect to still use all the existing upload/download > + paths. > + > +Access to a dma_buf from the kernel context involves three steps: > + > +1. Prepare access, which invalidate any necessary caches and make the object > + available for cpu access. > +2. Access the object page-by-page with the dma_buf map apis > +3. Finish access, which will flush any necessary cpu caches and free reserved > + resources. > + > +1. Prepare acces > + s/acces/access/ > + Before an importer can acces a dma_buf object with the cpu from the kernel s/acces/access/ > + context, it needs to notice the exporter of the access that is about to s/notice/notify/ (I assume?) > + happen. > + > + Interface: > + int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > + size_t start, size_t len, > + enum dma_data_direction direction) > + > + This allows the exporter to ensure that the memory is actually available > for > + cpu access - the exporter might need to allocate or swap-in and pin the > + backing storage. The exporter also needs to ensure that cpu access is > + coherent for the given range and access direction. The range and access > + direction can be used by the exporter to optimize the cache flushing, i.e. > + access outside of the range or with a different direction (read instead of > + write) might return stale or even bogus data (e.g. when the exporter > needs to > + copy the data to temporaray storage). s/temporaray/temporary/ > + > + This step might fail, e.g. in oom conditions. > + > +2. Accessing the buffer > + > + To support dma_buf objects residing in highmem cpu access is page-based > using > + an api similar to kmap. Accessing a dma_buf is done in aligned chunks of > + PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which > returns > + a pointer in kernel virtual address space. Afterwards the chunk needs to > be > + unmapped again. There is no limit on how often a given chunk can be mapped > + and unmmapped, i.e. the importer does not need to call begin_cpu_access > again s/unmmapped/unmapped/ > + before mapping the same chunk again. > + > + Interfaces: > + void *dma_buf_kmap(struct dma_buf *, unsigned long); > + void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); > + > + There are also atomic variants of these interfaces. Like for kmap they > + facilitate non-blocking fast-paths. Neither the importer nor the exporter > (in > + the callback) is allowed to block when using these. > + > + Interfaces: > + void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); > + void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); > + > + For importers all the restrictions of using kmap apply, like the limited > + supply of kmap_atomic slots. Hence an importer shall only hold onto at > most 2 > + atomic dma_buf kmaps at the same time (in any given proces
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 Andy Furniss changed: What|Removed |Added Attachment #57412|0 |1 is obsolete|| --- Comment #5 from Andy Furniss 2012-03-02 14:34:23 PST --- Comment on attachment 57412 --> https://bugs.freedesktop.org/attachment.cgi?id=57412 vdpau decode gdb bt full The decode crash is fixed now, probably by one of the u_blitter changes (well it worked with those as head). It still renders 95% noise though. -- 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: [Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter wrote: > Big differences to other contenders in the field (like ion) is > that this also supports highmem, so we have to split up the cpu > access from the kernel side into a prepare and a kmap step. > > Prepare is allowed to fail and should do everything required so that > the kmap calls can succeed (like swapin/backing storage allocation, > flushing, ...). > > More in-depth explanations will follow in the follow-up documentation > patch. > > Changes in v2: > > - Clear up begin_cpu_access confusion noticed by Sumit Semwal. > - Don't automatically fallback from the _atomic variants to the > non-atomic variants. The _atomic callbacks are not allowed to > sleep, so we want exporters to make this decision explicit. The > function signatures are explicit, so simpler exporters can still > use the same function for both. > - Make the unmap functions optional. Simpler exporters with permanent > mappings don't need to do anything at unmap time. Are we going to have to have a dma_buf->ops->begin_async_access(&me, dir) variant for coherency control of rendering with an imported dma_buf? There is also no concurrency control here between multiple importers doing simultaneous begin_cpu_access(). I presume that is going to be a common function across all exporters so the midlayer might offer a semaphore as a library function and then the dma_buf->ops->begin_cpu_access() becomes mandatory as at a minimum it has to point to the default implementation. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access
On Fri, Mar 2, 2012 at 4:38 PM, Chris Wilson wrote: > On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter > wrote: >> Big differences to other contenders in the field (like ion) is >> that this also supports highmem, so we have to split up the cpu >> access from the kernel side into a prepare and a kmap step. >> >> Prepare is allowed to fail and should do everything required so that >> the kmap calls can succeed (like swapin/backing storage allocation, >> flushing, ...). >> >> More in-depth explanations will follow in the follow-up documentation >> patch. >> >> Changes in v2: >> >> - Clear up begin_cpu_access confusion noticed by Sumit Semwal. >> - Don't automatically fallback from the _atomic variants to the >> non-atomic variants. The _atomic callbacks are not allowed to >> sleep, so we want exporters to make this decision explicit. The >> function signatures are explicit, so simpler exporters can still >> use the same function for both. >> - Make the unmap functions optional. Simpler exporters with permanent >> mappings don't need to do anything at unmap time. > > Are we going to have to have a dma_buf->ops->begin_async_access(&me, dir) > variant for coherency control of rendering with an imported dma_buf? > There is also no concurrency control here between multiple importers > doing simultaneous begin_cpu_access(). I presume that is going to be a > common function across all exporters so the midlayer might offer a > semaphore as a library function and then the > dma_buf->ops->begin_cpu_access() becomes mandatory as at a minimum it > has to point to the default implementation. Initially the expectation was that userspace would not pass a buffer to multiple subsystems for writing (or that if it did, it would get the undefined results that one could expect).. so dealing w/ synchronization was punted. I expect, though, that one of the next steps is some sort of sync-object mechanism to supplement dmabuf BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45558] cannot render on a drawable of size equal the max framebuffer size
https://bugs.freedesktop.org/show_bug.cgi?id=45558 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Eric Anholt 2012-03-02 17:31:52 PST --- The BLT ranges are exclusive -- it's only the drawrect that has that oddness. I pushed that part of the patch, and it does almost entirely fix gnome-shell rendering. commit 7d13a6e64bf88566875a8f68e0aac9b937e30feb Author: Alban Browaeys Date: Thu Feb 2 19:20:22 2012 +0100 dri/i915: Fix off-by-one in i830 clip region size. The hardware, like i915, uses an inclusive bounds on min and max for the drawing rectangle, but we were providing a number for exclusive. The number of bits used by the hardware only covers this value going up to the maximum size, so when we programmed 2048 as the maximum inclusive X, it saw a maximum X of 0 and clipped all rendering. This caused rendering failures in gnome-shell. Fixes piglit fbo-maxsize. v2: dropped changes to the blitter, which does use an exclusive x2, y2. [change by anholt] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45558 Reviewed-by: Eric Anholt NOTE: This is a candidate for release branches. -- 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 38873] [855gm] gnome-shell misrendered
https://bugs.freedesktop.org/show_bug.cgi?id=38873 --- Comment #2 from Eric Anholt 2012-03-02 17:32:51 PST --- The first issue is fixed: commit 7d13a6e64bf88566875a8f68e0aac9b937e30feb Author: Alban Browaeys Date: Thu Feb 2 19:20:22 2012 +0100 dri/i915: Fix off-by-one in i830 clip region size. The hardware, like i915, uses an inclusive bounds on min and max for the drawing rectangle, but we were providing a number for exclusive. The number of bits used by the hardware only covers this value going up to the maximum size, so when we programmed 2048 as the maximum inclusive X, it saw a maximum X of 0 and clipped all rendering. This caused rendering failures in gnome-shell. Fixes piglit fbo-maxsize. v2: dropped changes to the blitter, which does use an exclusive x2, y2. [change by anholt] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45558 Reviewed-by: Eric Anholt NOTE: This is a candidate for release branches. don't know about the second. -- 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 4374] [855GM] Incorrect painting in crack-attack
https://bugs.freedesktop.org/show_bug.cgi?id=4374 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from Eric Anholt 2012-03-02 17:44:20 PST --- I seem to recall testing this on my 865 about a year ago and seeing the bug, but today the bug doesn't show up any more. So I'm tentatively going to mark this fixed, though I don't have a commit identified that fixed it :( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. 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 41913] [865] intel/intel_bufmgr_gem.c:1361: do_bo_emit_reloc: Assertion `offset <= bo->size - 4' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=41913 Eric Anholt changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||FIXED --- Comment #3 from Eric Anholt 2012-03-02 17:51:05 PST --- 3 links to bug reports elsewhere instead of putting the info in the bug report, and none of them even have a backtrace. Sigh. Anyway, this got fixed thanks to another bug report: commit 024ece7523f1735d2fca0067c0a3bdcf53fde8f9 Author: Kurt Roeckx Date: Fri Mar 2 15:34:45 2012 -0800 i915: Compute maximum number of verts using the actual batchbuffer size. We were looking at the size of batch.map for how big the batchbuffer was, but on 865 we just use a single-page batchbuffer due to hardware limits. v2: Removed check for sizeof map < bo->size, since that's always false. [change by anholt] NOTE: This is a candidate for release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41495 33b07893e92dcee495908c549be872887096c894 Author: Chris Wilson Date: Wed Nov 9 22:21:16 2011 + i830: Compute initial number of vertices from remaining batch space In order to prevent an overflow of the batch buffer when emitting triangles, we need to limit the initial primitive to fit within the current batch. To do we need to measure the remaining space and thence compute the maximum number of vertices that fit into that space. Reported-by: Kurt Roeckx Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41495 Signed-off-by: Chris Wilson Reviewed-by: Eric Anholt NOTE: This is a candidate for release branches. -- 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 46213] [865G] Low framerate with glxgears and general low performance
https://bugs.freedesktop.org/show_bug.cgi?id=46213 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #2 from Eric Anholt 2012-03-02 17:52:23 PST --- The numbers in this report talking about glxgears just reflect surprise at vsync. It is an intentional choice to avoid tearing, and not something we will change by default. If you're excited about seeing tearing in your apps and rendering frames you'll never see, you can disable vsync in driconf. If you can come up with a specific application that is using CPU where it didn't before and a sysprof profile showing that CPU usage (and probably INTEL_DEBUG=fallback output explaining the software fallback), then we might be able to do something. -- 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 45281] [8xx] Assertion failure whilst running dangerball
https://bugs.freedesktop.org/show_bug.cgi?id=45281 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Eric Anholt 2012-03-02 17:53:41 PST --- Looks like this also got fixed by the i865 vert-counting series. At least, 8.0 fails and master works now. -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #7 from samit vats 2012-03-01 22:01:33 PST --- (In reply to comment #6) > I am reproducing the issue with higher versions of xorg-server.Once confirm > the > issue is reproduced with higer versions, I will attach the gdb backtrace. The issue is not reproduced with xorg-server-1.11.4. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 samit vats changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH v2] i915: Add option to bypass vbt table.
Hi, On Thursday, March 01, 2012 23:23:43 Daniel Vetter wrote: > Ah, that explains things. I've added this to the commit message and queued > it for -next, thanks. May be the next time I should also include the reason beyond the technical details in the commit message. Thanks for queuing up! Mathias
[Bug 46866] New: Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 Bug #: 46866 Summary: Piglit:Multiple failures observed while running quick-driver.tests Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: hysvats at gmail.com Driver Stack Details: = 1)Kernel-3.0.0-12-generice-pae 2)drm-2.4.31 3)Mesa-8.1-devel (git-897af1d) 4)Xorg-server-1.11.4 5)xf86-video-ati- master System Environment: === Asic : EG CedarPro O.S. : Ubuntu-11.10 (32 bit) Processor: AMD Athlon(tm) 64 X2 @ 1 GHz Memory : 2 GB Steps to Reproduce: === 1) Install piglit from git clone git://anongit.freedesktop.org/git/piglit 2) #./piglit-run.py tests/quick-driver.tests results/quick-driver.results #./piglit-summary-html.py summary/quick-driver results/quick-driver.results Observation : Multiple failures observed while running quick-driver.tests === -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 --- Comment #1 from samit vats 2012-03-02 00:42:41 PST --- Created attachment 57898 --> https://bugs.freedesktop.org/attachment.cgi?id=57898 piglit-log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 --- Comment #2 from samit vats 2012-03-02 00:43:15 PST --- Created attachment 57899 --> https://bugs.freedesktop.org/attachment.cgi?id=57899 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 --- Comment #3 from samit vats 2012-03-02 00:43:38 PST --- Created attachment 57900 --> https://bugs.freedesktop.org/attachment.cgi?id=57900 Xorg.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 46866] Piglit:Multiple failures observed while running quick-driver.tests
https://bugs.freedesktop.org/show_bug.cgi?id=46866 samit vats changed: What|Removed |Added Priority|medium |high -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 22195] app crashed to desktop with Radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=22195 dre changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
libdrm and platform devices?
Hi All, I have a drm device on the platform bus, similar to the exynos driver. right now libdrm (at least the tests included in libdrm) refuses to open the device because i915, nouveau, radeon and vmwgfx is all they know about. Looking at the libdrm code it is not obvious how to fix this (except for adding "exynos", "mydevice", "myotherdevice" to the module table which seems awkward and not very futureproof). Any hints or thoughts how to proceed here? Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
libdrm and platform devices?
> > I have a drm device on the platform bus, similar to the exynos driver. > right now libdrm (at least the tests included in libdrm) refuses to open > the device because i915, nouveau, radeon and vmwgfx is all they know > about. Looking at the libdrm code it is not obvious how to fix this > (except for adding "exynos", "mydevice", "myotherdevice" to the module > table which seems awkward and not very futureproof). Any hints or > thoughts how to proceed here? libdrm tests aren't really used that much, and it might be easier to just not care. people just hack on them for their platforms and sometimes someone pushes one in. You more likely want specific tests for your platform like intel-gpu-tools. Dave. > > Thanks > ?Sascha > > > -- > Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? | > Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?| > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 ? ?| > Amtsgericht Hildesheim, HRA 2686 ? ? ? ? ? | Fax: ? +49-5121-206917- | > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
libdrm and platform devices?
On Fri, Mar 02, 2012 at 12:02:21PM +, Dave Airlie wrote:
> >
> > I have a drm device on the platform bus, similar to the exynos driver.
> > right now libdrm (at least the tests included in libdrm) refuses to open
> > the device because i915, nouveau, radeon and vmwgfx is all they know
> > about. Looking at the libdrm code it is not obvious how to fix this
> > (except for adding "exynos", "mydevice", "myotherdevice" to the module
> > table which seems awkward and not very futureproof). Any hints or
> > thoughts how to proceed here?
>
> libdrm tests aren't really used that much, and it might be easier to
> just not care.
>
> people just hack on them for their platforms and sometimes someone
> pushes one in.
Ok, I can keep a local hack. What are your plans for the
xf86-modesetting driver? It works nicely after I commented out some
pci specific things and replaced drmOpen(NULL, BusID) with
open("/dev/dri/card0", O_RDWR). Do you plan to continue on the driver
and would accept patches for it?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
libdrm and platform devices?
On Fri, Mar 2, 2012 at 1:06 PM, Sascha Hauer wrote:
> On Fri, Mar 02, 2012 at 12:02:21PM +, Dave Airlie wrote:
>> >
>> > I have a drm device on the platform bus, similar to the exynos driver.
>> > right now libdrm (at least the tests included in libdrm) refuses to open
>> > the device because i915, nouveau, radeon and vmwgfx is all they know
>> > about. Looking at the libdrm code it is not obvious how to fix this
>> > (except for adding "exynos", "mydevice", "myotherdevice" to the module
>> > table which seems awkward and not very futureproof). Any hints or
>> > thoughts how to proceed here?
>>
>> libdrm tests aren't really used that much, and it might be easier to
>> just not care.
>>
>> people just hack on them for their platforms and sometimes someone
>> pushes one in.
>
> Ok, I can keep a local hack. What are your plans for the
> xf86-modesetting driver? It works nicely after I commented out some
> pci specific things and replaced drmOpen(NULL, BusID) with
> open("/dev/dri/card0", O_RDWR). Do you plan to continue on the driver
> and would accept patches for it?
might be why I added busid to the usb, my memory of why is hazy.
you should have been able to specify /dev/dri/card0 in the xorg.conf
Option "kmsdev"
and yes I'll continue working on it, I have to hook it in as a linux
fallback driver in the X server.
Dave.
[Bug 42727] radeon KMS with CRT TV
https://bugzilla.kernel.org/show_bug.cgi?id=42727 --- Comment #30 from Egor Y. Egorov 2012-03-02 13:34:22 --- Created an attachment (id=72515) --> (https://bugzilla.kernel.org/attachment.cgi?id=72515) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 42727] radeon KMS with CRT TV
https://bugzilla.kernel.org/show_bug.cgi?id=42727 --- Comment #31 from Egor Y. Egorov 2012-03-02 13:35:40 --- I run # ./radeonreg regset 0x04f4 0x8062 OLD: 0x04f4 (04f4) 0x8062 (-2147483550) NEW: 0x04f4 (04f4) 0x8062 (-2147483550) EGOROV radeontool # ./radeonreg regset 0x5e00 0x0001 OLD: 0x5e00 (5e00) 0x0001 (1) NEW: 0x5e00 (5e00) 0x0001 (1) EGOROV radeontool # ./radeonreg regset 0x6810 0x OLD: 0x6810 (6810) 0x (0) NEW: 0x6810 (6810) 0x (0) EGOROV radeontool # ./radeonreg regset 0x6830 0x OLD: 0x6830 (6830) 0x (0) NEW: 0x6830 (6830) 0x (0) EGOROV radeontool # ./radeonreg regset 0x6880 0x00010101 OLD: 0x6880 (6880) 0x00010101 (65793) NEW: 0x6880 (6880) 0x00010101 (65793) EGOROV radeontool # ./radeonreg regset 0x6884 0x OLD: 0x6884 (6884) 0x (0) NEW: 0x6884 (6884) 0x (0) EGOROV radeontool # ./radeonreg regset 0x7a00 0x0001 OLD: 0x7a00 (7a00) 0x0001 (1) NEW: 0x7a00 (7a00) 0x0001 (1) EGOROV radeontool # but everything remains as before -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] Block: use a freezable workqueue for disk-event polling
On 02/17/2012 10:22 PM, Alan Stern wrote: > This patch (as1519) fixes a bug in the block layer's disk-events > polling. The polling is done by a work routine queued on the > system_nrt_wq workqueue. Since that workqueue isn't freezable, the > polling continues even in the middle of a system sleep transition. > > Obviously, polling a suspended drive for media changes and such isn't > a good thing to do; in the case of USB mass-storage devices it can > lead to real problems requiring device resets and even re-enumeration. > > The patch fixes things by creating a new system-wide, non-reentrant, > freezable workqueue and using it for disk-events polling. Thanks Alan, picked up. -- Jens Axboe
[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #31 from Harald Judt 2012-03-02 07:10:27 PST --- Using current git of kernel, xorg-server, xf86-video-ati and mesa, the screen still freezes every once in a while and dmesg shows these messages: radeon :01:00.0: offset 0x20 is in reserved area 0x80 radeon :01:00.0: offset 0x20 is in reserved area 0x80 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart: > Hello everybody, > > First of all, I would like to thank all the attendees for their > participation in the mini-summit that helped make the meeting a success. > > Here are my consolidated notes that cover both the Linaro Connect meeting > and the ELC meeting. They're also available at > http://www.ideasonboard.org/media/meetings/. > > > Kernel Display and Video API Consolidation mini-summit at ELC 2012 > -- > [...] > *** Display Panel Drivers *** > > Goal: Sharing display panel drivers between display controllers from > different vendors. > > Panels are connected to the display controller through a standard bus > with a control channel (DSI and eDP are two major such buses). Various > vendors have created proprietary interfaces for panel drivers: > > - TI on OMAP (drivers/video/omap2/displays). > - Samsung on Exynos (drivers/video/exynos). > - ST-Ericsson on MCDE > (http://www.igloocommunity.org/gitweb/?p=kernel/igloo- > kernel.git;a=tree;f=drivers/video/mcde) > - Renesas is working on a similar interface for SH Mobile. > > HDMI-on-DSI transmitters, while not panels per-se, can be supported > through the same API. > > A Low level Linux Display Framework (https://lkml.org/lkml/2011/9/15/107) > has been proposed and overlaps with this topic. > > For DSI, a possible abstraction level would be a DCS (Display Command > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be > implemented as DCS drivers. > > Action points: > - Marcus to work on a proposal for DCS-based panels (with Tomi Valkeinen > and Morimoto-san). It would also be interesting to see something similar for MIPI-DBI (type B for me) [aka rfbi on omap], as most epaper displays use this to transmit data and currently use half-baked interfaces. So hopefully I'll be able to follow the discussion and can then try to convert your findings to the dbi case. Heiko
Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
On 2 March 2012 15:23, Heiko St?bner wrote:
> Am Freitag, 17. Februar 2012, 00:25:51 schrieb Laurent Pinchart:
> [...]
> > For DSI, a possible abstraction level would be a DCS (Display Command
> > Set) bus. Panels and/or HDMI-on-DSI transmitter drivers would be
> > implemented as DCS drivers.
> >
> > Action points:
> > - Marcus to work on a proposal for DCS-based panels (with Tomi
> Valkeinen
> > and Morimoto-san).
>
> It would also be interesting to see something similar for MIPI-DBI (type B
> for
> me) [aka rfbi on omap], as most epaper displays use this to transmit data
> and
> currently use half-baked interfaces.
>
> So hopefully I'll be able to follow the discussion and can then try to
> convert
> your findings to the dbi case.
>
> Heiko
>
The idea is to abstract the DSI/DBI-2 type of transport and focus on the
DCS command set level. The driver should be able to select between DBI and
DSI by providing some "struct dcs_device { ifc = DSI/DBI2, ... }" data to
the DCS bus.
Something like a stripped version of
www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=include/video/mcde.h#l113,
but for DBI/DSI only.
/BR
/Marcus
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120302/67215355/attachment.html>
[PATCH libdrm] Don't require pciaccess if Intel is disabled
On Thu, 1 Mar 2012 12:21:17 -0500, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> configure.ac | 10 ++
> 1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 97bbcb7..71a596c 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -51,10 +51,6 @@ PKG_CHECK_MODULES(PTHREADSTUBS, pthread-stubs)
> AC_SUBST(PTHREADSTUBS_CFLAGS)
> AC_SUBST(PTHREADSTUBS_LIBS)
>
> -PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> -AC_SUBST(PCIACCESS_CFLAGS)
> -AC_SUBST(PCIACCESS_LIBS)
> -
> pkgconfigdir=${libdir}/pkgconfig
> AC_SUBST(pkgconfigdir)
> AC_ARG_ENABLE([udev],
> @@ -261,6 +257,12 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno"; then
> fi
> fi
>
> +if test "x$INTEL" != "xno"; then
> + PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
> +fi
> +AC_SUBST(PCIACCESS_CFLAGS)
> +AC_SUBST(PCIACCESS_LIBS)
Reviewed-by: Eric Anholt
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120302/a689973a/attachment.pgp>
[PATCH 1/3] dma-buf: don't hold the mutex around map/unmap calls
On Thu, Mar 1, 2012 at 9:35 AM, Daniel Vetter wrote:
> The mutex protects the attachment list and hence needs to be held
> around the callbakc to the exporters (optional) attach/detach
> functions.
>
> Holding the mutex around the map/unmap calls doesn't protect any
> dma_buf state. Exporters need to properly protect any of their own
> state anyway (to protect against calls from their own interfaces).
> So this only makes the locking messier (and lockdep easier to anger).
>
> Therefore let's just drop this.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> ?drivers/base/dma-buf.c ?| ? ?4
> ?include/linux/dma-buf.h | ? ?2 +-
> ?2 files changed, 1 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index e38ad24..1b11192 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -258,10 +258,8 @@ struct sg_table *dma_buf_map_attachment(struct
> dma_buf_attachment *attach,
> ? ? ? ?if (WARN_ON(!attach || !attach->dmabuf || !attach->dmabuf->ops))
> ? ? ? ? ? ? ? ?return ERR_PTR(-EINVAL);
>
> - ? ? ? mutex_lock(&attach->dmabuf->lock);
> ? ? ? ?if (attach->dmabuf->ops->map_dma_buf)
> ? ? ? ? ? ? ? ?sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> - ? ? ? mutex_unlock(&attach->dmabuf->lock);
>
> ? ? ? ?return sg_table;
> ?}
> @@ -282,10 +280,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?|| !attach->dmabuf->ops))
> ? ? ? ? ? ? ? ?return;
>
> - ? ? ? mutex_lock(&attach->dmabuf->lock);
> ? ? ? ?if (attach->dmabuf->ops->unmap_dma_buf)
> ? ? ? ? ? ? ? ?attach->dmabuf->ops->unmap_dma_buf(attach, sg_table);
> - ? ? ? mutex_unlock(&attach->dmabuf->lock);
>
> ?}
> ?EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index f8ac076..f7ad2ca 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -86,7 +86,7 @@ struct dma_buf {
> ? ? ? ?struct file *file;
> ? ? ? ?struct list_head attachments;
> ? ? ? ?const struct dma_buf_ops *ops;
> - ? ? ? /* mutex to serialize list manipulation and other ops */
> + ? ? ? /* mutex to serialize list manipulation and attach/detach */
> ? ? ? ?struct mutex lock;
> ? ? ? ?void *priv;
> ?};
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dma-buf: add support for kernel cpu access
On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do everything required so that
> the kmap calls can succeed (like swapin/backing storage allocation,
> flushing, ...).
>
> More in-depth explanations will follow in the follow-up documentation
> patch.
>
> Changes in v2:
>
> - Clear up begin_cpu_access confusion noticed by Sumit Semwal.
> - Don't automatically fallback from the _atomic variants to the
> ?non-atomic variants. The _atomic callbacks are not allowed to
> ?sleep, so we want exporters to make this decision explicit. The
> ?function signatures are explicit, so simpler exporters can still
> ?use the same function for both.
> - Make the unmap functions optional. Simpler exporters with permanent
> ?mappings don't need to do anything at unmap time.
>
> Signed-Off-by: Daniel Vetter
> ---
> ?drivers/base/dma-buf.c ?| ?120
> +++
> ?include/linux/dma-buf.h | ? 60 +++
> ?2 files changed, 180 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 1b11192..bf54b89 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -285,3 +285,123 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment
> *attach,
>
> ?}
> ?EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> +
> +
> +/**
> + * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from
> the
> + * cpu in the kernel context. Calls begin_cpu_access to allow
> exporter-specific
> + * preparations. Coherency is only guaranteed in the specified range for the
> + * specified access direction.
> + * @dma_buf: ? [in] ? ?buffer to prepare cpu access for.
> + * @start: ? ? [in] ? ?start of range for cpu access.
> + * @len: ? ? ? [in] ? ?length of range for cpu access.
> + * @direction: [in] ? ?length of range for cpu access.
> + *
> + * Can return negative error values, returns 0 on success.
> + */
> +int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t
> len,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?enum dma_data_direction direction)
> +{
> + ? ? ? int ret = 0;
> +
> + ? ? ? if (WARN_ON(!dmabuf || !dmabuf->ops))
> + ? ? ? ? ? ? ? return EINVAL;
> +
> + ? ? ? if (dmabuf->ops->begin_cpu_access)
> + ? ? ? ? ? ? ? ret = dmabuf->ops->begin_cpu_access(dmabuf, start, len,
> direction);
> +
> + ? ? ? return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
> +
> +/**
> + * dma_buf_end_cpu_access - Must be called after accessing a dma_buf from the
> + * cpu in the kernel context. Calls end_cpu_access to allow exporter-specific
> + * actions. Coherency is only guaranteed in the specified range for the
> + * specified access direction.
> + * @dma_buf: ? [in] ? ?buffer to complete cpu access for.
> + * @start: ? ? [in] ? ?start of range for cpu access.
> + * @len: ? ? ? [in] ? ?length of range for cpu access.
> + * @direction: [in] ? ?length of range for cpu access.
> + *
> + * This call must always succeed.
> + */
> +void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? enum dma_data_direction direction)
> +{
> + ? ? ? WARN_ON(!dmabuf || !dmabuf->ops);
> +
> + ? ? ? if (dmabuf->ops->end_cpu_access)
> + ? ? ? ? ? ? ? dmabuf->ops->end_cpu_access(dmabuf, start, len, direction);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
> +
> +/**
> + * dma_buf_kmap_atomic - Map a page of the buffer object into kernel address
> + * space. The same restrictions as for kmap_atomic and friends apply.
> + * @dma_buf: ? [in] ? ?buffer to map page from.
> + * @page_num: ?[in] ? ?page in PAGE_SIZE units to map.
> + *
> + * This call must always succeed, any necessary preparations that might fail
> + * need to be done in begin_cpu_access.
> + */
> +void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
> +{
> + ? ? ? WARN_ON(!dmabuf || !dmabuf->ops);
> +
> + ? ? ? return dmabuf->ops->kmap_atomic(dmabuf, page_num);
Perhaps we should check somewhere for required dmabuf ops fxns (like
kmap_atomic here), rather than just calling unconditionally what might
be a null ptr. At least put it in the WARN_ON(), but it might be
nicer to catch a missing required fxns at export time, rather than
waiting for an importer to try and call it. Less likely that way, for
newly added required functions go unnoticed.
(same comment applies below for the non-atomic variant.. and possibly
some other existing dmabuf ops)
BR,
-R
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
> +
> +/**
> + * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
> + * @dma_buf: ? [in] ? ?buffer to unmap page from.
> + * @page_num: ?[in] ? ?page in PAGE_SIZE units to unmap.
> + * @vaddr: ? ? [in] ? ?kernel space pointer obtained from
> dma_buf_km
[PATCH 3/3] dma_buf: Add documentation for the new cpu access support
minor comments from the typo-police.. On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter wrote: > Signed-off-by: Daniel Vetter > --- > ?Documentation/dma-buf-sharing.txt | ?102 +++- > ?1 files changed, 99 insertions(+), 3 deletions(-) > > diff --git a/Documentation/dma-buf-sharing.txt > b/Documentation/dma-buf-sharing.txt > index 225f96d..f12542b 100644 > --- a/Documentation/dma-buf-sharing.txt > +++ b/Documentation/dma-buf-sharing.txt > @@ -32,8 +32,12 @@ The buffer-user > ?*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details] > ?For this first version, A buffer shared using the dma_buf sharing API: > ?- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of > - ? this framework. > -- may be used *ONLY* by importers that do not need CPU access to the buffer. > + ?this framework. > +- with this new iteration of the dma-buf api cpu access from the kernel has > been > + ?enable, see below for the details. > + > +dma-buf operations for device dma only > +-- > > ?The dma_buf buffer sharing API usage contains the following steps: > > @@ -219,7 +223,99 @@ NOTES: > ? ?If the exporter chooses not to allow an attach() operation once a > ? ?map_dma_buf() API has been called, it simply returns an error. > > -Miscellaneous notes: > +Kernel cpu access to a dma-buf buffer object > + > + > +The motivation to allow cpu access from the kernel to a dma-buf object from > the > +importers side are: > +- fallback operations, e.g. if the devices is connected to a usb bus and the > + ?kernel needs to shuffle the data around first before sending it away. > +- full transperancy for existing users on the importer side, i.e. userspace s/transperancy/transparency/ > + ?should not notice the difference between a normal object from that > subsystem > + ?and an imported one backed by a dma-buf. This is really important for drm > + ?opengl drivers that expect to still use all the existing upload/download > + ?paths. > + > +Access to a dma_buf from the kernel context involves three steps: > + > +1. Prepare access, which invalidate any necessary caches and make the object > + ? available for cpu access. > +2. Access the object page-by-page with the dma_buf map apis > +3. Finish access, which will flush any necessary cpu caches and free reserved > + ? resources. > + > +1. Prepare acces > + s/acces/access/ > + ? Before an importer can acces a dma_buf object with the cpu from the kernel s/acces/access/ > + ? context, it needs to notice the exporter of the access that is about to s/notice/notify/ (I assume?) > + ? happen. > + > + ? Interface: > + ? ? ?int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?size_t start, size_t len, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?enum dma_data_direction direction) > + > + ? This allows the exporter to ensure that the memory is actually available > for > + ? cpu access - the exporter might need to allocate or swap-in and pin the > + ? backing storage. The exporter also needs to ensure that cpu access is > + ? coherent for the given range and access direction. The range and access > + ? direction can be used by the exporter to optimize the cache flushing, i.e. > + ? access outside of the range or with a different direction (read instead of > + ? write) might return stale or even bogus data (e.g. when the exporter > needs to > + ? copy the data to temporaray storage). s/temporaray/temporary/ > + > + ? This step might fail, e.g. in oom conditions. > + > +2. Accessing the buffer > + > + ? To support dma_buf objects residing in highmem cpu access is page-based > using > + ? an api similar to kmap. Accessing a dma_buf is done in aligned chunks of > + ? PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which > returns > + ? a pointer in kernel virtual address space. Afterwards the chunk needs to > be > + ? unmapped again. There is no limit on how often a given chunk can be mapped > + ? and unmmapped, i.e. the importer does not need to call begin_cpu_access > again s/unmmapped/unmapped/ > + ? before mapping the same chunk again. > + > + ? Interfaces: > + ? ? ?void *dma_buf_kmap(struct dma_buf *, unsigned long); > + ? ? ?void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); > + > + ? There are also atomic variants of these interfaces. Like for kmap they > + ? facilitate non-blocking fast-paths. Neither the importer nor the exporter > (in > + ? the callback) is allowed to block when using these. > + > + ? Interfaces: > + ? ? ?void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); > + ? ? ?void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); > + > + ? For importers all the restrictions of using kmap apply, like the limited > + ? supply of kmap_atomic slots. Hence an importer shall only hold onto at > most 2 > + ? atomic dma_buf kmaps at the same time (in any given proces
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 Andy Furniss changed: What|Removed |Added Attachment #57412|0 |1 is obsolete|| --- Comment #5 from Andy Furniss 2012-03-02 14:34:23 PST --- Comment on attachment 57412 --> https://bugs.freedesktop.org/attachment.cgi?id=57412 vdpau decode gdb bt full The decode crash is fixed now, probably by one of the u_blitter changes (well it worked with those as head). It still renders 95% noise though. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter wrote: > Big differences to other contenders in the field (like ion) is > that this also supports highmem, so we have to split up the cpu > access from the kernel side into a prepare and a kmap step. > > Prepare is allowed to fail and should do everything required so that > the kmap calls can succeed (like swapin/backing storage allocation, > flushing, ...). > > More in-depth explanations will follow in the follow-up documentation > patch. > > Changes in v2: > > - Clear up begin_cpu_access confusion noticed by Sumit Semwal. > - Don't automatically fallback from the _atomic variants to the > non-atomic variants. The _atomic callbacks are not allowed to > sleep, so we want exporters to make this decision explicit. The > function signatures are explicit, so simpler exporters can still > use the same function for both. > - Make the unmap functions optional. Simpler exporters with permanent > mappings don't need to do anything at unmap time. Are we going to have to have a dma_buf->ops->begin_async_access(&me, dir) variant for coherency control of rendering with an imported dma_buf? There is also no concurrency control here between multiple importers doing simultaneous begin_cpu_access(). I presume that is going to be a common function across all exporters so the midlayer might offer a semaphore as a library function and then the dma_buf->ops->begin_cpu_access() becomes mandatory as at a minimum it has to point to the default implementation. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Linaro-mm-sig] [PATCH 2/3] dma-buf: add support for kernel cpu access
On Fri, Mar 2, 2012 at 4:38 PM, Chris Wilson wrote: > On Thu, ?1 Mar 2012 16:36:00 +0100, Daniel Vetter > wrote: >> Big differences to other contenders in the field (like ion) is >> that this also supports highmem, so we have to split up the cpu >> access from the kernel side into a prepare and a kmap step. >> >> Prepare is allowed to fail and should do everything required so that >> the kmap calls can succeed (like swapin/backing storage allocation, >> flushing, ...). >> >> More in-depth explanations will follow in the follow-up documentation >> patch. >> >> Changes in v2: >> >> - Clear up begin_cpu_access confusion noticed by Sumit Semwal. >> - Don't automatically fallback from the _atomic variants to the >> ? non-atomic variants. The _atomic callbacks are not allowed to >> ? sleep, so we want exporters to make this decision explicit. The >> ? function signatures are explicit, so simpler exporters can still >> ? use the same function for both. >> - Make the unmap functions optional. Simpler exporters with permanent >> ? mappings don't need to do anything at unmap time. > > Are we going to have to have a dma_buf->ops->begin_async_access(&me, dir) > variant for coherency control of rendering with an imported dma_buf? > There is also no concurrency control here between multiple importers > doing simultaneous begin_cpu_access(). I presume that is going to be a > common function across all exporters so the midlayer might offer a > semaphore as a library function and then the > dma_buf->ops->begin_cpu_access() becomes mandatory as at a minimum it > has to point to the default implementation. Initially the expectation was that userspace would not pass a buffer to multiple subsystems for writing (or that if it did, it would get the undefined results that one could expect).. so dealing w/ synchronization was punted. I expect, though, that one of the next steps is some sort of sync-object mechanism to supplement dmabuf BR, -R > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html
