[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver
I sent a reply to the sourceforge addresses in the original emails,
but I didn't see it show up in the archives. Trying again with the
freedesktop addresses.
On Thu, Oct 31, 2013 at 04:13:15PM -0700, Keith Packard wrote:
> This hooks DRI3 support into the GLX layer, the DRI common layer and the Intel
> driver.
>
> Signed-off-by: Keith Packard
> ---
> configure.ac | 10 +-
> include/GL/internal/dri_interface.h | 158 +++
> src/glx/Makefile.am |2 +
> src/glx/dri3_common.c | 146 +++
> src/glx/dri3_glx.c| 1539
> +
> src/glx/dri3_priv.h | 128 ++
> src/glx/glxclient.h |2 +
> src/glx/glxext.c |6 +-
> src/mesa/drivers/dri/common/dri_util.c| 163 ++-
> src/mesa/drivers/dri/common/dri_util.h| 23 +
> src/mesa/drivers/dri/i915/intel_context.c | 109 +-
> src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 33 +
> src/mesa/drivers/dri/i915/intel_mipmap_tree.h |8 +
> src/mesa/drivers/dri/i965/brw_context.c | 110 +-
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 61 +
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h |8 +
> src/mesa/drivers/dri/i965/intel_screen.c | 107 +-
> 17 files changed, 2594 insertions(+), 19 deletions(-)
> create mode 100644 src/glx/dri3_common.c
> create mode 100644 src/glx/dri3_glx.c
> create mode 100644 src/glx/dri3_priv.h
>
> diff --git a/configure.ac b/configure.ac
> index f94c9b9..b6158d9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.33
> LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
> LIBDRM_FREEDRENO_REQUIRED=2.4.39
> DRI2PROTO_REQUIRED=2.6
> +DRI3PROTO_REQUIRED=1.0
> +LIBUDEV_REQUIRED=151
> GLPROTO_REQUIRED=1.4.14
> LIBDRM_XORG_REQUIRED=2.4.24
> LIBKMS_XORG_REQUIRED=1.0.0
> @@ -820,10 +822,12 @@ xyesno)
> fi
> PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
> +PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED])
> fi
>
> # find the DRI deps for libGL
> -dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2
> >= 1.8"
> +dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2
> >= 1.8 xcb-dri3 xcb-sync xshmfence"
>
> # add xf86vidmode if available
> PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes,
> HAVE_XF86VIDMODE=no)
> @@ -833,8 +837,8 @@ xyesno)
>
> PKG_CHECK_MODULES([DRIGL], [$dri_modules])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules"
> -X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> -GL_LIB_DEPS="$DRIGL_LIBS"
> +X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS"
> +GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS"
>
> # need DRM libs, $PTHREAD_LIBS, etc.
> GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 48993b9..b06ad8d 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,11 @@ typedef struct __DRIdri2LoaderExtensionRec
> __DRIdri2LoaderExtension;
> typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
> typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>
> +
> +typedef struct __DRIdri3BufferRec __DRIdri3Buffer;
> +typedef struct __DRIdri3ExtensionRec__DRIdri3Extension;
> +typedef struct __DRIdri3LoaderExtensionRec __DRIdri3LoaderExtension;
> +
> /*@}*/
>
>
> @@ -966,6 +971,159 @@ struct __DRIdri2ExtensionRec {
>
>
> /**
> + * DRI3 Loader extension.
> + */
> +
> +#define __DRI3_DRIVER_EXTENSIONS "__dri3DriverExtensions"
> +
> +enum __DRI3bufferType {
> + __DRI3_BUFFER_BACK = 0,
> + __DRI3_BUFFER_FRONT = 1
> +};
> +
> +struct __DRIdri3BufferRec {
> + unsigned int size;
> + unsigned int pitch;
> + unsigned int cpp;
> + unsigned int flags;
> + unsigned int width, height;
> + enum __DRI3bufferType buffer_type;
> + uint32_t pixmap;
> + uint32_t sync_fence;
> + int32_t *shm_fence;
> + void *driverPrivate;
> +};
My main concern with this patch is that I'd like to use __DRIimage for
the color buffers instead of this new __DRIdri3Buffer. __DRIimage is
an opaque structure which we introduced for EGLImage support. It
essentially wraps an intel_region, so it's similar to __DRI3buffer,
except it's all opaque. __DRIimage is essentially *the* color buffer
abstraction in the DRI driver interface now and we're already using it
for color buffers in GBM and Wayland.
The intel version of __DRIimage is defined in intel_regions.h. It's
[Bug 64475] Slow work and no brightness adjustment in Euro Track Simulator II game with HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64475 --- Comment #4 from florian.will at googlemail.com --- Just adding some more data, I hope it's not entirely useless for you: I experience this/a similar issue with HD 6870 and Kernel 3.11, with radeon.dpm and the "performance" CPU governor enabled. I get only ~10-15 FPS while catalyst renders the same scene at 40+ FPS (and probably even more in windows). Light reflection seems to be wrong which makes the scene look pretty dark compared to how catalyst renders it. The HUD mirrors are fine, while "in-game" mirrors are rendered incorrectly, as you can see from commiethebeastie's screenshot. If you're interested, I can add my screenshot. It's not as dark as the one posted already, but still looks incorrect. I really don't know a lot about graphics etc., but I could imagine that there is some trouble with compiling shaders.. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/73a35612/attachment.html>
[Bug 71138] flashlight bug in L4D2
https://bugs.freedesktop.org/show_bug.cgi?id=71138 --- Comment #3 from Vadim Girlin --- This looks like z-fighting issues. You might want to try disabling compiler backends via R600_DEBUG environment variable: R600_DEBUG=nollvm R600_DEBUG=nosb R600_DEBUG=nollvm,nosb -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/59d7a0ba/attachment.html>
[PATCH v3 06/32] drm/exynos: Pass exynos_drm_manager in manager ops instead of dev
On Friday 01 of November 2013 16:01:23 Sean Paul wrote:
> On Thu, Oct 31, 2013 at 8:19 PM, Tomasz Figa
wrote:
> > Hi Sean,
> >
> > On Tuesday 29 of October 2013 12:12:52 Sean Paul wrote:
[snip]
> >> -static void fimd_win_mode_set(struct device *dev,
> >> - struct exynos_drm_overlay *overlay)
> >> +static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
> >> + struct exynos_drm_overlay *overlay)
> >>
> >> {
> >>
> >> - struct fimd_context *ctx = get_fimd_context(dev);
> >> + struct fimd_context *ctx = mgr->ctx;
> >>
> >> struct fimd_win_data *win_data;
> >> int win;
> >> unsigned long offset;
> >>
> >> if (!overlay) {
> >>
> >> - dev_err(dev, "overlay is NULL\n");
> >> + DRM_ERROR("overlay is NULL\n");
> >
> > This change does not seem to be related to $subject.
>
> It is. fimd_win_mode_set does not take dev as an argument any longer,
> as such it's undefined.
Right, I have overlooked this.
> >> return;
> >>
> >> }
> >>
> >> @@ -231,9 +233,8 @@ static void fimd_win_mode_set(struct device *dev,
> >>
> >> overlay->fb_width, overlay->crtc_width);
> >>
> >> }
> >>
> >> -static void fimd_win_set_pixfmt(struct device *dev, unsigned int
> >> win)
> >> +static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned
> >> int
> >> win) {
> >
> > Again not really related to $subject. Maybe this should be done in a
> > preparatory patch preceeding this one? (+ same comment for several
> > identical changes below)
>
> I think it's directly related to the subject. We no longer pass dev as
> an argument, so that has indirect effects on other functions.
Fine.
> >> - struct fimd_context *ctx = get_fimd_context(dev);
> >>
> >> struct fimd_win_data *win_data = >win_data[win];
> >> unsigned long val;
> >
> > [snip]
> >
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c index aebcc0e..ca0a87f
> >> 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> >> @@ -129,11 +129,9 @@ static struct edid *drm_hdmi_get_edid(struct
> >> device *dev,
> >>
> >> return NULL;
> >>
> >> }
> >>
> >> -
> >> -static int drm_hdmi_check_mode(struct device *dev,
> >> +static int drm_hdmi_check_mode_ctx(struct drm_hdmi_context *ctx,
> >>
> >> struct drm_display_mode *mode)
> >>
> >> {
> >>
> >> - struct drm_hdmi_context *ctx = to_context(dev);
> >>
> >> int ret = 0;
> >>
> >> /*
> >>
> >> @@ -153,6 +151,14 @@ static int drm_hdmi_check_mode(struct device
> >> *dev,
> >>
> >> return 0;
> >>
> >> }
> >>
> >> +static int drm_hdmi_check_mode(struct device *dev,
> >> + struct drm_display_mode *mode)
> >> +{
> >> + struct drm_hdmi_context *ctx = to_context(dev);
> >> +
> >> + return drm_hdmi_check_mode_ctx(ctx, mode);
> >> +}
> >> +
> >
> > nit: I don't think such wrapper is necessary.
> >
> > It seems to be easy enough to get from dev to ctx, so depending on the
> > amount of user of drm_hdmi_check_mode() it might be better to simply
> > change them to pass ctx instead of dev.
>
> This is a display_op that is defined to accept dev. It's changed later
> in the patchset to accept display, at which point the wrapper goes
> away.
Fair enough.
> > [snip]
> >
> >> @@ -403,19 +404,23 @@ static void vidi_subdrv_remove(struct
> >> drm_device
> >> *drm_dev, struct device *dev) /* TODO. */
> >>
> >> }
> >>
> >> -static int vidi_power_on(struct vidi_context *ctx, bool enable)
> >> +static int vidi_power_on(struct exynos_drm_manager *mgr, bool
> >> enable)
> >>
> >> {
> >>
> >> - struct exynos_drm_subdrv *subdrv = >subdrv;
> >> - struct device *dev = subdrv->dev;
> >> + struct vidi_context *ctx = mgr->ctx;
> >> +
> >> + DRM_DEBUG_KMS("%s\n", __FILE__);
> >> +
> >> + if (enable != false && enable != true)
> >> + return -EINVAL;
> >
> > Huh? What value would you expect a bool to have if not false or true?
> >
> > Anyway, this shouldn't really matter, as the check bellow assumes that
> > anything non-zero is true.
>
> This is pre-existing vidi code, I just moved it.
I don't see the hunk removing it from another location. Are you sure?
Best regards,
Tomasz
Usage of dma-buf sg-tables
On Fri, Nov 1, 2013 at 2:33 PM, Thomas Hellstrom wrote: > Considering that the linux DMA-API states that information in an sg-list may > be destroyed when it's mapped, > it seems to me that at least one of the drm prime functions use invalid > assumptions. > > In particular, I don't think it's safe to assume that pages in a single > sg-list segment are contigous after mapping, so > if we want struct page pointers we should use > > pfn = dma_to_phys((sg_dma_address(sg) + p_offset*PAGE_SIZE)) >> PAGE_SHIFT > > and if the pfn is valid, convert it to a struct page. > > (Incorrect code is, for example, in drm_prime_sg_to_page_addr_arrays) > > Or does dma-buf require that page info in sg-lists need to be kept across > the map operation? > > BTW this brings up another question: It's stated that the above function is > needed by the TTM driver in order to do > correct fault handling. This seems odd, TTM shouldn't be able to mmap() or > fault an imported dma-buf, right? The idea of the interface is that the backing storage is completely opaque ot the importer and might not even be backed by something with a struct page attached. But since that'd require us to rework lots of code (e.g. add new case to the ttm code besides ioremap and kmap to get at the backing storage from the cpu and also frob the fault handler a bit) Dave just hacked something up. No one ever touched it since. And I'm actually not too sure how the underlying pages survive the sg dma mapping ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 04/32] drm/exynos: Use manager_op initialize in fimd
On Friday 01 of November 2013 15:51:00 Sean Paul wrote:
> On Thu, Oct 31, 2013 at 7:49 PM, Tomasz Figa
wrote:
> > Hi Sean,
> >
> > On Tuesday 29 of October 2013 12:12:50 Sean Paul wrote:
> >> This patch implements the intitialize manager op in fimd.
> >>
> >> Signed-off-by: Sean Paul
> >> ---
> >>
> >> Changes in v2: None
> >> Changes in v3: None
> >>
> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
> >> 1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > [snip]
> >
> >> static void fimd_dpms(struct device *subdrv_dev, int mode)
> >> {
> >>
> >> struct fimd_context *ctx = get_fimd_context(subdrv_dev);
> >>
> >> @@ -660,6 +671,7 @@ static void fimd_wait_for_vblank(struct device
> >> *dev) }
> >>
> >> static struct exynos_drm_manager_ops fimd_manager_ops = {
> >>
> >> + .initialize = fimd_mgr_initialize,
> >>
> >> .dpms = fimd_dpms,
> >> .apply = fimd_apply,
> >> .commit = fimd_commit,
> >>
> >> @@ -681,7 +693,6 @@ static irqreturn_t fimd_irq_handler(int irq, void
> >> *dev_id) {
> >>
> >> struct fimd_context *ctx = (struct fimd_context *)dev_id;
> >> struct exynos_drm_subdrv *subdrv = >subdrv;
> >>
> >> - struct drm_device *drm_dev = subdrv->drm_dev;
> >
> > Apparently the driver already can have a reference to drm_device,
> > without the .initialize() method being called.
> >
> > I guess your change makes it somehow better, but patch description
> > fails to explain this.
>
> I've updated the patch description. This change is needed to remove
> all subdrv references from fimd so we can just implement manager.
Fair enough. Thanks.
Best regards,
Tomasz
[PATCH v3 05/32] drm/exynos: hdmi: Implement initialize op for hdmi
Hi Sean, On Friday 01 of November 2013 15:54:31 Sean Paul wrote: > On Thu, Oct 31, 2013 at 7:53 PM, Tomasz Figa wrote: > > Hi Sean, > > > > On Tuesday 29 of October 2013 12:12:51 Sean Paul wrote: [snip] > >> @@ -995,6 +1000,9 @@ static irqreturn_t mixer_irq_handler(int irq, > >> void > >> *arg) /* read interrupt status for handling and clearing flags for > >> VSYNC */ val = mixer_reg_read(res, MXR_INT_STATUS); > >> > >> + if (!ctx->drm_dev) > >> + goto out; > > > > The patch looks fine, but I'd like you to explain me in what > > conditions > > can this condition evaluate to true. > > This can happen if there's a mixer interrupt before the intialize() > hook is called. What about making the driver enable the interrupt (or even all the hardware) after this hook is called then? Best regards, Tomasz
[PATCH v3 02/32] drm/exynos: Merge overlay_ops into manager_ops
Hi Sean,
On Friday 01 of November 2013 15:50:05 Sean Paul wrote:
> On Thu, Oct 31, 2013 at 7:39 PM, Tomasz Figa
wrote:
> > Hi Sean,
> >
> > On Tuesday 29 of October 2013 12:12:48 Sean Paul wrote:
[snip]
> >> -static void fimd_wait_for_vblank(struct device *dev)
> >> -{
> >> - struct fimd_context *ctx = get_fimd_context(dev);
> >> -
> >> - if (ctx->suspended)
> >> - return;
> >> -
> >> - atomic_set(>wait_vsync_event, 1);
> >> -
> >> - /*
> >> - * wait for FIMD to signal VSYNC interrupt or return after
> >> - * timeout which is set to 50ms (refresh rate of 20).
> >> - */
> >> - if (!wait_event_timeout(ctx->wait_vsync_queue,
> >> - !atomic_read(>wait_vsync_event),
> >> - DRM_HZ/20))
> >> - DRM_DEBUG_KMS("vblank wait timed out.\n");
> >> -}
> >
> > Do you need all the churn of moving all the functions above? I believe
> > it would be enough to simply move the structure. This would greatly
> > decrease the diffstat and chances of possible merge conflicts.
>
> Hi Tomasz,
> I've done as you suggest,
Thanks.
> I'll post a new version once we settle on
> the other issues you brought up.
Okay.
I'm yet to review remaining patches from this series (I hope to review
next 5-7 patches later today), as it is quite a lot of changes, so stay
tuned for further comments. ;)
Best regards,
Tomasz
[Bug 71138] flashlight bug in L4D2
https://bugs.freedesktop.org/show_bug.cgi?id=71138 Alex Deucher changed: What|Removed |Added Attachment #88506|text/plain |image/png mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/fcf61c65/attachment.html>
[Bug 71138] flashlight bug in L4D2
https://bugs.freedesktop.org/show_bug.cgi?id=71138 --- Comment #2 from yashax at windowslive.com --- Created attachment 88508 --> https://bugs.freedesktop.org/attachment.cgi?id=88508=edit Another screenshot showing the black spots. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/7d0583d9/attachment.html>
[Bug 71138] flashlight bug in L4D2
https://bugs.freedesktop.org/show_bug.cgi?id=71138 --- Comment #1 from yashax at windowslive.com --- Created attachment 88507 --> https://bugs.freedesktop.org/attachment.cgi?id=88507=edit Re-uploading the first screenshot. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/3f1a8ec4/attachment-0001.html>
[Bug 71138] New: flashlight bug in L4D2
https://bugs.freedesktop.org/show_bug.cgi?id=71138 Priority: medium Bug ID: 71138 Assignee: dri-devel at lists.freedesktop.org Summary: flashlight bug in L4D2 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: yashax at windowslive.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 88506 --> https://bugs.freedesktop.org/attachment.cgi?id=88506=edit The black spots. When I'm looking on my teammates with flashlight, there are black spots on them. The black spots are moving very fast. It doesn't happens with walls/zombies, only with teammates. --- System information: Radeon HD 4850 Ubuntu 12.04.3 Linux 3.12-rc7 X.Org server version: 1.11.3 libdrm2 version: 2.4.47+git1310301030.45810d~gd~p xserver-xorg-video-radeon version: 7.2.0+git1310021050.f1dc67~gd~p OpenGL renderer string: Gallium 0.4 on AMD RV770 OpenGL version string: 3.0 Mesa 10.0.0-devel (git-b16b3c8 precise-oibaf-ppa) OpenGL shading language version string: 1.30 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/a6f5a0c0/attachment.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #5 from Tom --- Created attachment 88503 --> https://bugs.freedesktop.org/attachment.cgi?id=88503=edit gpu lockup log oh, I've realeased how to get a lockup log, here you go. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/f103d1f9/attachment.html>
[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #26 from Peter Zubaj --- I had similar problem with Fedora rawhide. Recompiling rawhide kernel from source with default config helped. Looks like problem is with some kind of memory trace enabled in kernel (most of cpu time was spend in slab_alloc and slab_free). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/84ba830e/attachment.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #4 from Tom --- Created attachment 88499 --> https://bugs.freedesktop.org/attachment.cgi?id=88499=edit mesa_src_config.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/21b486dc/attachment.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #3 from Tom --- Created attachment 88498 --> https://bugs.freedesktop.org/attachment.cgi?id=88498=edit dpm_enabled -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/1ac0069d/attachment.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #2 from Tom --- Created attachment 88497 --> https://bugs.freedesktop.org/attachment.cgi?id=88497=edit scrolling_websites_rendering -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/762fceee/attachment.html>
[Bug 71134] AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 --- Comment #1 from Tom --- Created attachment 88496 --> https://bugs.freedesktop.org/attachment.cgi?id=88496=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/a1ec2140/attachment-0001.html>
[Bug 71134] New: AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues
https://bugs.freedesktop.org/show_bug.cgi?id=71134 Priority: medium Bug ID: 71134 Assignee: dri-devel at lists.freedesktop.org Summary: AMD Radeon 7790 (BONAIRE Sea Islands) rendering, stability, performance issues Severity: normal Classification: Unclassified OS: Linux (All) Reporter: neatnoise at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 88495 --> https://bugs.freedesktop.org/attachment.cgi?id=88495=edit dmesg Hello, I would like to report a list of issues I've run into after some time of using mesa gallium driver for AMD Radeon 7790 (BONAIRE Sea Islands chip). Used components: OS: Gentoo User space packages: media-libs/mesa git sys-devel/llvm git x11-libs/libdrm git x11-libs/glamor git x11-drivers/xf86-video-ati git x11-base/xorg-server 1.14.3 Linux Kernel: 3.12.0-rc7 Rendering issues (tested with window managers: metacity and compiz): - rendering corruption while scrolling web pages even if inbrowser hardware acceleration is disabled (in Chrome as well as in Firefox). There is kind of pixel offset on the diagonal of rendered web page and corruption of images, borders (it happens only while scrolling). - Taking screenshot and using gksu (I'm using gnome 2 environment) results in huge rendering slow down (about 1 fps). I have to reload a window manager to fix this issue. - Introduced dpm to Sea Islands in 3.12 kernel (while enabled) leads to image corruption when moving windows, playing videos (in a browser and a video player), scrolling websites. The corrupted image shows as flickering and messing around parts of the screen. The rendered image is ok only if nothing happens on the screen. - anisotropic filtering doesn't seem to work (tested in sauerbraten game). After applaying there is no visual difference between bilinear filtering and anisotropic filtering. Stability issues: - Any use of OpenGL hardware acceleration after few minutes leads to GPU lockup (from basic OpenGL games like sauerbraten, inbrowser hardware acceleration, to compiz window manager). Glamor + metacity seems to work without GPU lockups. - Playing videos in mplayer (VO: [vdpau]) also leads to a GPU lockup from time to time. The same happens in firefox browser while playing youtube videos in uvd decoding + flash Performance issues: - I get much less fps compared to my old card - Radeon 4850 (r600g driver) even if the clocks are manually set to a maximal frequency. - Compiz with basic effects is sometimes not fluent - drops to less than 30 fps especially when there are more windows opened. I would like attach any GPU lockup logs but dmesg doesn't leave any trace. More than half of lockups are not recoverable and I have to reboot the computer. Screens and logs are in the attachments. Thank you for any help in resolving these issues. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/e29b3ed2/attachment.html>
[PATCH 5/6] dri3: Add DRI3 support to GLX, DRI common and Intel driver
On Thu, Oct 31, 2013 at 04:13:15PM -0700, Keith Packard wrote:
> This hooks DRI3 support into the GLX layer, the DRI common layer and the Intel
> driver.
>
> Signed-off-by: Keith Packard
> ---
> configure.ac | 10 +-
> include/GL/internal/dri_interface.h | 158 +++
> src/glx/Makefile.am |2 +
> src/glx/dri3_common.c | 146 +++
> src/glx/dri3_glx.c| 1539
> +
> src/glx/dri3_priv.h | 128 ++
> src/glx/glxclient.h |2 +
> src/glx/glxext.c |6 +-
> src/mesa/drivers/dri/common/dri_util.c| 163 ++-
> src/mesa/drivers/dri/common/dri_util.h| 23 +
> src/mesa/drivers/dri/i915/intel_context.c | 109 +-
> src/mesa/drivers/dri/i915/intel_mipmap_tree.c | 33 +
> src/mesa/drivers/dri/i915/intel_mipmap_tree.h |8 +
> src/mesa/drivers/dri/i965/brw_context.c | 110 +-
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 61 +
> src/mesa/drivers/dri/i965/intel_mipmap_tree.h |8 +
> src/mesa/drivers/dri/i965/intel_screen.c | 107 +-
> 17 files changed, 2594 insertions(+), 19 deletions(-)
> create mode 100644 src/glx/dri3_common.c
> create mode 100644 src/glx/dri3_glx.c
> create mode 100644 src/glx/dri3_priv.h
>
> diff --git a/configure.ac b/configure.ac
> index f94c9b9..b6158d9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,6 +38,8 @@ LIBDRM_NVVIEUX_REQUIRED=2.4.33
> LIBDRM_NOUVEAU_REQUIRED="2.4.33 libdrm >= 2.4.41"
> LIBDRM_FREEDRENO_REQUIRED=2.4.39
> DRI2PROTO_REQUIRED=2.6
> +DRI3PROTO_REQUIRED=1.0
> +LIBUDEV_REQUIRED=151
> GLPROTO_REQUIRED=1.4.14
> LIBDRM_XORG_REQUIRED=2.4.24
> LIBKMS_XORG_REQUIRED=1.0.0
> @@ -820,10 +822,12 @@ xyesno)
> fi
> PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> +PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >= $DRI3PROTO_REQUIRED])
> +PKG_CHECK_MODULES([LIBUDEV], [libudev >= $LIBUDEV_REQUIRED])
> fi
>
> # find the DRI deps for libGL
> -dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2
> >= 1.8"
> +dri_modules="x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1 xcb-dri2
> >= 1.8 xcb-dri3 xcb-sync xshmfence"
>
> # add xf86vidmode if available
> PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes,
> HAVE_XF86VIDMODE=no)
> @@ -833,8 +837,8 @@ xyesno)
>
> PKG_CHECK_MODULES([DRIGL], [$dri_modules])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV $dri_modules"
> -X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> -GL_LIB_DEPS="$DRIGL_LIBS"
> +X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS $LIBUDEV_CFLAGS"
> +GL_LIB_DEPS="$DRIGL_LIBS $LIBUDEV_LIBS"
>
> # need DRM libs, $PTHREAD_LIBS, etc.
> GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h
> index 48993b9..b06ad8d 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -86,6 +86,11 @@ typedef struct __DRIdri2LoaderExtensionRec
> __DRIdri2LoaderExtension;
> typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
> typedef struct __DRI2throttleExtensionRec__DRI2throttleExtension;
>
> +
> +typedef struct __DRIdri3BufferRec __DRIdri3Buffer;
> +typedef struct __DRIdri3ExtensionRec__DRIdri3Extension;
> +typedef struct __DRIdri3LoaderExtensionRec __DRIdri3LoaderExtension;
> +
> /*@}*/
>
>
> @@ -966,6 +971,159 @@ struct __DRIdri2ExtensionRec {
>
>
> /**
> + * DRI3 Loader extension.
> + */
> +
> +#define __DRI3_DRIVER_EXTENSIONS "__dri3DriverExtensions"
> +
> +enum __DRI3bufferType {
> + __DRI3_BUFFER_BACK = 0,
> + __DRI3_BUFFER_FRONT = 1
> +};
> +
> +struct __DRIdri3BufferRec {
> + unsigned int size;
> + unsigned int pitch;
> + unsigned int cpp;
> + unsigned int flags;
> + unsigned int width, height;
> + enum __DRI3bufferType buffer_type;
> + uint32_t pixmap;
> + uint32_t sync_fence;
> + int32_t *shm_fence;
> + void *driverPrivate;
> +};
My main concern with this patch is that I'd like to use __DRIimage for
the color buffers instead of this new __DRIdri3Buffer. __DRIimage is
an opaque structure which we introduced for EGLImage support. It
essentially wraps an intel_region, so it's similar to __DRI3buffer,
except it's all opaque. __DRIimage is essentially *the* color buffer
abstraction in the DRI driver interface now and we're already using it
for color buffers in GBM and Wayland. Using __DRIimage will make
those backends and this patch simpler.
The intel version of __DRIimage is defined in intel_regions.h. It's
more complicated than __DRIdri3Buffer since it supports planar
buffers, but at the end of the
[Bug 70675] steam error dialogs are garbled
https://bugs.freedesktop.org/show_bug.cgi?id=70675 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Alex Deucher --- Pushed: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=3b38701a72fa1cad1e4610a2f4330b3da4cc6391 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/06651add/attachment.html>
[PATCH v3 05/32] drm/exynos: hdmi: Implement initialize op for hdmi
On Fri, Nov 1, 2013 at 3:56 PM, Tomasz Figa wrote: > Hi Sean, > > On Friday 01 of November 2013 15:54:31 Sean Paul wrote: >> On Thu, Oct 31, 2013 at 7:53 PM, Tomasz Figa > wrote: >> > Hi Sean, >> > >> > On Tuesday 29 of October 2013 12:12:51 Sean Paul wrote: > [snip] >> >> @@ -995,6 +1000,9 @@ static irqreturn_t mixer_irq_handler(int irq, >> >> void >> >> *arg) /* read interrupt status for handling and clearing flags for >> >> VSYNC */ val = mixer_reg_read(res, MXR_INT_STATUS); >> >> >> >> + if (!ctx->drm_dev) >> >> + goto out; >> > >> > The patch looks fine, but I'd like you to explain me in what >> > conditions >> > can this condition evaluate to true. >> >> This can happen if there's a mixer interrupt before the intialize() >> hook is called. > > What about making the driver enable the interrupt (or even all the > hardware) after this hook is called then? > Sure, I can do that. This is one of the reasons that a unified driver model would be useful. Sean > Best regards, > Tomasz >
[PATCH v3 06/32] drm/exynos: Pass exynos_drm_manager in manager ops instead of dev
On Thu, Oct 31, 2013 at 8:19 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 12:12:52 Sean Paul wrote:
>> This patch changes the manager ops callbacks from accepting the subdrv
>> device pointer to taking a pointer to the manager. This will allow us
>> to move closer to decoupling manager/display from subdrv, and
>> subsequently decoupling the crtc/plane from the encoder.
>
> The idea of changing callbacks argument itself is fine for me, but I
> wonder if by the way we couldn't refactor the code in a way that would
> allow type checking of context structures. This would make the code a bit
> less error-prone (or maybe I'm just a bit too paranoid...).
>
> Anyway, please see my remaining comments inline.
>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2:
>> - Instead of passing context, pass manager
>> - Properly assign ctx->dev in fimd driver
>> Changes in v3:
>> - Added vidi implementation
>>
>> drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 35
>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 +++---
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 114
>> ++ drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> | 72 drivers/gpu/drm/exynos/exynos_drm_vidi.c |
>> 83 ++- 6 files changed, 180 insertions(+), 153
>> deletions(-)
> [snip]
>> @@ -182,16 +184,16 @@ static struct exynos_drm_display_ops
>> fimd_display_ops = { .power_on = fimd_display_power_on,
>> };
>>
>> -static void fimd_win_mode_set(struct device *dev,
>> - struct exynos_drm_overlay *overlay)
>> +static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
>> + struct exynos_drm_overlay *overlay)
>> {
>> - struct fimd_context *ctx = get_fimd_context(dev);
>> + struct fimd_context *ctx = mgr->ctx;
>> struct fimd_win_data *win_data;
>> int win;
>> unsigned long offset;
>>
>> if (!overlay) {
>> - dev_err(dev, "overlay is NULL\n");
>> + DRM_ERROR("overlay is NULL\n");
>
> This change does not seem to be related to $subject.
>
It is. fimd_win_mode_set does not take dev as an argument any longer,
as such it's undefined.
>> return;
>> }
>>
>> @@ -231,9 +233,8 @@ static void fimd_win_mode_set(struct device *dev,
>> overlay->fb_width, overlay->crtc_width);
>> }
>>
>> -static void fimd_win_set_pixfmt(struct device *dev, unsigned int win)
>> +static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int
>> win) {
>
> Again not really related to $subject. Maybe this should be done in a
> preparatory patch preceeding this one? (+ same comment for several
> identical changes below)
>
I think it's directly related to the subject. We no longer pass dev as
an argument, so that has indirect effects on other functions.
>> - struct fimd_context *ctx = get_fimd_context(dev);
>> struct fimd_win_data *win_data = >win_data[win];
>> unsigned long val;
>>
> [snip]
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c index aebcc0e..ca0a87f
>> 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> @@ -129,11 +129,9 @@ static struct edid *drm_hdmi_get_edid(struct device
>> *dev,
>>
>> return NULL;
>> }
>> -
>> -static int drm_hdmi_check_mode(struct device *dev,
>> +static int drm_hdmi_check_mode_ctx(struct drm_hdmi_context *ctx,
>> struct drm_display_mode *mode)
>> {
>> - struct drm_hdmi_context *ctx = to_context(dev);
>> int ret = 0;
>>
>> /*
>> @@ -153,6 +151,14 @@ static int drm_hdmi_check_mode(struct device *dev,
>> return 0;
>> }
>>
>> +static int drm_hdmi_check_mode(struct device *dev,
>> + struct drm_display_mode *mode)
>> +{
>> + struct drm_hdmi_context *ctx = to_context(dev);
>> +
>> + return drm_hdmi_check_mode_ctx(ctx, mode);
>> +}
>> +
>
> nit: I don't think such wrapper is necessary.
>
> It seems to be easy enough to get from dev to ctx, so depending on the
> amount of user of drm_hdmi_check_mode() it might be better to simply
> change them to pass ctx instead of dev.
>
This is a display_op that is defined to accept dev. It's changed later
in the patchset to accept display, at which point the wrapper goes
away.
> [snip]
>> @@ -403,19 +404,23 @@ static void vidi_subdrv_remove(struct drm_device
>> *drm_dev, struct device *dev) /* TODO. */
>> }
>>
>> -static int vidi_power_on(struct vidi_context *ctx, bool enable)
>> +static int vidi_power_on(struct exynos_drm_manager *mgr, bool enable)
>> {
>> - struct exynos_drm_subdrv *subdrv = >subdrv;
>> - struct device *dev = subdrv->dev;
>> + struct vidi_context *ctx = mgr->ctx;
>> +
>> + DRM_DEBUG_KMS("%s\n", __FILE__);
>> +
>> + if (enable != false && enable != true)
>> +
[PATCH v3 05/32] drm/exynos: hdmi: Implement initialize op for hdmi
On Thu, Oct 31, 2013 at 7:53 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 12:12:51 Sean Paul wrote:
>> This patch implements the initialize callback in the hdmi and mixer
>> manager. This allows us to get rid of drm_dev in the drm_hdmi level and
>> track it in the mixer and hdmi drivers. This is one of the things
>> holding back the complete removal of the drm_hdmi layer.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2: None
>> Changes in v3: None
>>
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 35
>> ++--
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 ++-
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 18
>> drivers/gpu/drm/exynos/exynos_mixer.c| 35
>> +++- 4 files changed, 66 insertions(+), 25
>> deletions(-)
> [snip]
>> @@ -985,8 +991,7 @@ static struct exynos_mixer_ops mixer_ops = {
>>
>> static irqreturn_t mixer_irq_handler(int irq, void *arg)
>> {
>> - struct exynos_drm_hdmi_context *drm_hdmi_ctx = arg;
>> - struct mixer_context *ctx = drm_hdmi_ctx->ctx;
>> + struct mixer_context *ctx = arg;
>> struct mixer_resources *res = >mixer_res;
>> u32 val, base, shadow;
>>
>> @@ -995,6 +1000,9 @@ static irqreturn_t mixer_irq_handler(int irq, void
>> *arg) /* read interrupt status for handling and clearing flags for
>> VSYNC */ val = mixer_reg_read(res, MXR_INT_STATUS);
>>
>> + if (!ctx->drm_dev)
>> + goto out;
>
> The patch looks fine, but I'd like you to explain me in what conditions
> can this condition evaluate to true.
>
This can happen if there's a mixer interrupt before the intialize()
hook is called.
Sean
> Best regards,
> Tomasz
>
[PATCH v3 04/32] drm/exynos: Use manager_op initialize in fimd
On Thu, Oct 31, 2013 at 7:49 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 12:12:50 Sean Paul wrote:
>> This patch implements the intitialize manager op in fimd.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2: None
>> Changes in v3: None
>>
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
>> 1 file changed, 15 insertions(+), 4 deletions(-)
> [snip]
>> static void fimd_dpms(struct device *subdrv_dev, int mode)
>> {
>> struct fimd_context *ctx = get_fimd_context(subdrv_dev);
>> @@ -660,6 +671,7 @@ static void fimd_wait_for_vblank(struct device *dev)
>> }
>>
>> static struct exynos_drm_manager_ops fimd_manager_ops = {
>> + .initialize = fimd_mgr_initialize,
>> .dpms = fimd_dpms,
>> .apply = fimd_apply,
>> .commit = fimd_commit,
>> @@ -681,7 +693,6 @@ static irqreturn_t fimd_irq_handler(int irq, void
>> *dev_id) {
>> struct fimd_context *ctx = (struct fimd_context *)dev_id;
>> struct exynos_drm_subdrv *subdrv = >subdrv;
>> - struct drm_device *drm_dev = subdrv->drm_dev;
>
> Apparently the driver already can have a reference to drm_device, without
> the .initialize() method being called.
>
> I guess your change makes it somehow better, but patch description fails
> to explain this.
>
I've updated the patch description. This change is needed to remove
all subdrv references from fimd so we can just implement manager.
Sean
> Best regards,
> Tomasz
>
[PATCH v3 02/32] drm/exynos: Merge overlay_ops into manager_ops
On Thu, Oct 31, 2013 at 7:39 PM, Tomasz Figa wrote:
> Hi Sean,
>
> On Tuesday 29 of October 2013 12:12:48 Sean Paul wrote:
>> This patch merges overlay_ops into manager_ops. In all cases,
>> overlay_ops is implemented in the same place as manager ops, it doesn't
>> serve a functional purpose, and doesn't make things more clear.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>> Changes in v2: None
>> Changes in v3: None
>>
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 29 +--
>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 26 +-
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 363
>> ++-- drivers/gpu/drm/exynos/exynos_drm_hdmi.c
>> | 36 ++-
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 29 +--
>> drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
>> 6 files changed, 229 insertions(+), 256 deletions(-)
> [snip]
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 868a14d..f271f22
>> 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -181,185 +181,6 @@ static struct exynos_drm_display_ops
>> fimd_display_ops = { .power_on = fimd_display_power_on,
>> };
>>
>> -static void fimd_dpms(struct device *subdrv_dev, int mode)
>> -{
>> - struct fimd_context *ctx = get_fimd_context(subdrv_dev);
>> -
>> - DRM_DEBUG_KMS("%d\n", mode);
>> -
>> - mutex_lock(>lock);
>> -
>> - switch (mode) {
>> - case DRM_MODE_DPMS_ON:
>> - /*
>> - * enable fimd hardware only if suspended status.
>> - *
>> - * P.S. fimd_dpms function would be called at booting time
> so
>> - * clk_enable could be called double time.
>> - */
>> - if (ctx->suspended)
>> - pm_runtime_get_sync(subdrv_dev);
>> - break;
>> - case DRM_MODE_DPMS_STANDBY:
>> - case DRM_MODE_DPMS_SUSPEND:
>> - case DRM_MODE_DPMS_OFF:
>> - if (!ctx->suspended)
>> - pm_runtime_put_sync(subdrv_dev);
>> - break;
>> - default:
>> - DRM_DEBUG_KMS("unspecified mode %d\n", mode);
>> - break;
>> - }
>> -
>> - mutex_unlock(>lock);
>> -}
> [snip]
>> -static void fimd_wait_for_vblank(struct device *dev)
>> -{
>> - struct fimd_context *ctx = get_fimd_context(dev);
>> -
>> - if (ctx->suspended)
>> - return;
>> -
>> - atomic_set(>wait_vsync_event, 1);
>> -
>> - /*
>> - * wait for FIMD to signal VSYNC interrupt or return after
>> - * timeout which is set to 50ms (refresh rate of 20).
>> - */
>> - if (!wait_event_timeout(ctx->wait_vsync_queue,
>> - !atomic_read(>wait_vsync_event),
>> - DRM_HZ/20))
>> - DRM_DEBUG_KMS("vblank wait timed out.\n");
>> -}
>
> Do you need all the churn of moving all the functions above? I believe it
> would be enough to simply move the structure. This would greatly decrease
> the diffstat and chances of possible merge conflicts.
>
Hi Tomasz,
I've done as you suggest, I'll post a new version once we settle on
the other issues you brought up.
Sean
> Otherwise the patch looks good to me and improves things indeed.
>
> Best regards,
> Tomasz
>
[pull] radeon drm-next-3.13
Hi Dave, Initial pull request for radeon drm-next 3.13. Highlights: - Enable DPM on a number of asics by default - Enable audio by default - Dynamically power down dGPUs on PowerXpress systems - Lots of bug fixes The following changes since commit 9d6104e0174b130ed864571b31811c3fd09fd611: drm/sysfs: Do not drop device reference twice (2013-10-31 06:33:49 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-3.13 for you to fetch changes up to 70471860ff9f335c60c004d42ebd48945bfa5403: drm/radeon: don't share PPLLs on DCE4.1 (2013-11-01 15:25:55 -0400) Alex Deucher (23): drm/radeon: Add support for programming the FMT blocks drm/radeon: add a connector property for dither drm/radeon: enable hdmi audio by default drm/radeon: plug in blit copy routine for SI drm/radeon: implement blit copy callback for CIK drm/radeon/si: tell dpm there is a display connected drm/radeon/atom: don't call [EN|DIS]ABLE_OUTPUT on DCE3.x drm/radeon/atom: don't call [EN|DIS]ABLE_OUTPUT on DCE4.x drm/radeon/audio: break out of loops once we match connector drm/radeon/audio: write audio/video latency info for DCE4/5 drm/radeon/audio: write audio/video latency info for DCE6/8 drm/radeon/dpm: only print dpm debugging messages when radeon_dpm=1 drm/radeon: enable DPM by default on SUMO/PALM APUs drm/radeon: enable DPM by default on SI asics drm/radeon: enable DPM by default on BTC asics drm/radeon: enable DPM by default on evergreen asics drm/radeon: enable DPM by default on r7xx asics drm/radeon: disable force performance state when thermal state is active drm/radeon/dpm: retain user selected performance level across state changes drm/radeon: fix endian handling in rlc buffer setup drm/radeon/si: fix define for MC_SEQ_TRAIN_WAKEUP_CNTL drm/radeon/dpm: fix typo in setting smc flag drm/radeon: don't share PPLLs on DCE4.1 Christian K?nig (7): drm/radeon: activate UVD clocks before sending the destroy msg drm/radeon: fix UVD destroy IB size drm/radeon: rework and fix reset detection v2 drm/radeon: add vm_set_page tracepoint drm/radeon: drop CP page table updates & cleanup v2 drm/radeon: initially clear page tables drm/radeon: clear the page directory using the DMA Dan Carpenter (1): drm/radeon/dpm: cleanup a type issue with rv6xx_clocks_per_unit() Dave Airlie (2): drm/radeon: convert to pmops drm/radeon: add runtime PM support (v2) Maarten Lankhorst (1): drm/radeon: fixup locking inversion between, mmap_sem and reservations Marek Ol??k (1): drm/radeon: don't use PACKET2 on CIK Markus Trippelsdorf (1): drm/radeon: Implement radeon_pci_shutdown drivers/gpu/drm/radeon/atombios_crtc.c | 2 +- drivers/gpu/drm/radeon/atombios_encoders.c | 24 +- drivers/gpu/drm/radeon/cik.c | 253 --- drivers/gpu/drm/radeon/cik_sdma.c| 22 +- drivers/gpu/drm/radeon/cikd.h| 95 drivers/gpu/drm/radeon/dce6_afmt.c | 43 drivers/gpu/drm/radeon/evergreen.c | 80 +- drivers/gpu/drm/radeon/evergreen_hdmi.c | 48 +++- drivers/gpu/drm/radeon/evergreend.h | 70 ++ drivers/gpu/drm/radeon/ni.c | 76 -- drivers/gpu/drm/radeon/ni_dma.c | 19 +- drivers/gpu/drm/radeon/r600.c| 53 drivers/gpu/drm/radeon/r600_cs.c | 16 +- drivers/gpu/drm/radeon/r600_hdmi.c | 8 +- drivers/gpu/drm/radeon/r600d.h | 28 +++ drivers/gpu/drm/radeon/radeon.h | 33 ++- drivers/gpu/drm/radeon/radeon_asic.c | 17 +- drivers/gpu/drm/radeon/radeon_asic.h | 35 +-- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 4 + drivers/gpu/drm/radeon/radeon_connectors.c | 104 +++- drivers/gpu/drm/radeon/radeon_cs.c | 298 +++ drivers/gpu/drm/radeon/radeon_device.c | 77 -- drivers/gpu/drm/radeon/radeon_display.c | 59 - drivers/gpu/drm/radeon/radeon_drv.c | 168 +++-- drivers/gpu/drm/radeon/radeon_drv.h | 3 + drivers/gpu/drm/radeon/radeon_fence.c| 347 +-- drivers/gpu/drm/radeon/radeon_gart.c | 73 +- drivers/gpu/drm/radeon/radeon_ioc32.c| 2 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 8 +- drivers/gpu/drm/radeon/radeon_kms.c | 26 +- drivers/gpu/drm/radeon/radeon_mode.h | 14 ++ drivers/gpu/drm/radeon/radeon_pm.c | 62 +++-- drivers/gpu/drm/radeon/radeon_trace.h| 24 ++ drivers/gpu/drm/radeon/radeon_uvd.c | 4 +- drivers/gpu/drm/radeon/rs600.c | 64 + drivers/gpu/drm/radeon/rv6xx_dpm.c |
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #40 from Anssi Hannula --- The changes look sound to me. I had already forgotten that the table values were off for the rounded clocks (even though I had mentioned it in comment #5). Also, I see now that as the DTO is also set according to the target clock (instead of pll clock), this compensates for possible difference between target/pll clocks when calculating CTS. So the CTS/N values need to be selected as if the clock was exactly the rounded clock (e.g. 74176), instead of using the spec values (that are correct only for exact 74250/1.001). This should also mean that the SW values are all-OK except in the cases where an integer CTS is not possible as per Pierre's note 1. > 1. The 25175 clock at 44.1 kHz is out of spec. There are no correct values to > make it in spec. So either change the clock, rely on hw calculated values, or > hope that sinks tolerate the large N. 4th alternative is to round CTS and leave the glitches in on those modes. I might even slightly prefer that than produce out-of-spec N, but that is just my preference and I don't really have any real-world data of course... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/5cb3d411/attachment.html>
dma-buf non-coherent mmap
On 11/01/2013 11:17 AM, Daniel Vetter wrote: > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach > wrote: >> GStreamer needs _some_ way of accessing the buffer contents with the >> CPU, this doesn't necessarily have to be the dumb mmap we have right >> now. >> DMA-BUF support in GSt is not really finished (I know we have a lot of >> patches internally to make it actually work with anything, which are >> trickling upstream right now), so this might be a good time to hammer >> out how it should be done, so we can adapt GSt before people start to >> rely on the dma-buf fallback mmap. >> >> I would think the bracketed mmap idea that was thrown around by Rob some >> time ago when the mmap topic first surfaced is simple enough that we >> don't need additional userspace helpers and should be enough to make the >> coherency issue disappear. > Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap > stuff and simply demand that userspace calls that we'd have something > half-sane at least. Since we currently don't really have any real > users we could still do this abi change I think. > > One open issue is whether the BEGIN_MMAP ioctl should also synchronize > with any outstanding gpu access. Imo it should, since that's pretty > much how all the current drm drivers work, but maybe we should reserve > space for a few flags so that this can be extended later on - Android > seems to be pretty insistent on using explicit syncpoints everywhere > instead of implicit synchronization. Or maybe we should have the flag > already, but reject implicit syncing until Maarten's dma_fence stuff > is in and enabled, dunno. Adding him to cc. > > The clear thing otoh is that these two ioctls should only serve as > barriers, not as locks as has been proposed in some other RFCs > floating around (iirc the one from exynos was borked in this fashion). > -Daniel I think one of the worst use-cases we could imagine would be a client doing something like the old kde screen saver that drew hundreds of thousands of small squares and in addition would flush for each square. Here begin/mmap end/mmap would not suffice, and _mandatory_ syncing would also be a bad idea. We'd need to have a region supplied. Something like gallium texture transfers would work reasonably well, but they allow direct mappings of the underlying surface / buffer, which means that a lazy client might allocate texture transfers covering the whole buffer if coherent drivers made that a reasonably fast operation. access using something like texsubimage (or region-type pwrites / preads) would at least involve a memcpy / kernel copy and would have the client think twice before accessing the dma-buf in this way, but I understand that this might sound frustrating for writers of coherent drivers. (I would have opposed it :)) But I'd like to stress that a single BEGIN_MMAP / END_MMAP wouldn't help us much, and that we need a read/ write/bidirectional indication. Thanks, /Thomas
Usage of dma-buf sg-tables
Hi! Considering that the linux DMA-API states that information in an sg-list may be destroyed when it's mapped, it seems to me that at least one of the drm prime functions use invalid assumptions. In particular, I don't think it's safe to assume that pages in a single sg-list segment are contigous after mapping, so if we want struct page pointers we should use pfn = dma_to_phys((sg_dma_address(sg) + p_offset*PAGE_SIZE)) >> PAGE_SHIFT and if the pfn is valid, convert it to a struct page. (Incorrect code is, for example, in drm_prime_sg_to_page_addr_arrays) Or does dma-buf require that page info in sg-lists need to be kept across the map operation? BTW this brings up another question: It's stated that the above function is needed by the TTM driver in order to do correct fault handling. This seems odd, TTM shouldn't be able to mmap() or fault an imported dma-buf, right? Thanks, Thomas
dma-buf non-coherent mmap
Am Freitag, den 01.11.2013, 09:22 -0400 schrieb Rob Clark: > On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter > wrote: > > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach > > wrote: > >> GStreamer needs _some_ way of accessing the buffer contents with the > >> CPU, this doesn't necessarily have to be the dumb mmap we have right > >> now. > >> DMA-BUF support in GSt is not really finished (I know we have a lot of > >> patches internally to make it actually work with anything, which are > >> trickling upstream right now), so this might be a good time to hammer > >> out how it should be done, so we can adapt GSt before people start to > >> rely on the dma-buf fallback mmap. > >> > >> I would think the bracketed mmap idea that was thrown around by Rob some > >> time ago when the mmap topic first surfaced is simple enough that we > >> don't need additional userspace helpers and should be enough to make the > >> coherency issue disappear. > > > > Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap > > stuff and simply demand that userspace calls that we'd have something > > half-sane at least. Since we currently don't really have any real > > users we could still do this abi change I think. > > > > One open issue is whether the BEGIN_MMAP ioctl should also synchronize > > with any outstanding gpu access. Imo it should, since that's pretty > > much how all the current drm drivers work, but maybe we should reserve > > space for a few flags so that this can be extended later on - Android > > seems to be pretty insistent on using explicit syncpoints everywhere > > instead of implicit synchronization. Or maybe we should have the flag > > already, but reject implicit syncing until Maarten's dma_fence stuff > > is in and enabled, dunno. Adding him to cc. > I don't think we need that right now. We may prepare for implicit sync by having the flag ready in the API, but don't force the exporters to implement it right now. > I suppose I wouldn't mind if we made BEGIN/END_MMAP as sort of clones > of the CPU_PREP/FINI ioctls I have in msm.. where the CPU_PREP takes a > flag/bitmask to indicate READ/WRITE/NOSYNC > > That doesn't really help with partial buffer access, like you'd get if > you were using the buffer for vertex upload. Although not really sure > if we'd be seeing dmabuf's for that sort of use-case. We could make a > more elaborate kernel interface that maps better to all the different > cases in pipe_transfer. Or we could just say that that is overkill. > I don't really have strong opinion about that (so someone who does, > send an RFC). But I do agree with the "barriers only, not locks". > I just checked back with our GStreamer guy and he thinks that for the use-cases he sees today it would make a lot of sense to have some way to indicate that userspace is only going to access a partial range of the buffer. I think this may be a crucial optimization on all kinds of devices where you have to ensure coherency manually. Personally I would like to have the same kind of partial access indicators in DRMs cpu_prep/fini to optimize all the userspace suballocations we have today. I think we are all on the same page with the barriers only thing. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #11 from Chris --- Created attachment 88477 --> https://bugs.freedesktop.org/attachment.cgi?id=88477=edit corrupted screen on ubuntu 13.04 corrupted screen on ubuntu 13.04 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/3d5465a7/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 Pierre Ossman changed: What|Removed |Added Attachment #88476|0 |1 is patch|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/35983bd1/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #39 from Pierre Ossman --- Created attachment 88476 --> https://bugs.freedesktop.org/attachment.cgi?id=88476=edit properly calculate both N and CTS -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/84499000/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #38 from Peter Fr?hberger --- Nope it is okay. You had everything I needed in your previous post (could easily copy the two functions and the struct) - will report back later. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/5304be6d/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #37 from Pierre Ossman --- (In reply to comment #36) > Could you post a patch, then I can try on my hardware. I was hoping to be lazy, but I'll sort it out then. :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/e855864b/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #36 from Peter Fr?hberger --- Could you post a patch, then I can try on my hardware. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/1f70a775/attachment-0001.html>
[Linaro-mm-sig] thoughts of looking at android fences
struct list_headchild_list_head;
> >> spinlock_tchild_list_lock;
> >>
> >> struct sync_timeline_debug {
> >> struct list_headsync_timeline_list;
> >> char name[32];
> >> };
> >> };
> >>
> >> Hm, this looks familiar, the drm drivers had some structure for
> protecting the active fence list that has
> >> an identical definition, but with a slightly different list offset..
> >>
> >> struct __wait_queue_head {
> >> spinlock_t lock;
> >> struct list_head task_list;
> >> };
> >>
> >> typedef struct __wait_queue_head wait_queue_head_t;
> >>
> >> This is nicer to convert the existing drm drivers, which already
> implement synchronous wait with a waitqueue.
> >> The default wait op is in fact
> >>
> >> Ok enough of this little excercise. I just wanted to see how different
> the 2 are. I think even if the
> >> fence interface will end up being incompatible it wouldn't be too hard
> to convert android..
> >>
> >> Main difference is the ops, android has a lot more than what I used for
> dma-fence:
> >>
> >> struct fence_ops {
> >> bool (*enable_signaling)(struct fence *fence); // required,
> callback called with fence->lock held,
> >> // fence->lock is a pointer passed to __fence_init. Callback
> should make sure that the fence will
> >> // be signaled asap.
> >> bool (*signaled)(struct fence *fence); // optional, but if set to
> NULL fence_is_signaled is not
> >> // required to ever return true, unless enable_signaling is
> called, similar to has_signaled
> >> long (*wait)(struct fence *fence, bool intr, signed long timeout);
> // required, but it can be set
> >> // to the default fence_default_wait implementation which is
> recommended. It calls enable_signaling
> >> // and appends itself to async callback list. Identical semantics
> to wait_event_interruptible_timeout.
> >> void (*release)(struct fence *fence); // free_pt
> >> };
> >>
> >> Because every fence has a stamp, there is no need for a compare op.
> >>
> >> struct sync_timeline_ops {
> >> const char *driver_name;
> >>
> >> /* required */
> >> struct sync_pt *(*dup)(struct sync_pt *pt);
> >>
> >> /* required */
> >> int (*has_signaled)(struct sync_pt *pt);
> >>
> >> /* required */
> >> int (*compare)(struct sync_pt *a, struct sync_pt *b);
> >>
> >> /* optional */
> >> void (*free_pt)(struct sync_pt *sync_pt);
> >>
> >> /* optional */
> >> void (*release_obj)(struct sync_timeline *sync_timeline);
> >>
> >> /* deprecated */
> >> void (*print_obj)(struct seq_file *s,
> >>struct sync_timeline *sync_timeline);
> >>
> >> /* deprecated */
> >> void (*print_pt)(struct seq_file *s, struct sync_pt *sync_pt);
> >>
> >> /* optional */
> >> int (*fill_driver_data)(struct sync_pt *syncpt, void *data, int
> size);
> >>
> >> /* optional */
> >> void (*timeline_value_str)(struct sync_timeline *timeline, char
> *str,
> >> int size);
> >>
> >> /* optional */
> >> void (*pt_value_str)(struct sync_pt *pt, char *str, int size);
> >> };
> >>
> >> The dup is weird, I have nothing like that. I do allow multiple
> callbacks to be added to the same
> >> dma-fence, and allow callbacks to be aborted, provided you still hold a
> refcount.
> >>
> >> So from the ops it looks like what's mostly missing is print_pt,
> fill_driver_data,
> >> timeline_value_str and pt_value_str.
> >>
> >> I have no idea how much of this is inaccurate. This is just an
> assessment based on me looking at
> >> the stuff in drivers/staging/android/sync for an afternoon and the
> earlier discussions. :)
> >>
> > So I actually tried to implement it now. I killed all the deprecated
> members and assumed a linear timeline.
> > This means that syncpoints can only be added at the end, not in between.
> In particular it means sw_sync
> > might be slightly broken.
> >
> > I only tested it with a simple program I wrote called ufence.c, it's in
> drivers/staging/android/ufence.c in the following tree:
> >
> > http://cgit.freedesktop.org/~mlankhorst/linux
> >
> > the "rfc: convert android to fence api" has all the changes from my
> dma-fence proposal to what android would need,
> > it also converts the userspace fence api to use the dma-fence api.
> >
> > sync_pt is implemented as fence too. This meant not having to convert
> all of android right away, though I did make some changes.
> > I killed the deprecated members and made all the fence calls forward to
> the sync_timeline_ops. dup and compare are no longer used.
> >
> > I haven't given this a spin on a full android kernel, only with the
> components that are in mainline kernel under staging and my dumb test
> program.
> >
> > ~Maarten
> >
> > PS: The nomenclature is very confusing. I want to rename dma-fence to
> syncpoint, but I want some feedback from the android devs first. :)
> >
> Come on, any feedback? I want to move the discussion forward.
>
> ~Maarten
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/d37d65a9/attachment-0001.html>
[Bug 52467] Radeon HD6450 KMS garbled screen on boot.
https://bugs.freedesktop.org/show_bug.cgi?id=52467 --- Comment #10 from Chris --- Maybe I have the same problem. Tested on ubuntu 13.04 and 13.10? my new HD6450 just gives me the same corrupted screen as yours. On windows, it works with no problem. (In reply to comment #4) > Created attachment 64641 [details] > Picture of screen corruption -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/b84a3eb3/attachment.html>
[PATCH] drm/radeon/dpm: fix typo in setting smc flag
PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH should be
set in extraFlags, not systemFlags.
Noticed-by: Sylvain BERTRAND
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/si_dpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index fc8b1ff..a24ada4 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -4558,7 +4558,7 @@ static int si_init_smc_table(struct radeon_device *rdev)
table->systemFlags |= PPSMC_SYSTEMFLAG_GDDR5;
if (rdev->pm.dpm.platform_caps &
ATOM_PP_PLATFORM_CAP_REVERT_GPIO5_POLARITY)
- table->systemFlags |=
PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH;
+ table->extraFlags |= PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH;
if (rdev->pm.dpm.platform_caps &
ATOM_PP_PLATFORM_CAP_VRHOT_GPIO_CONFIGURABLE) {
table->systemFlags |= PPSMC_SYSTEMFLAG_REGULATOR_HOT_PROG_GPIO;
--
1.8.3.1
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675
--- Comment #35 from Pierre Ossman ---
(In reply to comment #28)
> Created attachment 88450 [details] [review]
> use fractional fb div on DCE4+
>
> Does this patch help? This should allow the pll value to more closely match
> the actual requested clock.
Nope. Still glitches around 9 minutes.
The calculations in the table are off though, so I'm not surprised. With
corrected values it works fine. I also changed the algorithm to be able to
calculate these values properly:
static const struct radeon_hdmi_acr r600_hdmi_predefined_acr[] = {
/* 32kHz44.1kHz 48kHz*/
/* Clock N CTS N CTS N CTS */
{ 25175, 4096, 25175, 28224, 125875, 6144, 25175 }, /* 25,20/1.001
MHz */
{ 25200, 4096, 25200, 6272, 28000, 6144, 25200 }, /* 25.20
MHz */
{ 27000, 4096, 27000, 6272, 3, 6144, 27000 }, /* 27.00
MHz */
{ 27027, 4096, 27027, 6272, 30030, 6144, 27027 }, /* 27.00*1.001
MHz */
{ 54000, 4096, 54000, 6272, 6, 6144, 54000 }, /* 54.00
MHz */
{ 54054, 4096, 54054, 6272, 60060, 6144, 54054 }, /* 54.00*1.001
MHz */
{ 74176, 4096, 74176, 5733, 75335, 6144, 74176 }, /* 74.25/1.001
MHz */
{ 74250, 4096, 74250, 6272, 82500, 6144, 74250 }, /* 74.25
MHz */
{ 148352, 4096, 148352, 5733, 150670, 6144, 148352 }, /* 148.50/1.001
MHz */
{ 148500, 4096, 148500, 6272, 165000, 6144, 148500 }, /* 148.50
MHz */
};
/*
* calculate CTS and N values if they are not found in the table
*/
static void r600_hdmi_calc_cts(uint32_t clock, int *CTS, int *N, int freq)
{
int n, cts;
unsigned long div, mul;
/* Safe, but overly large values */
n = 128 * freq;
cts = clock * 1000;
/* Smallest valid fraction */
div = gcd(n, cts);
n /= div;
cts /= div;
/*
* The optimal N is 128*freq/1000. Calculate the closest larger
* value that doesn't truncate any bits.
*/
mul = ((128*freq/1000) + (n-1))/n;
n *= mul;
cts *= mul;
*N = n;
*CTS = cts;
DRM_DEBUG("Calculated ACR timing N=%d CTS=%d for frequency %d\n",
*N, *CTS, freq);
}
struct radeon_hdmi_acr r600_hdmi_acr(uint32_t clock)
{
struct radeon_hdmi_acr res;
u8 i;
/* Precalculated values for common clocks */
for (i = 0; i < ARRAY_SIZE(r600_hdmi_predefined_acr); i++) {
if (r600_hdmi_predefined_acr[i].clock == clock) {
return r600_hdmi_predefined_acr[i];
}
}
/* And odd clocks get manually calculated */
r600_hdmi_calc_cts(clock, _32khz, _32khz, 32000);
r600_hdmi_calc_cts(clock, _44_1khz, _44_1khz, 44100);
r600_hdmi_calc_cts(clock, _48khz, _48khz, 48000);
return res;
}
Two notes here:
1. The 25175 clock at 44.1 kHz is out of spec. There are no correct values to
make it in spec. So either change the clock, rely on hw calculated values, or
hope that sinks tolerate the large N.
2. None the N values for 44100 listed in the HDMI spec are optimal. Not sure
why, so I haven't changed them except where needed.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/5cec3741/attachment.html>
[PATCH] qxl: add a connector property to denote hotplug should rescan modes.
On Fri, Oct 11, 2013 at 6:21 PM, Daniel Vetter wrote: > On Fri, Oct 11, 2013 at 11:05:00AM +1000, Dave Airlie wrote: >> From: Dave Airlie >> >> So GNOME userspace has an issue with when it rescans for modes on hotplug >> events, if the monitor has no EDID it assumes that nothing has changed on >> EDID as with real hw we'd never have new modes without a new EDID, and they >> kind off rely on the behaviour now, however with virtual GPUs we would >> like to rescan the modes and get a new preferred mode on hotplug events >> to handle dynamic guest resizing (where you resize the host window and the >> guest resizes with it). >> >> This is a simple property we can make userspace watch for to trigger new >> behaviour based on it, and can be used to replaced EDID hacks in virtual >> drivers. >> >> Signed-off-by: Dave Airlie > > There's the related problem that we kinda don't tell userspace which > connectors exactly changed when sending out a hotplug event. We could > solve both issues with a hotplug_sequence counter that increments on any > change. Probably more work though ;-) Its kinda orthogonal problem though, I don't mind reprobing its more for the case where userspace does nothing when we have no EDID I need to fix. Dave.
[PATCH] DRM: Armada: convert to use simple_open()
This removes an open coded simple_open() function and replaces file
operations references to the function with simple_open() instead.
Signed-off-by: Duan Jiong
---
drivers/gpu/drm/armada/armada_debugfs.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_debugfs.c
b/drivers/gpu/drm/armada/armada_debugfs.c
index 612f375..471e456 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -95,15 +95,9 @@ static int armada_debugfs_write(struct file *file, const
char __user *ptr,
return len;
}
-static int armada_debugfs_reg_w_open(struct inode *inode, struct file *file)
-{
- file->private_data = inode->i_private;
- return 0;
-}
-
static const struct file_operations fops_reg_w = {
.owner = THIS_MODULE,
- .open = armada_debugfs_reg_w_open,
+ .open = simple_open,
.write = armada_debugfs_write,
.llseek = noop_llseek,
};
--
1.8.3.1
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #34 from Peter Fr?hberger --- I need something to regression test. With xbmc I can sync to the video clock and drop / dupe audio, when they are running into different directions. Example: Watching 1080i50 (was better with the SW patch): 14:26:12 T:140478137739008 WARNING: CDVDMessageQueue(audio)::Get - asked for new data packet, with nothing available 14:27:08 T:140478137739008 WARNING: Previous line repeats 10 times. 14:27:08 T:140478137739008 DEBUG: CDVDPlayerAudio:: Discontinuity1 - was:74579944528.817001, should be:74579839111.00, error:-105417.817001 1080p24 does not work reliable with the SW patch (that I told via mail). The pll patch you linked caused severe issues for some users, therefore I unapplied it. Btw. this was also quite curious with it: Without the pll clock patch I used radeontool to change the 0x05b4 from 1485000 to 1487500 which the pll clock should accomplish automatically - sadly it had other side effects. Best would really be some ms timer and play some audio / video stream and measure the length. Open for ideas here to track that down correctly, as the tests are quite a lot: 1080p24, 1080-24.0, 1080 at 50hz, 60hz, ac3, dts, lpcm, dts-hd. Without highjacking this thread - what about the register dumped I sent via Mail, it seems fglrx uses a 10 khz clock (relevant registers are factor 10) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/5edd0692/attachment.html>
smc table extra flag used in system flags
On Wed, Oct 30, 2013 at 9:33 PM, Sylvain BERTRAND wrote: > Hi, > > git branch drm-fixes-3.12, git commit > cdf6e8058415ba4d808537e30a0a6be9fb29e95a > > In si_dpm.c line 4557, the > PPSMC_EXTRAFLAGS_AC2DC_GPIO5_POLARITY_HIGH is ignored because it > is written in smc table systemFlags instead of the extraFlags. Good catch. I'll fix that up. Alex > > regards, > > -- > Sylvain > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #33 from Alex Deucher --- (In reply to comment #31) > As send via E-Mail, I told the same with 24.0 and 24p having these issues. > The "sw cts/n values" patch made audio drops with 50 / 60hz much better - > but I also have to admit: > > Reverting the "sw cts/n values" patch makes 24p working flawless again. > > > If it is not too late for 3.12 perhaps reverting the "sw cts/n values" patch > would be an option? Are you sure it was flawless? You had said you needed this patch: http://lists.freedesktop.org/archives/dri-devel/2013-October/047585.html to fix the audio playback in addition to using hw cts/n. That patch broke playback for a number of other users. So it doesn't seem to be completely fixed in either case. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/180fbbf7/attachment.html>
[PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
2013/11/1 Sean Paul :
> On Thu, Oct 31, 2013 at 6:30 AM, Inki Dae wrote:
>>
>>
>>> -Original Message-
>>> From: Sean Paul [mailto:seanpaul at chromium.org]
>>> Sent: Wednesday, October 30, 2013 1:13 AM
>>> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>>> Cc: airlied at linux.ie; tomasz.figa at gmail.com; marcheu at chromium.org;
>>> Sean
>>> Paul
>>> Subject: [PATCH v3 12/32] drm/exynos: Split manager/display/subdrv
>>>
>>> This patch splits display and manager from subdrv. The result is that
>>> crtc functions can directly call into manager callbacks and encoder
>>> functions can directly call into display callbacks. This will allow
>>> us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp
>>> with common code.
>>>
>>> Signed-off-by: Sean Paul
>>> ---
>>>
>>> Changes in v2:
>>> - Pass display into display_ops instead of context
>>> Changes in v3:
>>> - Changed vidi args to exynos_drm_display instead of void
>>> - Moved exynos_drm_hdmi.c removal into next patch
>>>
>>> drivers/gpu/drm/exynos/exynos_drm_connector.c | 50 ++---
>>> drivers/gpu/drm/exynos/exynos_drm_core.c | 181 +-
>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 115 +---
>>> drivers/gpu/drm/exynos/exynos_drm_crtc.h | 20 +-
>>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 29 +--
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 106 +++
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 258
>> --
>>>
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.h | 18 +-
>>> drivers/gpu/drm/exynos/exynos_drm_fb.c| 4 +-
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 161
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 211 +
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 2 +
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 15 +-
>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 129 ++---
>>> 14 files changed, 615 insertions(+), 684 deletions(-)
>>>
>>> static int exynos_drm_create_enc_conn(struct drm_device *dev,
>>> - struct exynos_drm_subdrv *subdrv)
>>> + struct exynos_drm_display *display)
>>> {
>>> struct drm_encoder *encoder;
>>> struct drm_connector *connector;
>>> + struct exynos_drm_manager *manager;
>>> int ret;
>>> + unsigned long possible_crtcs = 0;
>>>
>>> - subdrv->manager->dev = subdrv->dev;
>>> + /* Find possible crtcs for this display */
>>> + list_for_each_entry(manager, _drm_manager_list, list)
>>> + if (manager->type == display->type)
>>> + possible_crtcs |= 1 << manager->pipe;
>>>
>>> /* create and initialize a encoder for this sub driver. */
>>> - encoder = exynos_drm_encoder_create(dev, subdrv->manager,
>>> - (1 << MAX_CRTC) - 1);
>>> + encoder = exynos_drm_encoder_create(dev, display, possible_crtcs);
>>> if (!encoder) {
>>> DRM_ERROR("failed to create encoder\n");
>>> return -EFAULT;
>>> }
>>> - subdrv->encoder = encoder;
>>> + display->encoder = encoder;
>>>
>>> - if (subdrv->manager->display_ops->type == EXYNOS_DISPLAY_TYPE_LCD)
>>> {
>>> + if (display->type == EXYNOS_DISPLAY_TYPE_LCD) {
>>> ret = exynos_drm_attach_lcd_bridge(dev, encoder);
>>
>> The lvds bridge related codes need more reviews
>
> I think everyone agrees that there need not be a 1:1 binding to driver
> relationship, so what is left to discuss?
>
I also agree to that no 1:1 binding. But this way it's not clear to me
yet. For this, I already commented that I'll try to find a better way
to you. So know that it's not that I don't agree to this way. If there
is no any better way, then I'll merge this lvds support to top of the
re-factoring patch series. any problem? I'd really like to focus on
the re-factoring patch series as of now. And we also have other patch
series to should be reviewed. BTW, did Dave accept that lvds driver?
This lvds driver should be placed in drivers/gpu/drm/bridge/.
Thanks,
Inki Dae
> Sean
>
>
>
>> so I'll merge this patch
>> manually excepting the lvds bridge related codes. Let's discuss lvds bridge
>> later.
>>
>> Thanks,
>> Inki Dae
>>
>>> if (ret)
>>> return 0;
>>> @@ -91,7 +98,7 @@ static int exynos_drm_create_enc_conn(struct drm_device
>>> *dev,
>>> goto err_destroy_encoder;
>>> }
>>>
>>> - subdrv->connector = connector;
>>> + display->connector = connector;
>>>
>>> return 0;
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 samit vats changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/96bbfa32/attachment.html>
[Bug 69463] RadeonSI : xserver crashes with Segmentation Fault
https://bugs.freedesktop.org/show_bug.cgi?id=69463 --- Comment #15 from samit vats --- The issue is fixed with following configuration Mesa : 723f047a3bc21b536d27ab1c0d6cc82f93002648(2013-10-31) glamor : 16c86bd3d8ba92c50fc96efb5a39a7725a16d785(2013-10-19) xf86-video-ati : f1dc677e79cd7a88d7379a934ebc7d87a3b18805(2013-10-01) with xorg-server-1.14.3 Hence closing the Bug -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/f3bcb057/attachment.html>
dma-buf non-coherent mmap
On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach wrote: > GStreamer needs _some_ way of accessing the buffer contents with the > CPU, this doesn't necessarily have to be the dumb mmap we have right > now. > DMA-BUF support in GSt is not really finished (I know we have a lot of > patches internally to make it actually work with anything, which are > trickling upstream right now), so this might be a good time to hammer > out how it should be done, so we can adapt GSt before people start to > rely on the dma-buf fallback mmap. > > I would think the bracketed mmap idea that was thrown around by Rob some > time ago when the mmap topic first surfaced is simple enough that we > don't need additional userspace helpers and should be enough to make the > coherency issue disappear. Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap stuff and simply demand that userspace calls that we'd have something half-sane at least. Since we currently don't really have any real users we could still do this abi change I think. One open issue is whether the BEGIN_MMAP ioctl should also synchronize with any outstanding gpu access. Imo it should, since that's pretty much how all the current drm drivers work, but maybe we should reserve space for a few flags so that this can be extended later on - Android seems to be pretty insistent on using explicit syncpoints everywhere instead of implicit synchronization. Or maybe we should have the flag already, but reject implicit syncing until Maarten's dma_fence stuff is in and enabled, dunno. Adding him to cc. The clear thing otoh is that these two ioctls should only serve as barriers, not as locks as has been proposed in some other RFCs floating around (iirc the one from exynos was borked in this fashion). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
dma-buf non-coherent mmap
Am Donnerstag, den 31.10.2013, 20:57 -0400 schrieb Rob Clark: > On Thu, Oct 31, 2013 at 8:37 PM, Jakob Bornecrantz > wrote: > > On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark wrote: > >> On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz >> gmail.com> wrote: > >>> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote: > On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote: > > On 10/31/2013 09:48 PM, Dave Airlie wrote: > > >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom > >vmware.com> wrote: > > >>Well, I'd be happy to avoid mmap, but then what does optional mean in > > >>this > > >>context? > > >>That all generic user-space apps *must* implement a workaround if > > >>mmap isn't > > >>implemented? > > >> > > >>It's unfortunate a bit like implicit synchronization mentioned in > > >>section 3) > > >>in Direct Userspace Access/mmap Support > > >>in the kernel dma-buf doc: It should be avoided, otherwise it might be > > >>relied upon by userspace and exporters > > >>not implementing it will suffer. > > >> > > >>In reality, people will start using mmap() and won't care to implement > > >>workarounds if it's not supported, and drivers like > > >>vmwgfx and non-coherent architectures will suffer. > > >> > > >>I haven't looked closely at how DRI3 or Wayland/weston use or will use > > >>dma-buf, but if they rely on mmap, we're sort > > >>of lost. MIR uses the following scheme: > > >DRI3 and wayland won't use dma-buf mmap directly, > > > > > >using dma-buf mmap directly is wrong for anything that shares objects > > >with itself. > > > > That sounds good to hear. Perhaps we should add that to the dma-buf > > docs. > > Userspace mmap was essentially added as a concession to the android ion > guys since they really, really wanted it. We've tried to tell them that > it's a horrible idea (see all the fun with coherency and syncing), but > they said that they have userspace for it already and so we let it be. > > Imo if you're not running Android userspace there's no need for this at > all. > >>> > >>> But now it turns out that gstreamer is using it and our life is hell. We > >>> should > >>> have made it not work for _any_ driver if CONFIG_ANDRIOD wasn't set. > >> > >> well, at the moment mmap is only implemented by a few of the arm > >> drivers, from the looks of it. So I guess in the near term it is > >> mostly going to be of interest to the SoC crowd. > > > > Ah okay, I thought this was desktop gstreamer. > > GStreamer needs _some_ way of accessing the buffer contents with the CPU, this doesn't necessarily have to be the dumb mmap we have right now. DMA-BUF support in GSt is not really finished (I know we have a lot of patches internally to make it actually work with anything, which are trickling upstream right now), so this might be a good time to hammer out how it should be done, so we can adapt GSt before people start to rely on the dma-buf fallback mmap. I would think the bracketed mmap idea that was thrown around by Rob some time ago when the mmap topic first surfaced is simple enough that we don't need additional userspace helpers and should be enough to make the coherency issue disappear. > >> Not sure about the long term, perhaps we should see about > >> turning gallium pipe_transfer/map stuff into a kernel interface > >> (ioctl's directly on the dmabuf fd, perhaps?) > > > > Or they could just create a OpenGL context, I know it sounds heavy weight. > > But somebody will eventually want to synchronize this with a different > > client > > API in a non-blocking way. And OpenGL or some other Khronos API already > > have that integration, no real need to reinvent the wheel. Then again I > > think > > both GBM and DRI have hooks for mapping and unmapping buffers, so those > > might suffice. > > GL(ES) context might be a bit of a PITA, at least until open src mesa > drivers are a bit more common in arm world. But not really against a > userspace API.. wonder how hard that would be to stuff in GBM? At > least that is a simple enough API that some sort of null-gbm "driver" > could be made for folks who don't have GL(ES).. > I already see the need for a dumb GBM driver for importing buffers into plain KMS drivers, so we can stick them on a plane or something. The only thing that crashes in here is GBM being a part of MESA. We certainly don't want GStreamer to depend on MESA just to access some buffers the right way. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH 4/6] dri/intel: Add intel_fd_for_region
On Thu, Oct 31, 2013 at 04:13:14PM -0700, Keith Packard wrote:
> Returns a prime file descriptor for the specified region.
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/i915/intel_regions.c | 13 +
> src/mesa/drivers/dri/i915/intel_regions.h | 4
> src/mesa/drivers/dri/i965/intel_regions.c | 13 +
> src/mesa/drivers/dri/i965/intel_regions.h | 4
> 4 files changed, 34 insertions(+)
Makes sense. We should use that in intel_query_image() instead of
calling drm_intel_bo_gem_export_to_prime() directly on
image->region->bo.
Reviewed-by: Kristian H?gsberg
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.c
> b/src/mesa/drivers/dri/i915/intel_regions.c
> index 9f5b89e..bac997d 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.c
> +++ b/src/mesa/drivers/dri/i915/intel_regions.c
> @@ -238,6 +238,19 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> return region;
> }
>
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region)
> +{
> + int fd;
> + int ret;
> +
> + ret = drm_intel_bo_gem_export_to_prime(region->bo, );
> + if (ret < 0)
> + return ret;
> + return fd;
> +}
> +
> void
> intel_region_reference(struct intel_region **dst, struct intel_region *src)
> {
> diff --git a/src/mesa/drivers/dri/i915/intel_regions.h
> b/src/mesa/drivers/dri/i915/intel_regions.h
> index 6bc4a42..84c013a 100644
> --- a/src/mesa/drivers/dri/i915/intel_regions.h
> +++ b/src/mesa/drivers/dri/i915/intel_regions.h
> @@ -93,6 +93,10 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint width, GLuint height, GLuint pitch,
>GLuint size, int fd, const char *name);
>
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region);
> +
> bool
> intel_region_flink(struct intel_region *region, uint32_t *name);
>
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.c
> b/src/mesa/drivers/dri/i965/intel_regions.c
> index 3920f4f..2e70326 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.c
> +++ b/src/mesa/drivers/dri/i965/intel_regions.c
> @@ -238,6 +238,19 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
> return region;
> }
>
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region)
> +{
> + int fd;
> + int ret;
> +
> + ret = drm_intel_bo_gem_export_to_prime(region->bo, );
> + if (ret < 0)
> + return ret;
> + return fd;
> +}
> +
> void
> intel_region_reference(struct intel_region **dst, struct intel_region *src)
> {
> diff --git a/src/mesa/drivers/dri/i965/intel_regions.h
> b/src/mesa/drivers/dri/i965/intel_regions.h
> index 05dfef3..f471b94 100644
> --- a/src/mesa/drivers/dri/i965/intel_regions.h
> +++ b/src/mesa/drivers/dri/i965/intel_regions.h
> @@ -95,6 +95,10 @@ intel_region_alloc_for_fd(struct intel_screen *screen,
>GLuint size,
>int fd, const char *name);
>
> +int
> +intel_fd_for_region(struct intel_screen *screen,
> +struct intel_region *region);
> +
> bool
> intel_region_flink(struct intel_region *region, uint32_t *name);
>
> --
> 1.8.4.2
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951=/4140/ostg.clktrk
> --
> ___
> Dri-devel mailing list
> Dri-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] dri/intel: Split out DRI2 buffer update code to separate function
On Thu, Oct 31, 2013 at 04:13:12PM -0700, Keith Packard wrote:
> Make an easy place to splice in a DRI3 version of this function
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/i915/intel_context.c | 90
> +--
> src/mesa/drivers/dri/i965/brw_context.c | 22 ++--
> 2 files changed, 68 insertions(+), 44 deletions(-)
Reviewed-by: Kristian H?gsberg
> diff --git a/src/mesa/drivers/dri/i915/intel_context.c
> b/src/mesa/drivers/dri/i915/intel_context.c
> index 2748514..1798bc7 100644
> --- a/src/mesa/drivers/dri/i915/intel_context.c
> +++ b/src/mesa/drivers/dri/i915/intel_context.c
> @@ -133,15 +133,58 @@ intel_process_dri2_buffer(struct intel_context *intel,
> struct intel_renderbuffer *rb,
> const char *buffer_name);
>
> -void
> -intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
> +static void
> +intel_update_dri2_buffers(struct intel_context *intel, __DRIdrawable
> *drawable)
> {
> - struct gl_framebuffer *fb = drawable->driverPrivate;
> - struct intel_renderbuffer *rb;
> - struct intel_context *intel = context->driverPrivate;
> __DRIbuffer *buffers = NULL;
> int i, count;
> const char *region_name;
> + struct intel_renderbuffer *rb;
> + struct gl_framebuffer *fb = drawable->driverPrivate;
> +
> + intel_query_dri2_buffers(intel, drawable, , );
> +
> + if (buffers == NULL)
> + return;
> +
> + for (i = 0; i < count; i++) {
> + switch (buffers[i].attachment) {
> + case __DRI_BUFFER_FRONT_LEFT:
> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> + region_name = "dri2 front buffer";
> + break;
> +
> + case __DRI_BUFFER_FAKE_FRONT_LEFT:
> + rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> + region_name = "dri2 fake front buffer";
> + break;
> +
> + case __DRI_BUFFER_BACK_LEFT:
> + rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
> + region_name = "dri2 back buffer";
> + break;
> +
> + case __DRI_BUFFER_DEPTH:
> + case __DRI_BUFFER_HIZ:
> + case __DRI_BUFFER_DEPTH_STENCIL:
> + case __DRI_BUFFER_STENCIL:
> + case __DRI_BUFFER_ACCUM:
> + default:
> + fprintf(stderr,
> + "unhandled buffer attach event, attachment type %d\n",
> + buffers[i].attachment);
> + return;
> + }
> +
> + intel_process_dri2_buffer(intel, drawable, [i], rb,
> region_name);
> + }
> +}
> +
> +void
> +intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
> +{
> + struct intel_context *intel = context->driverPrivate;
> + __DRIscreen *screen = intel->intelScreen->driScrnPriv;
>
> /* Set this up front, so that in case our buffers get invalidated
> * while we're getting new buffers, we don't clobber the stamp and
> @@ -151,42 +194,7 @@ intel_update_renderbuffers(__DRIcontext *context,
> __DRIdrawable *drawable)
> if (unlikely(INTEL_DEBUG & DEBUG_DRI))
>fprintf(stderr, "enter %s, drawable %p\n", __func__, drawable);
>
> - intel_query_dri2_buffers(intel, drawable, , );
> -
> - if (buffers == NULL)
> - return;
> -
> - for (i = 0; i < count; i++) {
> - switch (buffers[i].attachment) {
> - case __DRI_BUFFER_FRONT_LEFT:
> -rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> -region_name = "dri2 front buffer";
> -break;
> -
> - case __DRI_BUFFER_FAKE_FRONT_LEFT:
> -rb = intel_get_renderbuffer(fb, BUFFER_FRONT_LEFT);
> -region_name = "dri2 fake front buffer";
> -break;
> -
> - case __DRI_BUFFER_BACK_LEFT:
> -rb = intel_get_renderbuffer(fb, BUFFER_BACK_LEFT);
> -region_name = "dri2 back buffer";
> -break;
> -
> - case __DRI_BUFFER_DEPTH:
> - case __DRI_BUFFER_HIZ:
> - case __DRI_BUFFER_DEPTH_STENCIL:
> - case __DRI_BUFFER_STENCIL:
> - case __DRI_BUFFER_ACCUM:
> - default:
> -fprintf(stderr,
> -"unhandled buffer attach event, attachment type %d\n",
> -buffers[i].attachment);
> -return;
> - }
> -
> - intel_process_dri2_buffer(intel, drawable, [i], rb,
> region_name);
> - }
> + intel_update_dri2_buffers(intel, drawable);
>
> driUpdateFramebufferSize(>ctx, drawable);
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index 38147e9..c213b31 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -929,12 +929,11 @@ intel_process_dri2_buffer(struct brw_context *brw,
>struct intel_renderbuffer *rb,
>const char *buffer_name);
>
> -void
> -intel_update_renderbuffers(__DRIcontext *context, __DRIdrawable *drawable)
> +static void
> +intel_update_dri2_buffers(struct brw_context *brw,
[PATCH 1/6] drivers/dri/common: A few dri2 functions are not actually DRI2 specific
On Thu, Oct 31, 2013 at 04:13:11PM -0700, Keith Packard wrote:
> This just renames them so that they can be used with the DRI3 extension
> without causing too much confusion.
>
> Signed-off-by: Keith Packard
> ---
> src/mesa/drivers/dri/common/dri_util.c | 50
> +-
> 1 file changed, 25 insertions(+), 25 deletions(-)
Reviewed-by: Kristian H?gsberg
> diff --git a/src/mesa/drivers/dri/common/dri_util.c
> b/src/mesa/drivers/dri/common/dri_util.c
> index c28b0fc..539fb4b 100644
> --- a/src/mesa/drivers/dri/common/dri_util.c
> +++ b/src/mesa/drivers/dri/common/dri_util.c
> @@ -291,13 +291,13 @@ validate_context_version(__DRIscreen *screen,
> /*@{*/
>
> static __DRIcontext *
> -dri2CreateContextAttribs(__DRIscreen *screen, int api,
> - const __DRIconfig *config,
> - __DRIcontext *shared,
> - unsigned num_attribs,
> - const uint32_t *attribs,
> - unsigned *error,
> - void *data)
> +driCreateContextAttribs(__DRIscreen *screen, int api,
> +const __DRIconfig *config,
> +__DRIcontext *shared,
> +unsigned num_attribs,
> +const uint32_t *attribs,
> +unsigned *error,
> +void *data)
> {
> __DRIcontext *context;
> const struct gl_config *modes = (config != NULL) ? >modes : NULL;
> @@ -442,22 +442,22 @@ dri2CreateContextAttribs(__DRIscreen *screen, int api,
> }
>
> static __DRIcontext *
> -dri2CreateNewContextForAPI(__DRIscreen *screen, int api,
> -const __DRIconfig *config,
> -__DRIcontext *shared, void *data)
> +driCreateNewContextForAPI(__DRIscreen *screen, int api,
> + const __DRIconfig *config,
> + __DRIcontext *shared, void *data)
> {
> unsigned error;
>
> -return dri2CreateContextAttribs(screen, api, config, shared, 0, NULL,
> - , data);
> +return driCreateContextAttribs(screen, api, config, shared, 0, NULL,
> + , data);
> }
>
> static __DRIcontext *
> -dri2CreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
> - __DRIcontext *shared, void *data)
> +driCreateNewContext(__DRIscreen *screen, const __DRIconfig *config,
> +__DRIcontext *shared, void *data)
> {
> -return dri2CreateNewContextForAPI(screen, __DRI_API_OPENGL,
> - config, shared, data);
> +return driCreateNewContextForAPI(screen, __DRI_API_OPENGL,
> + config, shared, data);
> }
>
> /**
> @@ -609,9 +609,9 @@ static void dri_put_drawable(__DRIdrawable *pdp)
> }
>
> static __DRIdrawable *
> -dri2CreateNewDrawable(__DRIscreen *screen,
> - const __DRIconfig *config,
> - void *data)
> +driCreateNewDrawable(__DRIscreen *screen,
> + const __DRIconfig *config,
> + void *data)
> {
> __DRIdrawable *pdraw;
>
> @@ -698,7 +698,7 @@ dri2ConfigQueryf(__DRIscreen *screen, const char *var,
> GLfloat *val)
> }
>
> static unsigned int
> -dri2GetAPIMask(__DRIscreen *screen)
> +driGetAPIMask(__DRIscreen *screen)
> {
> return screen->api_mask;
> }
> @@ -741,13 +741,13 @@ const __DRIdri2Extension driDRI2Extension = {
> .base = { __DRI_DRI2, 4 },
>
> .createNewScreen= dri2CreateNewScreen,
> -.createNewDrawable = dri2CreateNewDrawable,
> -.createNewContext = dri2CreateNewContext,
> -.getAPIMask = dri2GetAPIMask,
> -.createNewContextForAPI = dri2CreateNewContextForAPI,
> +.createNewDrawable = driCreateNewDrawable,
> +.createNewContext = driCreateNewContext,
> +.getAPIMask = driGetAPIMask,
> +.createNewContextForAPI = driCreateNewContextForAPI,
> .allocateBuffer = dri2AllocateBuffer,
> .releaseBuffer = dri2ReleaseBuffer,
> -.createContextAttribs = dri2CreateContextAttribs,
> +.createContextAttribs = driCreateContextAttribs
> .createNewScreen2 = dri2CreateNewScreen2,
> };
>
> --
> 1.8.4.2
>
>
> --
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951=/4140/ostg.clktrk
> --
> ___
> Dri-devel mailing list
> Dri-devel at lists.sourceforge.net
>
outcome of DRM/KMS DT bindings session
On Fri, Nov 01, 2013 at 10:10:41AM +1000, Dave Airlie wrote: > >> After looking at some of the ordering issues we've had with x86 GPUs > >> (which are really just a tightly coupled SoC) I don't want separate > >> drivers all having their own init, suspend/resume paths in them as I > >> know we'll have to start making special vtable entry points etc to > >> solve some random ordering issues that crop up. > > > > The DRM device has to be initialized/suspended/resumed as a whole, no > > doubt about that. If that's not the case you indeed open up the door for > > all kinds of ordering issues. > > > > Still the different components can be multiple devices, just initialize > > the drm device once all components are probed. Remove it again once a > > component is removed. Handle suspend in the DRM device, not in > > the individual component drivers. The suspend in the component drivers > > would only be called after the DRM device is completely quiesced. > > Similarly the resume in the component drivers would not reenable the > > components, this instead would be done in the DRM device when all > > components are there again. > > But why? why should we have separate drivers for each component of a > tightly coupled SoC? > > it makes no sense, having a driver node per every block in the chip > isn't an advantage, it complicates > things for no advantage at all. If we don't have hotplug hw removing > one device shouldn't be possible > this idea that removing a sub-driver should teardown the drm is crazy as well. In my opinion separating things out into separate drivers makes it less complicated. For instance it makes it very easy to manage the various resources used by each driver (registers, interrupts, ...). The only added complexity lies in the fact that we need some code to synchronize the DRM device setup and teardown (and suspend and resume for that matter). It's been discussed elsewhere that most SoCs are very similar in their requirements, so I think we should be able to come up with a piece of code that can be shared between drivers. Perhaps it would even be possible to share that code between subsystems, since ALSA and V4L2 may have similar requirements. That's effectively not very different from what you're proposing. As far as I can tell the only difference would be that this works in sort of a "bottom-up" fashion, whereas your proposal would be "top-down". Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/7108e206/attachment.pgp>
outcome of DRM/KMS DT bindings session
>> After looking at some of the ordering issues we've had with x86 GPUs >> (which are really just a tightly coupled SoC) I don't want separate >> drivers all having their own init, suspend/resume paths in them as I >> know we'll have to start making special vtable entry points etc to >> solve some random ordering issues that crop up. > > The DRM device has to be initialized/suspended/resumed as a whole, no > doubt about that. If that's not the case you indeed open up the door for > all kinds of ordering issues. > > Still the different components can be multiple devices, just initialize > the drm device once all components are probed. Remove it again once a > component is removed. Handle suspend in the DRM device, not in > the individual component drivers. The suspend in the component drivers > would only be called after the DRM device is completely quiesced. > Similarly the resume in the component drivers would not reenable the > components, this instead would be done in the DRM device when all > components are there again. But why? why should we have separate drivers for each component of a tightly coupled SoC? it makes no sense, having a driver node per every block in the chip isn't an advantage, it complicates things for no advantage at all. If we don't have hotplug hw removing one device shouldn't be possible this idea that removing a sub-driver should teardown the drm is crazy as well. > > This way all components could be proper (driver model)devices with > proper drivers without DRM even noticing that multiple components are > involved. > > Side note: We have no choice anyway. All SoCs can (sometimes must) > be extended with external I2C devices. On every SoC the I2C bus master > is a separate device, so we have a multicomponent device (in the sense > of driver model) already in many cases. > Having off-chip i2c devices being part of the driver model is fine, stuff works like that everywhere, having each SoC block part of the device model isn't fine unless you can really prove re-use and why having separate driver templating for each block is helpful. I'm not willing to have overly generic sub drivers that provide no advantage and only add lots of disadvantage like init and suspend/resume ordering. I know there is going to be SoC ordering issues at init time that will end up circular between two separate drivers each deferring because they want another driver up. Don't dig us into that hole, i2c has a well defined ordering of init, I don't think internal SoC devices are so well defined. Dave.
dma-buf non-coherent mmap
On Fri, Nov 1, 2013 at 6:17 AM, Daniel Vetter wrote: > On Fri, Nov 1, 2013 at 11:03 AM, Lucas Stach > wrote: >> GStreamer needs _some_ way of accessing the buffer contents with the >> CPU, this doesn't necessarily have to be the dumb mmap we have right >> now. >> DMA-BUF support in GSt is not really finished (I know we have a lot of >> patches internally to make it actually work with anything, which are >> trickling upstream right now), so this might be a good time to hammer >> out how it should be done, so we can adapt GSt before people start to >> rely on the dma-buf fallback mmap. >> >> I would think the bracketed mmap idea that was thrown around by Rob some >> time ago when the mmap topic first surfaced is simple enough that we >> don't need additional userspace helpers and should be enough to make the >> coherency issue disappear. > > Yeah, if we add a BEGIN_MMAP/END_MMAP ioctl or so to the dma-buf mmap > stuff and simply demand that userspace calls that we'd have something > half-sane at least. Since we currently don't really have any real > users we could still do this abi change I think. > > One open issue is whether the BEGIN_MMAP ioctl should also synchronize > with any outstanding gpu access. Imo it should, since that's pretty > much how all the current drm drivers work, but maybe we should reserve > space for a few flags so that this can be extended later on - Android > seems to be pretty insistent on using explicit syncpoints everywhere > instead of implicit synchronization. Or maybe we should have the flag > already, but reject implicit syncing until Maarten's dma_fence stuff > is in and enabled, dunno. Adding him to cc. I suppose I wouldn't mind if we made BEGIN/END_MMAP as sort of clones of the CPU_PREP/FINI ioctls I have in msm.. where the CPU_PREP takes a flag/bitmask to indicate READ/WRITE/NOSYNC That doesn't really help with partial buffer access, like you'd get if you were using the buffer for vertex upload. Although not really sure if we'd be seeing dmabuf's for that sort of use-case. We could make a more elaborate kernel interface that maps better to all the different cases in pipe_transfer. Or we could just say that that is overkill. I don't really have strong opinion about that (so someone who does, send an RFC). But I do agree with the "barriers only, not locks". BR, -R > The clear thing otoh is that these two ioctls should only serve as > barriers, not as locks as has been proposed in some other RFCs > floating around (iirc the one from exynos was borked in this fashion). > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Friday, November 01, 2013 8:27 AM, Tomasz Figa wrote: > On Friday 01 of November 2013 08:23:59 Jingoo Han wrote: > > On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote: > > > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote: > > > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote: > > > > > CCing Jingoo, > > > > > > > > > > Is that ok to remove eDP driver from video/exynos? Isn't this > > > > > driver > > > > > really used by Linux framebuffer driver, s3c-fb.c? > > > > > > > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, > > > > > > > > linux-fbdev list, linux-samsung-soc list > > > > > > > > Yes, it is used by s3c-fb.c. > > > > > > > > > Of course, now s3c-fb driver is dead code because this driver > > > > > doesn't > > > > > support device tree yet but we would need more reviews and > > > > > discussions > > > > > about moving this driver into drm side. Let's watch new rules for > > > > > device tree bindings of DRM world. So I'd not like to merge this > > > > > driver yet. > > > > > > > > 's3c-fb' driver is still used for other mass products projects. > > > > Just, device tree support patch is not yet submitted. > > > > > > Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx > > > and > > > all s5p* SoCs. It is not used on Exynos SoCs anymore. > > > > Hi Tomasz Figa, > > Just Tomasz. ;) Hi Tomasz, :-) > > > Some mass product projects using Exynos5250 and etc, use s3c-fb driver > > and dp driver. Also, these projects are still using Framebuffer, not > > DRM. > > Well, those are based on vendor trees anyway, so do not really affect > mainline kernel. OK, I see. > > > > As for Exynos DP driver, what SoCs does it support? If only Exynos (as > > > the name suggests) then there is no point in keeping it at > > > video/exynos and making it a part of Exynos DRM driver seems > > > reasonable to me. > > > > However, when considering only mainline kernel, I have no strong > > objection. As you know, many Linux kernel based OS projects using > > Exynos, are using DRM, not Framebuffer. > > Generally, fbdev is strongly discouraged in any new systems and DRM is the > way to go, so I don't think we should ever want to bring s3c-fb support > back to Exynos platforms. Yes, you're right. Personally, I think that all Exynos platforms should go into DRM, not FB. One more thing, then how about moving Exynos MIPI to DRM side? Is there any plan on Exynos MIPI? Best regards, Jingoo Han > > > > > Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver > > should be updated, too. > > That's correct.
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #32 from Peter Fr?hberger --- To add: I tested with http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de926800b155886c61b06146e28c0ba2e6fafc39 reverted and use "fractional fb div on DCE4+" applied -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/5727cd1a/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #31 from Peter Fr?hberger --- As send via E-Mail, I told the same with 24.0 and 24p having these issues. The "sw cts/n values" patch made audio drops with 50 / 60hz much better - but I also have to admit: Reverting the "sw cts/n values" patch makes 24p working flawless again. If it is not too late for 3.12 perhaps reverting the "sw cts/n values" patch would be an option? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/01757ce5/attachment.html>
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote: > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote: > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote: > > > CCing Jingoo, > > > > > > Is that ok to remove eDP driver from video/exynos? Isn't this driver > > > really used by Linux framebuffer driver, s3c-fb.c? > > > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, > > linux-fbdev list, linux-samsung-soc list > > > > Yes, it is used by s3c-fb.c. > > > > > Of course, now s3c-fb driver is dead code because this driver doesn't > > > support device tree yet but we would need more reviews and discussions > > > about moving this driver into drm side. Let's watch new rules for > > > device tree bindings of DRM world. So I'd not like to merge this > > > driver yet. > > 's3c-fb' driver is still used for other mass products projects. > > Just, device tree support patch is not yet submitted. > > Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx and > all s5p* SoCs. It is not used on Exynos SoCs anymore. Hi Tomasz Figa, Some mass product projects using Exynos5250 and etc, use s3c-fb driver and dp driver. Also, these projects are still using Framebuffer, not DRM. > > As for Exynos DP driver, what SoCs does it support? If only Exynos (as the > name suggests) then there is no point in keeping it at video/exynos and > making it a part of Exynos DRM driver seems reasonable to me. However, when considering only mainline kernel, I have no strong objection. As you know, many Linux kernel based OS projects using Exynos, are using DRM, not Framebuffer. Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver should be updated, too. Best regards, Jingoo Han
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote: > > CCing Jingoo, > > Is that ok to remove eDP driver from video/exynos? Isn't this driver really > used by Linux framebuffer driver, s3c-fb.c? +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, linux-fbdev list, linux-samsung-soc list Yes, it is used by s3c-fb.c. > > Of course, now s3c-fb driver is dead code because this driver doesn't > support device tree yet but we would need more reviews and discussions about > moving this driver into drm side. Let's watch new rules for device tree > bindings of DRM world. So I'd not like to merge this driver yet. 's3c-fb' driver is still used for other mass products projects. Just, device tree support patch is not yet submitted. Sean Paul, When moving the driver, notify related Maintainers of that driver. Please use 'scripts/get_maintainer.pl' next time. Best regards, Jingoo Han
dma-buf non-coherent mmap
On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom wrote: > On 10/31/2013 06:52 PM, Rob Clark wrote: >> >> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom >> wrote: >>> >>> Hi! >>> >>> I'm just looking over what's needed to implement drm Prime / dma-buf >>> exports >>> + imports in the vmwgfx driver. It seems like most dma-bufs ops are quite >>> straightforward to implement except user-space mmap(). >>> >>> The reason being that vmwgfx dma-bufs will be using completely >>> non-coherent >>> memory, whenever there needs to be CPU accesses. >>> >>> The accelerated contents resides in an opaque structure on the device >>> into >>> which we can DMA to and from, so for mmap to work we need to zap ptes and >>> DMA to the device when doing something accelerated, and on the first >>> page-fault DMA data back and wait for idle if the device did a write to >>> the >>> dma-buf. >>> >>> Now this shouldn't really be a problem if dma-bufs were only used for >>> cross-device sharing, but since people apparently want to use dma-buf >>> file >>> handles to share CPU data between processes it really becomes a serious >>> problem. >>> >>> Needless to say we'd want to limit the size of the DMAs, and have mmap >>> users >>> request regions for read, and mark regions dirty for write, something >>> similar to gallium's texture transfer objects. >>> >>> Any ideas? >> >> well, I think vmwgfx is part of the reason we decided mmap would be >> optional for dmabuf. So perhaps it is an option to simply ignore >> mmap? >> >> BR, >> -R > > > Well, I'd be happy to avoid mmap, but then what does optional mean in this > context? > That all generic user-space apps *must* implement a workaround if mmap isn't > implemented? > > It's unfortunate a bit like implicit synchronization mentioned in section 3) > in Direct Userspace Access/mmap Support > in the kernel dma-buf doc: It should be avoided, otherwise it might be > relied upon by userspace and exporters > not implementing it will suffer. > > In reality, people will start using mmap() and won't care to implement > workarounds if it's not supported, and drivers like > vmwgfx and non-coherent architectures will suffer. > > I haven't looked closely at how DRI3 or Wayland/weston use or will use > dma-buf, but if they rely on mmap, we're sort > of lost. MIR uses the following scheme: DRI3 and wayland won't use dma-buf mmap directly, using dma-buf mmap directly is wrong for anything that shares objects with itself. I personally wish we hadn't added mmap support to dma-buf at all, but some people had some use cases that they'll never implement. If you export a dma-buf to be used by a client it should be using drivers on the client to import the dma-buf and then it should be using mesa. Dave.
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #147 from Bryan Quigley <gquigs+bugs at gmail.com> --- Tried again with latest git. Issue still exists. Any other troubleshooting to try? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/9738c85c/attachment.html>
[Bug 70675] steam error dialogs are garbled
https://bugs.freedesktop.org/show_bug.cgi?id=70675 --- Comment #5 from Alexandre Demers --- I just tested the patch on my HD 6950 and it fixes the visual bug. Can the patch be pushed in the ddx tree? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/8bfc6f26/attachment-0001.html>
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
01.11.2013 01:38, Rafa? Mi?ecki kirjoitti: > 2013/10/29 Anssi Hannula : >> Because of this, only the 2-channel SAD may be used if it appears before >> the 8-channel SAD. Unless other SADs require otherwise, this may cause >> the ALSA HDA driver to allow stereo playback only. > > I can confirm that the problem exists. My SADs (Onkyo TX-SR605): > Format: 1 (PCM)Channels:1Freq:0x7F (32-192)B2:0x07 (16-24b) > Format: 1 (PCM)Channels:7Freq:0x7F (32-192)B2:0x07 (16-24b) > Format: 2 (AC3)Channels:7Freq:0x07 (32-48)B2:0x50 (640?) > Format: 7 (DTS)Channels:7Freq:0x06 (44-48)B2:0xC0 (1536?) > Format: 10 (EAC3)Channels:7Freq:0x06 (44-48)B2:0x00 > Format: 11 (DTS_HD)Channels:7Freq:0x7E (44-192)B2:0x01 > Format: 12 (MLP)Channels:7Freq:0x1E (44-96)B2:0x00 > > Unfortunately I get only 1 emulated SAD entry for PCM > (/proc/asound/card1/eld#0.0): > sad0_coding_type[0x1] LPCM > sad0_channels 2 > sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 > sad0_bits [0xe] 16 20 24 > > So I can not play 8 channel LPCM "legally" (without forcing player to do so). > > >> Fix the code to pick the PCM SAD with the highest number of channels, >> while merging the rate masks of PCM SADs with lower amount of channels >> into the additional stereo rate mask byte. > > Does it mean that now instead of 2 real SADs: > 1) 192kHz support for 2 channels > 2) 96kHz support for 8 channels > you will only get: > 1) 192kHz support for 8 channels > ? No, the SADs will be separated again by the ATI/AMD ELD generator in hda_eld.c (as the 4th byte in the register contains the PCM stereo rate mask). I.e., assuming a receiver with 96kHz PCM multichannel limitation, with the patch the video-side sets the three standard SAD bytes according to the SAD with the highest number of channels (8ch+96kHz+24b), and the extra byte contains the or'ed rate mask of all PCM SADs (i.e. 192kHz). The audio-side then notices that 96kHz (in SAD) != 192kHz (in extra byte) and generates two SADs, one with 8ch 96kHz and one with 2ch 192kHz. > Does it mean alsa may try to play 8channels audio at 192kHz and fail at this? > That doesn't sound good, but on the other hand I can't propose > anything better :| Well, ALSA does not restrict that currently in any case (the ALSA HDMI code currently only takes the maximum channels/rate/etc into account, it doesn't check if the specific combination is allowed by SADs), but that is mostly just because nobody has added such code yet. > Out of curiosity, what does fglrx set in the verbs? I don't know, though I'd expect it to put the same values that get put there with this patch. >> Technically there are even more cases to handle (multiple non-PCM SADs >> of the same type, more than two PCM SADs with varying channel counts, >> etc), but those have not actually been encountered in the field and >> handling them would be non-trivial. >> >> Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo >> support and 96kHz 8-channel support (and other 8-channel compressed >> formats): > -- Anssi Hannula
dma-buf non-coherent mmap
On Fri, Nov 1, 2013 at 1:25 AM, Rob Clark wrote: > On Thu, Oct 31, 2013 at 8:17 PM, Jakob Bornecrantz > wrote: >> On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote: >>> On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote: On 10/31/2013 09:48 PM, Dave Airlie wrote: >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom >>> >vmware.com> wrote: >>Well, I'd be happy to avoid mmap, but then what does optional mean in >>this >>context? >>That all generic user-space apps *must* implement a workaround if mmap >>isn't >>implemented? >> >>It's unfortunate a bit like implicit synchronization mentioned in >>section 3) >>in Direct Userspace Access/mmap Support >>in the kernel dma-buf doc: It should be avoided, otherwise it might be >>relied upon by userspace and exporters >>not implementing it will suffer. >> >>In reality, people will start using mmap() and won't care to implement >>workarounds if it's not supported, and drivers like >>vmwgfx and non-coherent architectures will suffer. >> >>I haven't looked closely at how DRI3 or Wayland/weston use or will use >>dma-buf, but if they rely on mmap, we're sort >>of lost. MIR uses the following scheme: >DRI3 and wayland won't use dma-buf mmap directly, > >using dma-buf mmap directly is wrong for anything that shares objects >with itself. That sounds good to hear. Perhaps we should add that to the dma-buf docs. >>> >>> Userspace mmap was essentially added as a concession to the android ion >>> guys since they really, really wanted it. We've tried to tell them that >>> it's a horrible idea (see all the fun with coherency and syncing), but >>> they said that they have userspace for it already and so we let it be. >>> >>> Imo if you're not running Android userspace there's no need for this at >>> all. >> >> But now it turns out that gstreamer is using it and our life is hell. We >> should >> have made it not work for _any_ driver if CONFIG_ANDRIOD wasn't set. > > well, at the moment mmap is only implemented by a few of the arm > drivers, from the looks of it. So I guess in the near term it is > mostly going to be of interest to the SoC crowd. Ah okay, I thought this was desktop gstreamer. > Not sure about the long term, perhaps we should see about > turning gallium pipe_transfer/map stuff into a kernel interface > (ioctl's directly on the dmabuf fd, perhaps?) Or they could just create a OpenGL context, I know it sounds heavy weight. But somebody will eventually want to synchronize this with a different client API in a non-blocking way. And OpenGL or some other Khronos API already have that integration, no real need to reinvent the wheel. Then again I think both GBM and DRI have hooks for mapping and unmapping buffers, so those might suffice. Cheers, Jakob.
[PATCH v3 06/32] drm/exynos: Pass exynos_drm_manager in manager ops instead of dev
Hi Sean,
On Tuesday 29 of October 2013 12:12:52 Sean Paul wrote:
> This patch changes the manager ops callbacks from accepting the subdrv
> device pointer to taking a pointer to the manager. This will allow us
> to move closer to decoupling manager/display from subdrv, and
> subsequently decoupling the crtc/plane from the encoder.
The idea of changing callbacks argument itself is fine for me, but I
wonder if by the way we couldn't refactor the code in a way that would
allow type checking of context structures. This would make the code a bit
less error-prone (or maybe I'm just a bit too paranoid...).
Anyway, please see my remaining comments inline.
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Instead of passing context, pass manager
> - Properly assign ctx->dev in fimd driver
> Changes in v3:
> - Added vidi implementation
>
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 35
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 +++---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 114
> ++ drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> | 72 drivers/gpu/drm/exynos/exynos_drm_vidi.c |
> 83 ++- 6 files changed, 180 insertions(+), 153
> deletions(-)
[snip]
> @@ -182,16 +184,16 @@ static struct exynos_drm_display_ops
> fimd_display_ops = { .power_on = fimd_display_power_on,
> };
>
> -static void fimd_win_mode_set(struct device *dev,
> - struct exynos_drm_overlay *overlay)
> +static void fimd_win_mode_set(struct exynos_drm_manager *mgr,
> + struct exynos_drm_overlay *overlay)
> {
> - struct fimd_context *ctx = get_fimd_context(dev);
> + struct fimd_context *ctx = mgr->ctx;
> struct fimd_win_data *win_data;
> int win;
> unsigned long offset;
>
> if (!overlay) {
> - dev_err(dev, "overlay is NULL\n");
> + DRM_ERROR("overlay is NULL\n");
This change does not seem to be related to $subject.
> return;
> }
>
> @@ -231,9 +233,8 @@ static void fimd_win_mode_set(struct device *dev,
> overlay->fb_width, overlay->crtc_width);
> }
>
> -static void fimd_win_set_pixfmt(struct device *dev, unsigned int win)
> +static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int
> win) {
Again not really related to $subject. Maybe this should be done in a
preparatory patch preceeding this one? (+ same comment for several
identical changes below)
> - struct fimd_context *ctx = get_fimd_context(dev);
> struct fimd_win_data *win_data = >win_data[win];
> unsigned long val;
>
[snip]
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c index aebcc0e..ca0a87f
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> @@ -129,11 +129,9 @@ static struct edid *drm_hdmi_get_edid(struct device
> *dev,
>
> return NULL;
> }
> -
> -static int drm_hdmi_check_mode(struct device *dev,
> +static int drm_hdmi_check_mode_ctx(struct drm_hdmi_context *ctx,
> struct drm_display_mode *mode)
> {
> - struct drm_hdmi_context *ctx = to_context(dev);
> int ret = 0;
>
> /*
> @@ -153,6 +151,14 @@ static int drm_hdmi_check_mode(struct device *dev,
> return 0;
> }
>
> +static int drm_hdmi_check_mode(struct device *dev,
> + struct drm_display_mode *mode)
> +{
> + struct drm_hdmi_context *ctx = to_context(dev);
> +
> + return drm_hdmi_check_mode_ctx(ctx, mode);
> +}
> +
nit: I don't think such wrapper is necessary.
It seems to be easy enough to get from dev to ctx, so depending on the
amount of user of drm_hdmi_check_mode() it might be better to simply
change them to pass ctx instead of dev.
[snip]
> @@ -403,19 +404,23 @@ static void vidi_subdrv_remove(struct drm_device
> *drm_dev, struct device *dev) /* TODO. */
> }
>
> -static int vidi_power_on(struct vidi_context *ctx, bool enable)
> +static int vidi_power_on(struct exynos_drm_manager *mgr, bool enable)
> {
> - struct exynos_drm_subdrv *subdrv = >subdrv;
> - struct device *dev = subdrv->dev;
> + struct vidi_context *ctx = mgr->ctx;
> +
> + DRM_DEBUG_KMS("%s\n", __FILE__);
> +
> + if (enable != false && enable != true)
> + return -EINVAL;
Huh? What value would you expect a bool to have if not false or true?
Anyway, this shouldn't really matter, as the check bellow assumes that
anything non-zero is true.
>
> if (enable) {
> ctx->suspended = false;
>
Just for clarity, this is the check I mentioned above.
Best regards,
Tomasz
dma-buf non-coherent mmap
On Fri, Nov 1, 2013 at 12:00 AM, Daniel Vetter wrote: > On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote: >> On 10/31/2013 09:48 PM, Dave Airlie wrote: >> >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom >> >wrote: >> >>Well, I'd be happy to avoid mmap, but then what does optional mean in this >> >>context? >> >>That all generic user-space apps *must* implement a workaround if mmap >> >>isn't >> >>implemented? >> >> >> >>It's unfortunate a bit like implicit synchronization mentioned in section >> >>3) >> >>in Direct Userspace Access/mmap Support >> >>in the kernel dma-buf doc: It should be avoided, otherwise it might be >> >>relied upon by userspace and exporters >> >>not implementing it will suffer. >> >> >> >>In reality, people will start using mmap() and won't care to implement >> >>workarounds if it's not supported, and drivers like >> >>vmwgfx and non-coherent architectures will suffer. >> >> >> >>I haven't looked closely at how DRI3 or Wayland/weston use or will use >> >>dma-buf, but if they rely on mmap, we're sort >> >>of lost. MIR uses the following scheme: >> >DRI3 and wayland won't use dma-buf mmap directly, >> > >> >using dma-buf mmap directly is wrong for anything that shares objects >> >with itself. >> >> That sounds good to hear. Perhaps we should add that to the dma-buf docs. > > Userspace mmap was essentially added as a concession to the android ion > guys since they really, really wanted it. We've tried to tell them that > it's a horrible idea (see all the fun with coherency and syncing), but > they said that they have userspace for it already and so we let it be. > > Imo if you're not running Android userspace there's no need for this at > all. But now it turns out that gstreamer is using it and our life is hell. We should have made it not work for _any_ driver if CONFIG_ANDRIOD wasn't set. Cheers, Jakob.
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Friday 01 of November 2013 08:55:12 Jingoo Han wrote: > On Friday, November 01, 2013 8:27 AM, Tomasz Figa wrote: > > On Friday 01 of November 2013 08:23:59 Jingoo Han wrote: > > > On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote: > > > > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote: > > > > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote: > > > > > > CCing Jingoo, > > > > > > > > > > > > Is that ok to remove eDP driver from video/exynos? Isn't this > > > > > > driver > > > > > > really used by Linux framebuffer driver, s3c-fb.c? > > > > > > > > > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, > > > > > > > > > > linux-fbdev list, linux-samsung-soc list > > > > > > > > > > Yes, it is used by s3c-fb.c. > > > > > > > > > > > Of course, now s3c-fb driver is dead code because this driver > > > > > > doesn't > > > > > > support device tree yet but we would need more reviews and > > > > > > discussions > > > > > > about moving this driver into drm side. Let's watch new rules > > > > > > for > > > > > > device tree bindings of DRM world. So I'd not like to merge > > > > > > this > > > > > > driver yet. > > > > > > > > > > 's3c-fb' driver is still used for other mass products projects. > > > > > Just, device tree support patch is not yet submitted. > > > > > > > > Current in-tree users of s3c-fb drivers are s3c2443, non-DT > > > > s3c64xx > > > > and > > > > all s5p* SoCs. It is not used on Exynos SoCs anymore. > > > > > > Hi Tomasz Figa, > > > > Just Tomasz. ;) > > Hi Tomasz, :-) > > > > Some mass product projects using Exynos5250 and etc, use s3c-fb > > > driver > > > and dp driver. Also, these projects are still using Framebuffer, not > > > DRM. > > > > Well, those are based on vendor trees anyway, so do not really affect > > mainline kernel. > > OK, I see. > > > > > As for Exynos DP driver, what SoCs does it support? If only Exynos > > > > (as > > > > the name suggests) then there is no point in keeping it at > > > > video/exynos and making it a part of Exynos DRM driver seems > > > > reasonable to me. > > > > > > However, when considering only mainline kernel, I have no strong > > > objection. As you know, many Linux kernel based OS projects using > > > Exynos, are using DRM, not Framebuffer. > > > > Generally, fbdev is strongly discouraged in any new systems and DRM is > > the way to go, so I don't think we should ever want to bring s3c-fb > > support back to Exynos platforms. > > Yes, you're right. > Personally, I think that all Exynos platforms should go into DRM, not > FB. > > One more thing, then how about moving Exynos MIPI to DRM side? > Is there any plan on Exynos MIPI? Well, it will eventually have to be moved somewhere else than it is, but I believe this will have to wait for Common Display Framework. This is because the case of MIPI DSI is slightly different from DisplayPort, since it is not an enumerable/auto-configurable interface and requires dedicated panel drivers and static data provided by board designers (in DT for example). Handling of such things in a generic way will be done by CDF. Best regards, Tomasz
[PATCH v3 05/32] drm/exynos: hdmi: Implement initialize op for hdmi
Hi Sean,
On Tuesday 29 of October 2013 12:12:51 Sean Paul wrote:
> This patch implements the initialize callback in the hdmi and mixer
> manager. This allows us to get rid of drm_dev in the drm_hdmi level and
> track it in the mixer and hdmi drivers. This is one of the things
> holding back the complete removal of the drm_hdmi layer.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2: None
> Changes in v3: None
>
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 35
> ++--
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 3 ++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 18
> drivers/gpu/drm/exynos/exynos_mixer.c| 35
> +++- 4 files changed, 66 insertions(+), 25
> deletions(-)
[snip]
> @@ -985,8 +991,7 @@ static struct exynos_mixer_ops mixer_ops = {
>
> static irqreturn_t mixer_irq_handler(int irq, void *arg)
> {
> - struct exynos_drm_hdmi_context *drm_hdmi_ctx = arg;
> - struct mixer_context *ctx = drm_hdmi_ctx->ctx;
> + struct mixer_context *ctx = arg;
> struct mixer_resources *res = >mixer_res;
> u32 val, base, shadow;
>
> @@ -995,6 +1000,9 @@ static irqreturn_t mixer_irq_handler(int irq, void
> *arg) /* read interrupt status for handling and clearing flags for
> VSYNC */ val = mixer_reg_read(res, MXR_INT_STATUS);
>
> + if (!ctx->drm_dev)
> + goto out;
The patch looks fine, but I'd like you to explain me in what conditions
can this condition evaluate to true.
Best regards,
Tomasz
[PATCH v3 04/32] drm/exynos: Use manager_op initialize in fimd
Hi Sean,
On Tuesday 29 of October 2013 12:12:50 Sean Paul wrote:
> This patch implements the intitialize manager op in fimd.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2: None
> Changes in v3: None
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
[snip]
> static void fimd_dpms(struct device *subdrv_dev, int mode)
> {
> struct fimd_context *ctx = get_fimd_context(subdrv_dev);
> @@ -660,6 +671,7 @@ static void fimd_wait_for_vblank(struct device *dev)
> }
>
> static struct exynos_drm_manager_ops fimd_manager_ops = {
> + .initialize = fimd_mgr_initialize,
> .dpms = fimd_dpms,
> .apply = fimd_apply,
> .commit = fimd_commit,
> @@ -681,7 +693,6 @@ static irqreturn_t fimd_irq_handler(int irq, void
> *dev_id) {
> struct fimd_context *ctx = (struct fimd_context *)dev_id;
> struct exynos_drm_subdrv *subdrv = >subdrv;
> - struct drm_device *drm_dev = subdrv->drm_dev;
Apparently the driver already can have a reference to drm_device, without
the .initialize() method being called.
I guess your change makes it somehow better, but patch description fails
to explain this.
Best regards,
Tomasz
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
2013/11/1 Rafa? Mi?ecki : > 2013/10/29 Anssi Hannula : >> Fix the code to pick the PCM SAD with the highest number of channels, >> while merging the rate masks of PCM SADs with lower amount of channels >> into the additional stereo rate mask byte. > > Does it mean that now instead of 2 real SADs: > 1) 192kHz support for 2 channels > 2) 96kHz support for 8 channels > you will only get: > 1) 192kHz support for 8 channels > ? > Does it mean alsa may try to play 8channels audio at 192kHz and fail at this? > That doesn't sound good, but on the other hand I can't propose > anything better :| Ahh, wait. I just noticed you're using SUPPORTED_FREQUENCIES and (different one) SUPPORTED_FREQUENCIES_STEREO there. Sorry I missed that earlier. Yeah, just code makes much more sense, I just think the logic in setting that frequency may be a bit bad... Let me think about this clearly tomorrow and I'll let you know :) -- Rafa?
[PATCH v3 03/32] drm/exynos: Add an initialize function to manager and display
On Tuesday 29 of October 2013 12:12:49 Sean Paul wrote: > This patch adds an initialize function to the manager and display > operations. This allows them to keep track of drm_device in their > local context, as well as adds an initialization hook right after > the encoder is created. > > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 + > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 21 + > 2 files changed, 26 insertions(+) Reviewed-by: Tomasz Figa Best regards, Tomasz
[PATCH v3 02/32] drm/exynos: Merge overlay_ops into manager_ops
Hi Sean,
On Tuesday 29 of October 2013 12:12:48 Sean Paul wrote:
> This patch merges overlay_ops into manager_ops. In all cases,
> overlay_ops is implemented in the same place as manager ops, it doesn't
> serve a functional purpose, and doesn't make things more clear.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2: None
> Changes in v3: None
>
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 29 +--
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 26 +-
> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 363
> ++-- drivers/gpu/drm/exynos/exynos_drm_hdmi.c
> | 36 ++-
> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 29 +--
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 -
> 6 files changed, 229 insertions(+), 256 deletions(-)
[snip]
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 868a14d..f271f22
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -181,185 +181,6 @@ static struct exynos_drm_display_ops
> fimd_display_ops = { .power_on = fimd_display_power_on,
> };
>
> -static void fimd_dpms(struct device *subdrv_dev, int mode)
> -{
> - struct fimd_context *ctx = get_fimd_context(subdrv_dev);
> -
> - DRM_DEBUG_KMS("%d\n", mode);
> -
> - mutex_lock(>lock);
> -
> - switch (mode) {
> - case DRM_MODE_DPMS_ON:
> - /*
> - * enable fimd hardware only if suspended status.
> - *
> - * P.S. fimd_dpms function would be called at booting time
so
> - * clk_enable could be called double time.
> - */
> - if (ctx->suspended)
> - pm_runtime_get_sync(subdrv_dev);
> - break;
> - case DRM_MODE_DPMS_STANDBY:
> - case DRM_MODE_DPMS_SUSPEND:
> - case DRM_MODE_DPMS_OFF:
> - if (!ctx->suspended)
> - pm_runtime_put_sync(subdrv_dev);
> - break;
> - default:
> - DRM_DEBUG_KMS("unspecified mode %d\n", mode);
> - break;
> - }
> -
> - mutex_unlock(>lock);
> -}
[snip]
> -static void fimd_wait_for_vblank(struct device *dev)
> -{
> - struct fimd_context *ctx = get_fimd_context(dev);
> -
> - if (ctx->suspended)
> - return;
> -
> - atomic_set(>wait_vsync_event, 1);
> -
> - /*
> - * wait for FIMD to signal VSYNC interrupt or return after
> - * timeout which is set to 50ms (refresh rate of 20).
> - */
> - if (!wait_event_timeout(ctx->wait_vsync_queue,
> - !atomic_read(>wait_vsync_event),
> - DRM_HZ/20))
> - DRM_DEBUG_KMS("vblank wait timed out.\n");
> -}
Do you need all the churn of moving all the functions above? I believe it
would be enough to simply move the structure. This would greatly decrease
the diffstat and chances of possible merge conflicts.
Otherwise the patch looks good to me and improves things indeed.
Best regards,
Tomasz
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
2013/10/29 Anssi Hannula : > Because of this, only the 2-channel SAD may be used if it appears before > the 8-channel SAD. Unless other SADs require otherwise, this may cause > the ALSA HDA driver to allow stereo playback only. I can confirm that the problem exists. My SADs (Onkyo TX-SR605): Format: 1 (PCM)Channels:1Freq:0x7F (32-192)B2:0x07 (16-24b) Format: 1 (PCM)Channels:7Freq:0x7F (32-192)B2:0x07 (16-24b) Format: 2 (AC3)Channels:7Freq:0x07 (32-48)B2:0x50 (640?) Format: 7 (DTS)Channels:7Freq:0x06 (44-48)B2:0xC0 (1536?) Format: 10 (EAC3)Channels:7Freq:0x06 (44-48)B2:0x00 Format: 11 (DTS_HD)Channels:7Freq:0x7E (44-192)B2:0x01 Format: 12 (MLP)Channels:7Freq:0x1E (44-96)B2:0x00 Unfortunately I get only 1 emulated SAD entry for PCM (/proc/asound/card1/eld#0.0): sad0_coding_type[0x1] LPCM sad0_channels 2 sad0_rates [0x1ee0] 32000 44100 48000 88200 96000 176400 192000 sad0_bits [0xe] 16 20 24 So I can not play 8 channel LPCM "legally" (without forcing player to do so). > Fix the code to pick the PCM SAD with the highest number of channels, > while merging the rate masks of PCM SADs with lower amount of channels > into the additional stereo rate mask byte. Does it mean that now instead of 2 real SADs: 1) 192kHz support for 2 channels 2) 96kHz support for 8 channels you will only get: 1) 192kHz support for 8 channels ? Does it mean alsa may try to play 8channels audio at 192kHz and fail at this? That doesn't sound good, but on the other hand I can't propose anything better :| Out of curiosity, what does fglrx set in the verbs? > Technically there are even more cases to handle (multiple non-PCM SADs > of the same type, more than two PCM SADs with varying channel counts, > etc), but those have not actually been encountered in the field and > handling them would be non-trivial. > > Example affected EDID from Onkyo TX-SR674 specifying 192kHz stereo > support and 96kHz 8-channel support (and other 8-channel compressed > formats): -- Rafa?
[PATCH v3 01/32] drm/exynos: Remove useless slab.h include
Hi Sean, St?phane, On Tuesday 29 of October 2013 12:12:47 Sean Paul wrote: > From: St?phane Marchesin > > Signed-off-by: St?phane Marchesin > Signed-off-by: Sean Paul > --- > > Changes in v2: None > Changes in v3: None > > drivers/video/exynos/exynos_dp_core.c | 1 - > 1 file changed, 1 deletion(-) I'm not sure if this patch should really be a part of this series. Furthermore, is this header inclusion really useless? I believe it is the place where kmalloc() and friends are declared. Best regards, Tomasz
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Friday 01 of November 2013 08:23:59 Jingoo Han wrote: > On Friday, November 01, 2013 8:12 AM, Tomasz Figa wrote: > > On Friday 01 of November 2013 08:06:00 Jingoo Han wrote: > > > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote: > > > > CCing Jingoo, > > > > > > > > Is that ok to remove eDP driver from video/exynos? Isn't this > > > > driver > > > > really used by Linux framebuffer driver, s3c-fb.c? > > > > > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, > > > > > > linux-fbdev list, linux-samsung-soc list > > > > > > Yes, it is used by s3c-fb.c. > > > > > > > Of course, now s3c-fb driver is dead code because this driver > > > > doesn't > > > > support device tree yet but we would need more reviews and > > > > discussions > > > > about moving this driver into drm side. Let's watch new rules for > > > > device tree bindings of DRM world. So I'd not like to merge this > > > > driver yet. > > > > > > 's3c-fb' driver is still used for other mass products projects. > > > Just, device tree support patch is not yet submitted. > > > > Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx > > and > > all s5p* SoCs. It is not used on Exynos SoCs anymore. > > Hi Tomasz Figa, Just Tomasz. ;) > Some mass product projects using Exynos5250 and etc, use s3c-fb driver > and dp driver. Also, these projects are still using Framebuffer, not > DRM. Well, those are based on vendor trees anyway, so do not really affect mainline kernel. > > As for Exynos DP driver, what SoCs does it support? If only Exynos (as > > the name suggests) then there is no point in keeping it at > > video/exynos and making it a part of Exynos DRM driver seems > > reasonable to me. > > However, when considering only mainline kernel, I have no strong > objection. As you know, many Linux kernel based OS projects using > Exynos, are using DRM, not Framebuffer. Generally, fbdev is strongly discouraged in any new systems and DRM is the way to go, so I don't think we should ever want to bring s3c-fb support back to Exynos platforms. > > Also, if moving DP driver to DRM, MAINTAINERS entry for Exynos DP driver > should be updated, too. That's correct. Best regards, Tomasz
[PATCH v3 21/32] drm/exynos: Move dp driver from video/ to drm/
On Friday 01 of November 2013 08:06:00 Jingoo Han wrote: > On Thursday, October 31, 2013 7:47 PM, Inki Dae wrote: > > CCing Jingoo, > > > > Is that ok to remove eDP driver from video/exynos? Isn't this driver > > really used by Linux framebuffer driver, s3c-fb.c? > > +cc Tomi Valkeinen, Jean-Christophe PLAGNIOL-VILLARD, > linux-fbdev list, linux-samsung-soc list > > Yes, it is used by s3c-fb.c. > > > Of course, now s3c-fb driver is dead code because this driver doesn't > > support device tree yet but we would need more reviews and discussions > > about moving this driver into drm side. Let's watch new rules for > > device tree bindings of DRM world. So I'd not like to merge this > > driver yet. > 's3c-fb' driver is still used for other mass products projects. > Just, device tree support patch is not yet submitted. Current in-tree users of s3c-fb drivers are s3c2443, non-DT s3c64xx and all s5p* SoCs. It is not used on Exynos SoCs anymore. As for Exynos DP driver, what SoCs does it support? If only Exynos (as the name suggests) then there is no point in keeping it at video/exynos and making it a part of Exynos DRM driver seems reasonable to me. Best regards, Tomasz
dma-buf non-coherent mmap
On Thu, Oct 31, 2013 at 10:07:25PM +0100, Thomas Hellstrom wrote: > On 10/31/2013 09:48 PM, Dave Airlie wrote: > >On Fri, Nov 1, 2013 at 6:40 AM, Thomas Hellstrom > >wrote: > >>Well, I'd be happy to avoid mmap, but then what does optional mean in this > >>context? > >>That all generic user-space apps *must* implement a workaround if mmap isn't > >>implemented? > >> > >>It's unfortunate a bit like implicit synchronization mentioned in section 3) > >>in Direct Userspace Access/mmap Support > >>in the kernel dma-buf doc: It should be avoided, otherwise it might be > >>relied upon by userspace and exporters > >>not implementing it will suffer. > >> > >>In reality, people will start using mmap() and won't care to implement > >>workarounds if it's not supported, and drivers like > >>vmwgfx and non-coherent architectures will suffer. > >> > >>I haven't looked closely at how DRI3 or Wayland/weston use or will use > >>dma-buf, but if they rely on mmap, we're sort > >>of lost. MIR uses the following scheme: > >DRI3 and wayland won't use dma-buf mmap directly, > > > >using dma-buf mmap directly is wrong for anything that shares objects > >with itself. > > That sounds good to hear. Perhaps we should add that to the dma-buf docs. Userspace mmap was essentially added as a concession to the android ion guys since they really, really wanted it. We've tried to tell them that it's a horrible idea (see all the fun with coherency and syncing), but they said that they have userspace for it already and so we let it be. Imo if you're not running Android userspace there's no need for this at all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Linaro-mm-sig] dma-buf non-coherent mmap
user-space cpu access to dma-buf is needed for example in Gstreamer pipeline when you have mix of harware element (a video decoder) and software element (like colorspace converter). Gstreamer already support dma-buf in a specific gstallocator: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/gst-libs/gst/allocators/gstdmabuf.c Regards, Benjamin 2013/10/31 Thomas Hellstrom : > On 10/31/2013 10:10 PM, Rob Clark wrote: >> >> On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom >> wrote: >>> >>> On 10/31/2013 06:52 PM, Rob Clark wrote: On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom wrote: > > Hi! > > I'm just looking over what's needed to implement drm Prime / dma-buf > exports > + imports in the vmwgfx driver. It seems like most dma-bufs ops are > quite > straightforward to implement except user-space mmap(). > > The reason being that vmwgfx dma-bufs will be using completely > non-coherent > memory, whenever there needs to be CPU accesses. > > The accelerated contents resides in an opaque structure on the device > into > which we can DMA to and from, so for mmap to work we need to zap ptes > and > DMA to the device when doing something accelerated, and on the first > page-fault DMA data back and wait for idle if the device did a write to > the > dma-buf. > > Now this shouldn't really be a problem if dma-bufs were only used for > cross-device sharing, but since people apparently want to use dma-buf > file > handles to share CPU data between processes it really becomes a serious > problem. > > Needless to say we'd want to limit the size of the DMAs, and have mmap > users > request regions for read, and mark regions dirty for write, something > similar to gallium's texture transfer objects. > > Any ideas? well, I think vmwgfx is part of the reason we decided mmap would be optional for dmabuf. So perhaps it is an option to simply ignore mmap? BR, -R >>> >>> >>> Well, I'd be happy to avoid mmap, but then what does optional mean in >>> this >>> context? >>> That all generic user-space apps *must* implement a workaround if mmap >>> isn't >>> implemented? >> >> well, mmap was mostly just added because it was needed by android for >> ION on dmabuf. >> >> I think it is an option to just not use dmabuf mmap in a linux >> userspace. I mean, we could also define some ioctls to give us pwrite >> and other similar sort of functionality if it is needed. > > > I think that if direct user-space cpu-access to dma-buf is ever needed by > linux, > something like that is a better option. Best IMHO would be to avoid > user-space > cpu-access completely. > > Regards, > /Thomas > > >> >> BR, >> -R >> > > ___ > Linaro-mm-sig mailing list > Linaro-mm-sig at lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- Benjamin Gaignard Graphic Working Group Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
