[Bug 58621] radeon 7770 kernel crash when changing powwr profile

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58621

--- Comment #8 from rafael castillo  ---
well dpm fixed it for me entirely, if you wanna close the bug once alan tested
it, is fine

thanks for your time

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3 1/7] drm: Add DSI bus infrastructure

[Thierry Reding]

On Tue, Nov 12, 2013 at 03:14:22PM +0100, Andrzej Hajda wrote:
> Hi Thierry,
> 
> I have already sent patch with DSI bus implementation [1].
> It was posted as the first step of CDF implementation attempt,
> but in fact it do not depend on CDF.
> 
> [1]
> http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg45252.html

Seems like that patchset was never merged. I guess probably because it
was posted as part of CDF work.

Do you have any plans on continuing work on that? If not I could extract
the DSI bus patch from the series, it's largely similar to the patch I
proposed here, and rework it somewhat. I'd very much like to avoid
putting the code in drivers/video, though, since that's considered
obsolete. Furthermore I think if we kept the transfer function proposed
in my patch should make it easier to address Bert's comments from your
posting.

> One comment below.
> 
> On 11/11/2013 01:00 PM, Thierry Reding wrote:
> > In order to support DSI peripherals, add a DSI bus type that devices and
> > drivers can be registered with.
> > 
> > Signed-off-by: Thierry Reding 
> > ---
> 
> [snip]
> > +
> > +/*
> > + * DSI packet data types
> > + */
> > +
> > +/* processor-sourced packets */
> > +#define DSI_CMD_VSYNC_START 0x01
> > +#define DSI_CMD_VSYNC_END 0x11
> > +#define DSI_CMD_HSYNC_START 0x21
> > +#define DSI_CMD_HSYNC_END 0x31
> > +#define DSI_CMD_EOT 0x08
> > +#define DSI_CMD_COLOR_MODE_OFF 0x02
> > +#define DSI_CMD_COLOR_MODE_ON 0x12
> > +#define DSI_CMD_SHUT_DOWN 0x22
> > +#define DSI_CMD_TURN_ON 0x32
> > +#define DSI_CMD_GEN_SHORT_WRITE_0 0x03
> > +#define DSI_CMD_GEN_SHORT_WRITE_1 0x13
> > +#define DSI_CMD_GEN_SHORT_WRITE_2 0x23
> > +#define DSI_CMD_GEN_SHORT_READ_0 0x04
> > +#define DSI_CMD_GEN_SHORT_READ_1 0x14
> > +#define DSI_CMD_GEN_SHORT_READ_2 0x24
> > +#define DSI_CMD_DCS_SHORT_WRITE_0 0x05
> > +#define DSI_CMD_DCS_SHORT_WRITE_1 0x15
> > +#define DSI_CMD_DCS_SHORT_READ 0x06
> > +#define DSI_CMD_SET_MAX_RETURN_PACKET_SIZE 0x37
> > +#define DSI_CMD_NULL 0x09
> > +#define DSI_CMD_BLANK 0x19
> > +#define DSI_CMD_GEN_LONG_WRITE 0x29
> > +#define DSI_CMD_DCS_LONG_WRITE 0x39
> > +#define DSI_CMD_YCbCr422_20 0x0c
> > +#define DSI_CMD_YCbCr422_24 0x1c
> > +#define DSI_CMD_YCbCr422_16 0x2c
> > +#define DSI_CMD_RGB30 0x0d
> > +#define DSI_CMD_RGB36 0x1d
> > +#define DSI_CMD_YCbCr420 0x3d
> > +#define DSI_CMD_RGB16 0x0e
> > +#define DSI_CMD_RGB18 0x1e
> > +#define DSI_CMD_RGB18NP 0x2e
> > +#define DSI_CMD_RGB24 0x3e
> > +
> > +/* peripheral-sourced */
> > +#define DSI_RSP_ACK_ERR 0x02
> > +#define DSI_RSP_EOT 0x08
> > +#define DSI_RSP_GEN_SHORT_READ_1 0x11
> > +#define DSI_RSP_GEN_SHORT_READ_2 0x12
> > +#define DSI_RSP_GEN_LONG_READ 0x1a
> > +#define DSI_RSP_DCS_LONG_READ 0x1c
> > +#define DSI_RSP_DCS_SHORT_READ_1 0x21
> > +#define DSI_RSP_DCS_SHORT_READ_2 0x22
> > +
> 
> Those macros are already defined in include/video/mipi_display.h

I wasn't aware, thanks for the pointer. It's somewhat unfortunate that
that's in include/video, but judging by the git log, it has been there
for quite a while.

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/20131113/26e0a7c1/attachment-0001.pgp>

[Bug 71285] Xonotic LLVM ERROR

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71285

--- Comment #2 from Rafael Castillo  ---
I use llvm 3.4 daily emerged on gentoo

-- 
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/20131113/d6990a24/attachment.html>

[Bug 70286] X crashes when using Firefox with logout loop

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70286

--- Comment #2 from nucrap at hotmail.com ---
Yeah I've just experienced the same... it's a shock that firefox seems to be
responsible for the bug. This is a really critical bug.

I've got quite the same warnings:

radeon :0b:00.0: ib ring test failed (-35).
[drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-35).
[drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35).
radeon :0b:00.0: GPU lockup (waiting for 0x00447fb3 last fence id
0x00447fac)
radeon :0b:00.0: GPU lockup CP stall for more than 1msec

[...]

[drm:radeon_crtc_page_flip] *ERROR* failed to pin new rbo buffer before flip
radeon :0b:00.0: 880158860c00 pin failed




Lots of errors like that!

-- 
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/20131113/a6c4bd48/attachment.html>

[Bug 55251] Resume from suspend and console switching using fails on F18

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55251

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #2 from Alex Deucher  ---
Is this still an issue with newer kernels?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55931] Crashes with radeon driver and r100/r200 cards (Radeon 7000 & 9250) on Tyan S2460 MB (AMD 32)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55931

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #5 from Alex Deucher  ---
Does it work if you disable AGP?  Boot with radeon.agpmode=-1 on the kernel
command line in grub.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55251] Resume from suspend and console switching using fails on F18

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55251

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Other   |Video(DRI - non Intel)
   Assignee|drivers_other at kernel-bugs.o |drivers_video-dri at 
kernel-bu
   |sdl.org |gs.osdl.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55931] Crashes with radeon driver and r100/r200 cards (Radeon 7000 & 9250) on Tyan S2460 MB (AMD 32)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55931

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|i386|Video(DRI - non Intel)
   Assignee|platform_i386 at kernel-bugs.o |drivers_video-dri at 
kernel-bu
   |sdl.org |gs.osdl.org
Product|Platform Specific/Hardware  |Drivers

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55941

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55941] Hybrid graphics i915/radeon. Switch to radeon results to black screen

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55941

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |DOCUMENTED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/3] drm/i915: Make AGP=n work even on gen3

[Daniel Vetter]

On Wed, Nov 13, 2013 at 08:59:56PM +0200, Ville Syrj?l? wrote:
> On Mon, Nov 11, 2013 at 09:35:17AM +0100, Daniel Vetter wrote:
> > Most platforms din't hit this condition, but if we want to allow
> > building without agp we should also make this allowed on gen3.
> > 
> > Cc: Ville Syrj?l? 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 38a344694e35..d7c922051c89 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -158,7 +158,7 @@ static struct drm_driver driver;
> >  #if IS_ENABLED(CONFIG_AGP_INTEL)
> >  extern int intel_agp_enabled;
> >  #else
> > -static int intel_agp_enabled;
> > +static int intel_agp_enabled = 1;
> 
> Patch 2/3 eliminates our only use of intel_agp_enabled, so this patch
> seems pointless.

Patch 2 has a good chance to get reverted, so having this separate isn't
completely pointless. Should have mentioned this in the cover letter ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 56441] video error with ubuntu 12.10 and kernels after 3.50.21, and generic_3.8.0-030800rc6

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=56441

--- Comment #6 from Alex Deucher  ---
Is this still an issue with a more recent kernel?  We've gone back to turning
off the displays completely when updating the MC.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 56441] video error with ubuntu 12.10 and kernels after 3.50.21, and generic_3.8.0-030800rc6

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=56441

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
   Assignee|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Intel-gfx] [PATCH 3/3] drm/i915: Deprecated UMS support

[Ville Syrjälä]

On Mon, Nov 11, 2013 at 09:35:19AM +0100, Daniel Vetter wrote:
> It's been 5 years since kms support was merged and roughly 4 years
> since UMS support was ripped out from userspace drivers.
> 
> Thus far it's not been a big burden to keep the ums paths alive, and
> we've made some good progress in better separating it from the kms
> code by sprinkling DRIVER_MODESET checks all over the place.
> 
> But now that the drm demidlayering is within reach this changes. I
> want to make the driver loading code more robust using devres.c and
> other cool tricks. But that doesn't work with ums due to the
> shadow-attach trick. Which means we either
> a) need to split out a complete ums codebase like radeon has
> b) kill it for good.
> 
> The 2nd option is obviously much less work than the first, so I think
> it's time to test the waters and see how many people out there still
> use ums.
> 
> I've decided that silently failing to initialize the driver (and not
> e.g. failing to load the module) is the right thing. That way we
> should only get reports from users that actually care about some ums
> features (like accelerated gl or support for secondary outputs).
> Everyone else will just fall back to the vesa X driver.
> 
> For developers there's a small info level dmesg output.
> 
> The plan is to drop this Kconfig option after 3.16 (so gives us 2 full
> releases) and then start killing code for real 2-3 releases
> afterwards. That should be more than enough time for users to pipe up.
> 
> Of course if anyone does we need to revisit this plan and maybe go
> with option a) above.
> 
> Also enable the KMS support by default in Kconfig and polish the help
> texts a bit.
> 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/Kconfig | 24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index b0f61679c598..b0fa4c4055ee 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -37,12 +37,11 @@ config DRM_I915
>  config DRM_I915_KMS
>   bool "Enable modesetting on intel by default"
>   depends on DRM_I915
> + default y
>   help
> -   Choose this option if you want kernel modesetting enabled by default,
> -   and you have a new enough userspace to support this. Running old
> -   userspaces with this enabled will cause pain.  Note that this causes
> -   the driver to bind to PCI devices, which precludes loading things
> -   like intelfb.
> +   Choose this option if you want kernel modesetting enabled by default.
> +
> +   If in doubt, say "Y".
>  
>  config DRM_I915_FBDEV
>   bool "Enable legacy fbdev support for the modesettting intel driver"
> @@ -57,9 +56,12 @@ config DRM_I915_FBDEV
> support. Note that this support also provide the linux console
> support on top of the intel modesetting driver.
>  
> +   If in doubt, say "Y".
> +
>  config DRM_I915_PRELIMINARY_HW_SUPPORT
>   bool "Enable preliminary support for prerelease Intel hardware by 
> default"
>   depends on DRM_I915
> + default n
>   help
> Choose this option if you have prerelease Intel hardware and want the
> i915 driver to support it by default.  You can enable such support at
> @@ -67,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
> option changes the default for that module option.
>  
> If in doubt, say "N".
> +
> +config DRM_I915_UMS

Was there supposed to be some user for this config option?

> + bool "Enable userspace modesetting on Intel hardware (DEPRECATED)"
> + depends on DRM_I915
> + default n
> + help
> +   Choose this option if you still need userspace modesetting.
> +
> +   Userspace modesetting is deprecated for quite some time now, so
> +   enable this only if you have ancient versions of the DDX drivers.
> +
> +   If in doubt, say "N".
> -- 
> 1.8.4.rc3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrj?l?
Intel OTC

[PATCH 2/3] drm/i915: Kill legeacy AGP for gen3 kms

[Ville Syrjälä]

On Mon, Nov 11, 2013 at 09:35:18AM +0100, Daniel Vetter wrote:
> Thus far we've tried to carefully work around the fact that old
> userspace relied on the AGP-backed legacy buffer mapping ioctls for a
> bit too long. But it's really horribly, and now some new users for it
> started to show up again:
> 
> http://www.mail-archive.com/mesa-dev at lists.freedesktop.org/msg45547.html
> 
> This uses drmAgpSize to figure out the GTT size, which is both the
> wrong thing to inquire and also might force us to keep this crap
> around for another few years.
> 
> So I want to stop this particular zombie from raising ever again. Now
> it's only been 4 years since XvMC was fixed for gen3, so a bit early
> by the usual rules. But since Linus explicitly said that an ABI
> breakage only counts if someone actually observes it I want to tempt
> fate an accelarate the demise of AGP.
> 
> We probably need to wait 2-3 kernel releases with this shipping until
> we go on a killing spree code-wise.
> 
> Cc: Ville Syrj?l? 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d7c922051c89..93a8e0316bd0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -797,17 +797,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
> struct pci_device_id *ent)
>   if (PCI_FUNC(pdev->devfn))
>   return -ENODEV;
>  
> - /* We've managed to ship a kms-enabled ddx that shipped with an XvMC
> -  * implementation for gen3 (and only gen3) that used legacy drm maps
> -  * (gasp!) to share buffers between X and the client. Hence we need to
> -  * keep around the fake agp stuff for gen3, even when kms is enabled. */
> - if (intel_info->gen != 3) {
> - driver.driver_features &=
> - ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
> - } else if (!intel_agp_enabled) {
> - DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
> - return -ENODEV;
> - }
> + driver.driver_features &= ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);

Nothing else uses intel_agp_enabled, so it could be killed entirely.

>  
>   return drm_get_pci_dev(pdev, ent, );
>  }
> -- 
> 1.8.4.rc3

-- 
Ville Syrj?l?
Intel OTC

[PATCH 1/3] drm/i915: Make AGP=n work even on gen3

[Ville Syrjälä]

On Mon, Nov 11, 2013 at 09:35:17AM +0100, Daniel Vetter wrote:
> Most platforms din't hit this condition, but if we want to allow
> building without agp we should also make this allowed on gen3.
> 
> Cc: Ville Syrj?l? 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 38a344694e35..d7c922051c89 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -158,7 +158,7 @@ static struct drm_driver driver;
>  #if IS_ENABLED(CONFIG_AGP_INTEL)
>  extern int intel_agp_enabled;
>  #else
> -static int intel_agp_enabled;
> +static int intel_agp_enabled = 1;

Patch 2/3 eliminates our only use of intel_agp_enabled, so this patch
seems pointless.

>  #endif
>  
>  static const struct intel_device_info intel_i830_info = {
> -- 
> 1.8.4.rc3

-- 
Ville Syrj?l?
Intel OTC

[PATCHv4][ 3/7] staging: imx-drm: Add RGB666 support for parallel display.

[Laurent Pinchart]

Hi Russell,

On Wednesday 13 November 2013 19:12:30 Russell King - ARM Linux wrote:
> On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> > On 11/13/2013 2:23 AM, Denis Carikli wrote:
> >>   +/* rgb666 */
> >> 
> >> +  ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
> >> +  ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
> >> +  ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
> >> +  ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
> >> +
> >>return 0;
> >>   }
> > 
> > Since,  rgb24 and bgr24 reverse the byte numbers
> > /* rgb24 */
> > ipu_dc_map_clear(priv, IPU_DC_MAP_RGB24);
> > ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 0, 7, 0xff); /* blue */
> > ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 1, 15, 0xff); /* green
> > */
> > ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 2, 23, 0xff); /* red */
> > 
> > /* bgr24 */
> > ipu_dc_map_clear(priv, IPU_DC_MAP_BGR24);
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 2, 7, 0xff); /* red */
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green
> > */
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */
> > 
> > Shouldn't rgb666 and bgr666 do the same?
> > Currently we have,
> > 
> > /* bgr666 */
> > ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /*
> > green */
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
> 
> Yes, I concur - this doesn't make sense to me.  BGR666 would mean in
> memory:
> 
> 111
> 721650
> BBGGRR
> 
> which reflects the same order for "RGB24" above.

Beside component order and number of bits per component, an in-memory RGB 
format also defines the memory endianness and, for formats that don't span an 
interger number of bytes, the left or right alignment.

BGR666 is currently defined in V4L2 as

Byte 0 12
Bit  7  6  5  4  3  2  1  07  6  5  4  3  2  1  0   7  6  5  4  3  2  1  0

 b5 b4 b3 b2 b1 b0 g5 g4  g3 g2 g1 g0 r5 r4 r3 r2  r1 r0  -  -  -  -  -  -

(see the *second* table in 
http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html)

I would thus expect RGB666 to be

Byte 0 12
Bit  7  6  5  4  3  2  1  07  6  5  4  3  2  1  0   7  6  5  4  3  2  1  0

 r5 r4 r3 r2 r1 r0 g5 g4  g3 g2 g1 g0 b5 b4 b3 b2  b1 b0  -  -  -  -  -  -

We can also define right-aligned formats if needed.

> > Where I'd expect to see
> > /* bgr666 */
> > 
> > ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue
> > */
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /*
> > green */
> > ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */
> 
> So this makes sense to me.

-- 
Regards,

Laurent Pinchart

[Bug 57921] NULL pointer dereference in radeon_bo_create

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=57921

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 57921] NULL pointer dereference in radeon_bo_create

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=57921

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |OBSOLETE

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 58121] Radeon SUMO: LVDS panel blanks when enabling external monitor

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58121

--- Comment #5 from Alex Deucher  ---
(In reply to ??? from comment #4)
> This also appeared on my laptop(A6 3400M and A8 3500M) with Linux 3.5.0 to
> 3.11. For using external monitor, i can only use Linux 3.4.x. I an looking
> forward to use newer Linux kernel on my laptop.

Can you bisect?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 58121] Radeon SUMO: LVDS panel blanks when enabling external monitor

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58121

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
 Kernel Version|3.9 |3.11

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 58621] radeon 7770 kernel crash when changing powwr profile

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58621

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #7 from Alex Deucher  ---
Created attachment 114571
  --> https://bugzilla.kernel.org/attachment.cgi?id=114571=edit
fix

This patch should avoid the null pointer dereference.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 58621] radeon 7770 kernel crash when changing powwr profile

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58621

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
   Assignee|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org

--- Comment #6 from Alan  ---
[  257.496852] radeon :01:00.0: failed to get a new IB (-35)
[  257.498006] BUG: unable to handle kernel NULL pointer dereference at
  (null)
[  257.499132] IP: [] si_vm_set_page+0x2c6/0x420 [radeon]
[  257.500250] PGD 4233d6067 PUD 42332e067 PMD 0 
[  257.501340] Oops: 0002 [#1] PREEMPT SMP 
[  257.502418] Modules linked in: ebtable_nat ebtables ipt_MASQUERADE
iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM bridge stp llc btusb bluetooth
hid_a4tech mxm_wmi kvm_amd rtl8180 eeprom_93cx6 kvm crc32_pclmul crc32c_intel
ghash_clmulni_intel mac80211 cdc_acm aesni_intel aes_x86_64 snd_emu10k1 lrw
cfg80211 gf128mul glue_helper snd_util_mem ablk_helper snd_ac97_codec cryptd
rfkill snd_rawmidi fam15h_power pcspkr edac_core ac97_bus sp5100_tco k10temp
r8169 i2c_piix4 radeon ttm xhci_hcd drm_kms_helper wmi
[  257.508026] CPU: 4 PID: 2369 Comm: X Tainted: GW3.10.0-rc3 #1
[  257.509333] Hardware name: MSI MS-7693/970A-G46 (MS-7693), BIOS V1.11
10/31/2012
[  257.510533] task: 880426ff8000 ti: 880425896000 task.ti:
880425896000
[  257.511640] RIP: 0010:[]  []
si_vm_set_page+0x2c6/0x420 [radeon]
[  257.512749] RSP: 0018:880425897aa8  EFLAGS: 00010202
[  257.513827] RAX: 0061 RBX: 880425897b48 RCX:

[  257.514992] RDX: 0840 RSI: 0dfb8000 RDI:

[  257.516074] RBP: 8804283ce000 R08: 0dfb8000 R09:
000e
[  257.517168] R10:  R11: 24200840 R12:
0420
[  257.518338] R13: 00387b00 R14: 1000 R15:
0001
[  257.519536] FS:  7eff0ee7e880() GS:88043ed0()
knlGS:
[  257.520657] CS:  0010 DS:  ES:  CR0: 8005003b
[  257.521691] CR2:  CR3: 0004211a3000 CR4:
000407e0
[  257.522813] DR0:  DR1:  DR2:

[  257.523891] DR3:  DR6: 0ff0 DR7:
0400
[  257.524966] Stack:
[  257.526086]  ffdd 8804283ce000 0dfb8000
0614
[  257.527308]  8804283ce000 0018 880421032380
1f80
[  257.528422]  8804283ce000 0e3d8000 00387b00
a0067d4d
[  257.529451] Call Trace:
[  257.530519]  [] ? radeon_vm_bo_update_pte+0x39d/0x560
[radeon]
[  257.531604]  [] ? si_ib_parse+0x3c5/0x5f0 [radeon]
[  257.532649]  [] ? radeon_cs_ioctl+0x80c/0x8d0 [radeon]
[  257.533765]  [] ? drm_ioctl+0x49d/0x5a0
[  257.534957]  [] ? rcu_eqs_enter_common.isra.43+0x1e5/0x220
[  257.536061]  [] ? avc_has_perm_flags+0x74/0x150
[  257.537141]  [] ? do_vfs_ioctl+0x2ec/0x4d0
[  257.538192]  [] ? file_has_perm+0x8e/0xa0
[  257.539171]  [] ? SyS_ioctl+0x88/0xa0
[  257.540211]  [] ? tracesys+0xdd/0xe2
[  257.541202] Code: fe ff ff 66 90 48 89 f1 41 89 f0 48 c1 e9 20 48 89 cf 8b
4b 08 4c 8b 53 18 44 8d 59 01 44 89 5b 08 41 89 d3 41 81 cb 00 00 20 24 <45> 89
1c 8a 8b 4b 08 4c 8b 53 18 44 8d 59 01 44 89 5b 08 45 89 
[  257.543604] RIP  [] si_vm_set_page+0x2c6/0x420 [radeon]
[  257.544841]  RSP 

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 58831] Error compiling qxl_fb

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58831

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 Kernel Version||72de4c63e5ebe8e4054ea800d7a
   ||8d4b3f033caf2
   Assignee|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 58981] [BUISECTED] boot failure with Radeon 9250 PCI 256MB + KMS

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=58981

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
Summary|Bisected regression; boot   |[BUISECTED] boot failure
   |failure with Radeon 9250|with Radeon 9250 PCI 256MB
   |PCI 256MB + KMS |+ KMS

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 59101] Gnome shell crashes after sleep mode

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=59101

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk

--- Comment #6 from Alan  ---
I saw the same with triple headed Radeon in Ubuntu 13.04 - 13.10 so far seems
to be behaving better. Might be worth trying a recent setup therefore

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60371] Laptop with ATI RADEON card does not wake up from suspend to ram when kernel modesetting is enabled.

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60371

Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
   Assignee|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60552] Lock up using 3.10.0 + dpm patches

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60552

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60552] Lock up using 3.10.0 + dpm patches

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60552

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCHv4][ 3/7] staging: imx-drm: Add RGB666 support for parallel display.

[Russell King - ARM Linux]

On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> On 11/13/2013 2:23 AM, Denis Carikli wrote:
>>   +  /* rgb666 */
>> +ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
>> +
>>  return 0;
>>   }
>>   
>>
>
> Since,  rgb24 and bgr24 reverse the byte numbers
> /* rgb24 */
> ipu_dc_map_clear(priv, IPU_DC_MAP_RGB24);
> ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 0, 7, 0xff); /* blue */
> ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 1, 15, 0xff); /* green */
> ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 2, 23, 0xff); /* red */
>
> /* bgr24 */
> ipu_dc_map_clear(priv, IPU_DC_MAP_BGR24);
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 2, 7, 0xff); /* red */
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */


>
>
> Shouldn't rgb666 and bgr666 do the same?
> Currently we have,
>
> /* bgr666 */
> ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /*  
> green */
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */

Yes, I concur - this doesn't make sense to me.  BGR666 would mean in
memory:

111
721650
BBGGRR

which reflects the same order for "RGB24" above.

> Where I'd expect to see
> /* bgr666 */
> ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /*  
> green */
> ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */

So this makes sense to me.

possible regression Radeon RV280 (R3xx/R4xx ?) card freeze, re-apply old patch ?

[Jochen Rollwagen]

of code affected seems to be (IMHO) in drivers/gpu/drm/radeon/: 
>> The (Radeon ?) Register RADEON_CONFIG_APER_0_BASE is defined in radeon_reg.h 
>> but never used in the driver:
>>
>> radeon_reg.h:#define RADEON_CONFIG_APER_0_BASE   0x0100
>>
>> in r100.c there's
>>
>> static u32 r100_get_accessible_vram(struct radeon_device *rdev)
>> {
>>  u32 aper_size;
>>  u8 byte;
>>
>>  aper_size = RREG32(RADEON_CONFIG_APER_SIZE);
>>
>>  /* Set HDP_APER_CNTL only on cards that are known not to be broken,
>>   * that is has the 2nd generation multifunction PCI interface
>>   */
>>  if (rdev->family == CHIP_RV280 ||
>>  rdev->family >= CHIP_RV350) {
>>  WREG32_P(RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL,
>> ~RADEON_HDP_APER_CNTL);
>>  DRM_INFO("Generation 2 PCI interface, using max accessible 
>> memory\n");
>>  return aper_size * 2;
>>  }
>>
>> That's the code executed on my machine according to dmesg. Missing (from the 
>> original patch, not applicable any more because of driver reorganization) 
>> seems to be
>>
>> CARD32 aper0_base = INREG(RADEON_CONFIG_APER_0_BASE);
>> aper0_base &= ~(mem_size - 1);
>> info->mc_fb_location = (aper0_base >> 16);
>>
>> The patch that seems to have removed/overridden this code is:
>>
>> http://www.mail-archive.com/dri-devel at lists.sourceforge.net/msg41307.html
>>
>> According to that patch, it was "booted on PCI r100, PCIE rv370, IGP rs400". 
>> So IMHO this could be a classical regression for an AGP RV280 card (like 
>> mine) and might explain why PCI mode works. this is Additionally 
>> corroborated by this post 
>> (http://comments.gmane.org/gmane.comp.freedesktop.xorg/5429):
>>
>> * The above doesn't necessarily work. For example, I've seen machines * with 
>> 128Mb configured as 2x64Mb apertures. I'm now _always_ setting * 
>> RADEON_HOST_PATH_CNTL. OUTREGP (RADEON_HOST_PATH_CNTL, RADEON_HDP_APER_CNTL, 
>> ~RADEON_HDP_APER_CNTL); (which was previously done only on some chip 
>> families).
>>
>> I _think_ this is not correct on all cards as the apertures may not be 
>> configured correctly (and X doesn't set them up neither, if those correspond 
>> to the RADEON_CONFIG_APER registers)"
>>
>> Could a Radeon guru confirm this or am i totally lost?
>>
>> Cheers
>>
>> Jochen
>>  Original-Nachricht 
>> Betreff: Fwd: Re: regression on RV280 card freeze, patch not applicable any 
>> more
>> Datum: Fri, 18 Oct 2013 15:32:18 +0200
>> Von: Jochen Rollwagen 
>> An: xorg-driver-ati at lists.x.org
>>
>>
>> sorry about that.
>>
>> Anyway, i checked drivers/gpu/drm/radeon and
>> drivers/char/agp/uninorth-agp.c and can't seem to find the patch
>> indicated below. Might it have gone missing :-) ?
>>
>>
>> Am 08.10.2013 18:41, schrieb Michel D?nzer:
>>> [ Please always follow up to the mailing list ]
>>>
>>> On Die, 2013-10-08 at 14:53 +0200, Jochen Rollwagen wrote:
>>>> Am 08.10.2013 10:03, schrieb Michel D?nzer:
>>>>> On Sam, 2013-10-05 at 15:13 +0200, Jochen Rollwagen wrote:
>>>>>> I?m running a RV280 based Radeon 9200 card (I know, an ancient card)
>>>>>> in a Mac Mini G4 (powerpc-architecture) with Ubuntu Precise and the
>>>>>> latest 3.4.64-kernel/ati driver and get lockups when trying to run the
>>>>>> card in AGP mode (KMS enabled). The lockups happen when resetting the
>>>>>> card (that?s what I can infer from the oops-screen).
>>>>> It's the other way around: The kernel radeon driver resets the card to
>>>>> try and get it running again after a lockup.
>>>>>
>>>>>> PCI mode works. After researching I found a old bug that was fixed
>>>>>> back in 2006 (https://bugs.freedesktop.org/show_bug.cgi?id=6011) that
>>>>>> looks like the freeze I experience (since PCI mode ? which allocates
>>>>>> 64 MB of memory - works and AGP mode which by default allocates 256 MB
>>>>>> doesn?t). The card has 64 mb memory.
>>>>>>
>>>>>> So the first question is, could this be the problem that causes the
>>>>>> lockups ?
>>>>> Not really. The GART and VRAM memory apertures aren't directly related,
>>>>> and the fix for the bug above should still be incorporated in the
>>>>> current radeon KMS code.
>>>>>
>>>>> Does radeon.agpmode=1 or radeon.agpmode=4 work?
>>>>>
>>>> Thank you for your reply. First, none of the agpmodes work, they just
>>>> take more or less time to lockup the card (1 - slowest, 4 fastest).
>>>> Secondly, if you write that the fix "should be incorporated in the
>>>> current code", i'm somewhat lost because it definitely isn't there.
>>> It's in the kernel now.
>>>
>> Wellno. I checked the 3.4.64 kernel sources after my last Mail
>> and the code isn't in the drivers/gpu/drm/radeon sources. But of course
>> i might have overlooked something.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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/20131113/422b6d33/attachment.html>

[PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7

[Olof Johansson]

From: Duncan Laurie 

We had been using a DMI table workaround to select the right
frequency for devices, but this is fragile and must be updated
with every new platform.

Instead the default case when VBT is missing is changed to use
120MHz clock for LVDS SSC for these generations.

The docs for 2010-Core, SandyBridge, and IvyBridge all indicate
that the reference frequency for LVDS is 120MHz:

"2010 Core"
http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
page 38
Reference Frequency: 120MHz for CRT and LVDS.  100MHz for the FDI.

"2011 SandyBridge"
http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
page 33
Reference Frequency: 120MHz for CRT, HDMI, LVDS.  100MHz for the FDI.

"2012 IvyBridge"
http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf
page 27
Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI.

Signed-off-by: Duncan Laurie 
[olof: Fixup for recent base, switched from if/else to single call]
Signed-off-by: Olof Johansson 
---

Daniel,

This applies on top of -next, which I'm presuming is close to your
for-3.13 base right now. It'd be good to see this go in since it's needed
to boot on Chromebooks (with developer mode off), and is thus blocking
testing next/mainline on a regular basis here.

Thanks!

-Olof

 drivers/gpu/drm/i915/intel_bios.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 6dd622d733b9..e4fba39631a5 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -790,7 +790,12 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)

/* Default to using SSC */
dev_priv->vbt.lvds_use_ssc = 1;
-   dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, 1);
+   /*
+* Core/SandyBridge/IvyBridge use alternative (120MHz) reference
+* clock for LVDS.
+*/
+   dev_priv->vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev,
+   !HAS_PCH_SPLIT(dev));
DRM_DEBUG_KMS("Set default to SSC at %dMHz\n", 
dev_priv->vbt.lvds_ssc_freq);

for (port = PORT_A; port < I915_MAX_PORTS; port++) {
-- 
1.8.4.1.601.g02b3b1d

[BUG] gma500: sleeping function called from invalid context at kernel/mutex.c:413

[Patrik Jakobsson]

On Wed, Nov 13, 2013 at 4:49 PM, Holger Schurig  
wrote:
> Kernel: 3.10.19
>
> From time to time, when I booted, I had a completely dark screen (with
> kernel command line quiet) and a non-blinking cursor. I wondered if
> that was perhaps gma500. So I turned on various debug checks. Then
> I've got the BUG from the subject.
>
> The device is a " VGA compatible controller [0300]: Intel Corporation
> System Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108]
> (rev 07)".
>
> Here's relevant "dmesg" output:
>
> ...

Hi

We're calling backlight_update_status() in IRQ context which isn't allowed.

I'll add it to my todo list.

Thanks
Patrik

[Bug 55591] [BISECTED]Intel HDA / Nouveau: HDMI audio broken

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55591

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55591] [BISECTED]Intel HDA / Nouveau: HDMI audio broken

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55591

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #10 from Alan  ---
Thanks

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[BUG] gma500: sleeping function called from invalid context at kernel/mutex.c:413

[Holger Schurig]

Kernel: 3.10.19

>From time to time, when I booted, I had a completely dark screen (with
kernel command line quiet) and a non-blinking cursor. I wondered if
that was perhaps gma500. So I turned on various debug checks. Then
I've got the BUG from the subject.

The device is a " VGA compatible controller [0300]: Intel Corporation
System Controller Hub (SCH Poulsbo) Graphics Controller [8086:8108]
(rev 07)".

Here's relevant "dmesg" output:

...
PCI: Using MMCONFIG for extended config space
PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
ACPI: Power Resource [FAN1] (on)
...
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
...
r8169 :02:00.0 eth0: link up
[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness
acpi device:04: registered as cooling_device1
acpi device:05: registered as cooling_device2
ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input7
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
fbcon: psbdrmfb (fb0) is primary device
Console: switching to colour frame buffer device 100x37
gma500 :00:02.0: fb0: psbdrmfb frame buffer device
gma500 :00:02.0: registered panic notifier
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
[drm] Initialized gma500 1.0.0 2011-06-06 for :00:02.0 on minor 0
gma500 :00:02.0: Backlight lvds set brightness 7a127a12
BUG: sleeping function called from invalid context at kernel/mutex.c:413
in_atomic(): 1, irqs_disabled(): 1, pid: 310, name: Xorg
5 locks held by Xorg/310:
 #0:  (_info->lock){+.+.+.}, at: [] lock_fb_info+0x13/0x30
 #1:  (console_lock){+.+.+.}, at: [] do_fb_ioctl+0x3cf/0x44a
 #2:  ((fb_notifier_list).rwsem){.+}, at: []
__blocking_notifier_call_chain+0x1e/0x4f
 #3:  (_bd->ops_lock){+.+...}, at: []
fb_notifier_callback+0x31/0xaa
 #4:  (_bd->update_lock){+.+...}, at: []
fb_notifier_callback+0x7c/0xaa
irq event stamp: 31266
hardirqs last  enabled at (31265): []
_raw_spin_unlock_irqrestore+0x33/0x56
hardirqs last disabled at (31266): [] common_interrupt+0x2a/0x36
softirqs last  enabled at (30912): [] __do_softirq+0x1b1/0x208
softirqs last disabled at (30903): [] do_softirq+0x54/0xa1
CPU: 0 PID: 310 Comm: Xorg Tainted: G   O 3.10.19 #1
 f615dfa0 f615dfa0 f6c09ebc c12f8f85 f6c09ee0 c104dad6 c13f7580 0001
 0001 0136 f615e294 f5cc9818 f5cc9818 f6c09f30 c12faddc 0001
 ca825490 f5018104 f6330004 f615e4ac f615dfa0 f615e4b4 f6c09f98 3046
Call Trace:
 [] dump_stack+0x16/0x18
 [] __might_sleep+0xf8/0xff
 [] mutex_lock_nested+0x1e/0x317
 [] do_gma_backlight_set+0x1d/0x3d [gma500_gfx]
 [] gma_backlight_set+0x2a/0x2d [gma500_gfx]
 [] psb_intel_opregion_asle_intr+0xc4/0xe0 [gma500_gfx]
 [] psb_irq_handler+0x7e/0x176 [gma500_gfx]
 [] handle_irq_event_percpu+0x5a/0x1cf
 [] ? handle_fasteoi_irq+0x11/0x97
 [] handle_irq_event+0x2c/0x43
 [] ? handle_level_irq+0x98/0x98
 [] handle_fasteoi_irq+0x6a/0x97
   [] ? do_IRQ+0x37/0x9a
 [] ? acpi_ex_store+0xb8/0x219
 [] ? common_interrupt+0x31/0x36
 [] ? acpi_ds_load2_end_op+0x1e1/0x311
 [] ? acpi_ds_result_push+0x29/0x13e
 [] ? acpi_ds_clear_operands+0x17/0x33
 [] ? acpi_ds_exec_end_op+0x27e/0x3b0
 [] ? acpi_ps_append_arg+0x19/0x7d
 [] ? acpi_ps_parse_loop+0x4a4/0x4f0
 [] ? kfree+0xbb/0x13b
 [] ? acpi_ps_parse_aml+0x82/0x23f
 [] ? acpi_ps_execute_method+0x19c/0x23a
 [] ? acpi_ns_evaluate+0xaf/0x194
 [] ? acpi_evaluate_object+0xf1/0x1e5
 [] ? acpi_video_device_lcd_set_level+0x52/0xd3
 [] ? acpi_video_set_brightness+0x21/0x24
 [] ? fb_notifier_callback+0x8f/0xaa
 [] ? notifier_call_chain+0x25/0x46
 [] ? __blocking_notifier_call_chain+0x39/0x4f
 [] ? blocking_notifier_call_chain+0x1a/0x1c
 [] ? fb_notifier_call_chain+0x11/0x13
 [] ? fb_blank+0x6a/0x73
 [] ? do_fb_ioctl+0x3e3/0x44a
 [] ? mark_held_locks+0xb3/0xd6
 [] ? ftrace_raw_event_mm_page+0x85/0x90
 [] ? do_fb_ioctl+0x44a/0x44a
 [] ? fb_ioctl+0x20/0x29
 [] ? vfs_ioctl+0x1b/0x25
 [] ? do_vfs_ioctl+0x413/0x451
 [] ? do_mmap_pgoff+0x24c/0x2bf
 [] ? up_write+0x16/0x2b
 [] ? vm_mmap_pgoff+0x57/0x73
 [] ? restore_all+0xf/0xf
 [] ? SyS_ioctl+0x3d/0x5b
 [] ? syscall_call+0x7/0xb
=
[ INFO: inconsistent lock state ]
3.10.19 #1 Tainted: G   O
-
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
Xorg/310 [HC1[1]:SC0[0]:HE0:SE1] takes:
 (_bd->update_lock){?.+...}, at: []
do_gma_backlight_set+0x1d/0x3d [gma500_gfx]
{HARDIRQ-ON-W} state was registered at:
  [] __lock_acquire+0x564/0x1664
  [] lock_acquire+0xbf/0xfa
  [] mutex_lock_nested+0x5b/0x317
  [] psb_backlight_init+0xf4/0x149 [gma500_gfx]
  [] gma_backlight_init+0x16/0x18 [gma500_gfx]
  [] psb_driver_load+0x37e/0x3c2 [gma500_gfx]
  [] 

[Bug 55591] [BISECTED]Intel HDA / Nouveau: HDMI audio broken

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55591

--- Comment #9 from Rickard N?rstr?m  ---
I do not have this problem since version 3.11 of the kernel.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60694] nvc3 suspend hangs

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60694

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60694] nvc3 suspend hangs

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60694

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |INSUFFICIENT_DATA

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 55591] [BISECTED]Intel HDA / Nouveau: HDMI audio broken

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=55591

Takashi Iwai  changed:

   What|Removed |Added

 CC||tiwai at suse.de
  Component|Sound(ALSA) |Video(DRI - non Intel)
   Assignee|perex at perex.cz  |drivers_video-dri at 
kernel-bu
   ||gs.osdl.org

--- Comment #8 from Takashi Iwai  ---
Looks like rather a regression in Nouveau driver...

Does the problem still happen with the latest kernel?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60720] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60720

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 60720] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60720

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |MOVED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/radeon/vm: don't attempt to update ptes if ib allocation fails

[Alex Deucher]

If we fail to allocate an indirect buffer (ib) when updating
the ptes, return an error instead of trying to use the ib.
Avoids a null pointer dereference.

Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=58621

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_gart.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index cd7489b..3044e50 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -1209,6 +1209,8 @@ int radeon_vm_bo_update_pte(struct radeon_device *rdev,
return -ENOMEM;

r = radeon_ib_get(rdev, R600_RING_TYPE_DMA_INDEX, , NULL, ndw * 4);
+   if (r)
+   return r;
ib.length_dw = 0;

r = radeon_vm_update_pdes(rdev, vm, , bo_va->soffset, 
bo_va->eoffset);
-- 
1.8.3.1

[PATCH 5/5] drm/rcar-du: Add support for the r8a7791 DU

[Laurent Pinchart]

The r8a7791 DU is a stripped-down version of the r8a7790 DU with two
CRTCs and a single LVDS output.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 4eee02f..5536811 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -272,9 +272,29 @@ static const struct rcar_du_device_info 
rcar_du_r8a7790_info = {
.num_lvds = 2,
 };

+static const struct rcar_du_device_info rcar_du_r8a7791_info = {
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
+   .num_crtcs = 2,
+   .routes = {
+   /* R8A7791 has one RGB output, one LVDS output and one
+* (currently unsupported) TCON output.
+*/
+   [RCAR_DU_OUTPUT_DPAD0] = {
+   .possible_crtcs = BIT(1),
+   .encoder_type = DRM_MODE_ENCODER_NONE,
+   },
+   [RCAR_DU_OUTPUT_LVDS0] = {
+   .possible_crtcs = BIT(0),
+   .encoder_type = DRM_MODE_ENCODER_LVDS,
+   },
+   },
+   .num_lvds = 1,
+};
+
 static const struct platform_device_id rcar_du_id_table[] = {
{ "rcar-du-r8a7779", (kernel_ulong_t)_du_r8a7779_info },
{ "rcar-du-r8a7790", (kernel_ulong_t)_du_r8a7790_info },
+   { "rcar-du-r8a7791", (kernel_ulong_t)_du_r8a7791_info },
{ }
 };

-- 
1.8.3.2

[PATCH 4/5] drm/rcar-du: Add LVDS_LANES quirk

[Laurent Pinchart]

LVDS lanes 1 and 3 are switched in ES1 hardware (R8A7790). The problem
has been fixed in newer revisions, add a quirk to make the workaround
selectable.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ++-
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index a0ffacb..4eee02f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -250,7 +250,7 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {

 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
-   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
.num_crtcs = 3,
.routes = {
/* R8A7790 has one RGB output, two LVDS outputs and one
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 7ca98f3..e31b735 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -31,6 +31,7 @@ struct rcar_du_lvdsenc;
 #define RCAR_DU_FEATURE_DEFR8  (1 << 1)/* Has DEFR8 register */

 #define RCAR_DU_QUIRK_ALIGN_128B   (1 << 0)/* Align pitches to 128 
bytes */
+#define RCAR_DU_QUIRK_LVDS_LANES   (1 << 1)/* LVDS lanes 1 and 3 
inverted */

 /*
  * struct rcar_du_output_routing - Output routing specification
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index a0f6a17..3dc1331 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -44,6 +44,7 @@ static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
const struct drm_display_mode *mode = >crtc.mode;
unsigned int freq = mode->clock;
u32 lvdcr0;
+   u32 lvdhcr;
u32 pllcr;
int ret;

@@ -72,15 +73,19 @@ static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc 
*lvds,
 * VSYNC -> CTRL1
 * DISP  -> CTRL2
 * 0 -> CTRL3
-*
-* Channels 1 and 3 are switched on ES1.
 */
rcar_lvds_write(lvds, LVDCTRCR, LVDCTRCR_CTR3SEL_ZERO |
LVDCTRCR_CTR2SEL_DISP | LVDCTRCR_CTR1SEL_VSYNC |
LVDCTRCR_CTR0SEL_HSYNC);
-   rcar_lvds_write(lvds, LVDCHCR,
-   LVDCHCR_CHSEL_CH(0, 0) | LVDCHCR_CHSEL_CH(1, 3) |
-   LVDCHCR_CHSEL_CH(2, 2) | LVDCHCR_CHSEL_CH(3, 1));
+
+   if (rcar_du_needs(lvds->dev, RCAR_DU_QUIRK_LVDS_LANES))
+   lvdhcr = LVDCHCR_CHSEL_CH(0, 0) | LVDCHCR_CHSEL_CH(1, 3)
+  | LVDCHCR_CHSEL_CH(2, 2) | LVDCHCR_CHSEL_CH(3, 1);
+   else
+   lvdhcr = LVDCHCR_CHSEL_CH(0, 0) | LVDCHCR_CHSEL_CH(1, 1)
+  | LVDCHCR_CHSEL_CH(2, 2) | LVDCHCR_CHSEL_CH(3, 3);
+
+   rcar_lvds_write(lvds, LVDCHCR, lvdhcr);

/* Select the input, hardcode mode 0, enable LVDS operation and turn
 * bias circuitry on.
-- 
1.8.3.2

[PATCH 3/5] drm/rcar-du: Split features and quirks

[Laurent Pinchart]

128-byte pitch alignement is not a hardware feature, it's a hardware
bug. Split it from the features field into a new quirks field. New
quirks will be added to support the R8A7791 SoC.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_drv.h | 13 +++--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  4 ++--
 3 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 0023f97..a0ffacb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -249,8 +249,8 @@ static const struct rcar_du_device_info 
rcar_du_r8a7779_info = {
 };

 static const struct rcar_du_device_info rcar_du_r8a7790_info = {
-   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_ALIGN_128B
- | RCAR_DU_FEATURE_DEFR8,
+   .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK | RCAR_DU_FEATURE_DEFR8,
+   .quirks = RCAR_DU_QUIRK_ALIGN_128B,
.num_crtcs = 3,
.routes = {
/* R8A7790 has one RGB output, two LVDS outputs and one
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 65d2d63..7ca98f3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -28,8 +28,9 @@ struct rcar_du_device;
 struct rcar_du_lvdsenc;

 #define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK (1 << 0)/* Per-CRTC IRQ and 
clock */
-#define RCAR_DU_FEATURE_ALIGN_128B (1 << 1)/* Align pitches to 128 
bytes */
-#define RCAR_DU_FEATURE_DEFR8  (1 << 2)/* Has DEFR8 register */
+#define RCAR_DU_FEATURE_DEFR8  (1 << 1)/* Has DEFR8 register */
+
+#define RCAR_DU_QUIRK_ALIGN_128B   (1 << 0)/* Align pitches to 128 
bytes */

 /*
  * struct rcar_du_output_routing - Output routing specification
@@ -48,12 +49,14 @@ struct rcar_du_output_routing {
 /*
  * struct rcar_du_device_info - DU model-specific information
  * @features: device features (RCAR_DU_FEATURE_*)
+ * @quirks: device quirks (RCAR_DU_QUIRK_*)
  * @num_crtcs: total number of CRTCs
  * @routes: array of CRTC to output routes, indexed by output 
(RCAR_DU_OUTPUT_*)
  * @num_lvds: number of internal LVDS encoders
  */
 struct rcar_du_device_info {
unsigned int features;
+   unsigned int quirks;
unsigned int num_crtcs;
struct rcar_du_output_routing routes[RCAR_DU_OUTPUT_MAX];
unsigned int num_lvds;
@@ -84,6 +87,12 @@ static inline bool rcar_du_has(struct rcar_du_device *rcdu,
return rcdu->info->features & feature;
 }

+static inline bool rcar_du_needs(struct rcar_du_device *rcdu,
+unsigned int quirk)
+{
+   return rcdu->info->quirks & quirk;
+}
+
 static inline u32 rcar_du_read(struct rcar_du_device *rcdu, u32 reg)
 {
return ioread32(rcdu->mmio + reg);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b31ac08..fbeabd9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -119,7 +119,7 @@ int rcar_du_dumb_create(struct drm_file *file, struct 
drm_device *dev,
/* The R8A7779 DU requires a 16 pixels pitch alignment as documented,
 * but the R8A7790 DU seems to require a 128 bytes pitch alignment.
 */
-   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_ALIGN_128B))
+   if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
align = 128;
else
align = 16 * args->bpp / 8;
@@ -144,7 +144,7 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file 
*file_priv,
return ERR_PTR(-EINVAL);
}

-   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_ALIGN_128B))
+   if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
align = 128;
else
align = 16 * format->bpp / 8;
-- 
1.8.3.2

[PATCH 2/5] drm/rcar-du: Update plane pitch in .mode_set_base() operation

[Laurent Pinchart]

When setting a new frame buffer with the mode set base operation the
pitch value might change. Set the hardware plane pitch register at the
same time as the plane base address in the rcar_du_plane_update_base()
function to make sure the pitch value always matches the frame buffer.

Cc: stable at vger.kernel.org
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  1 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 21 +++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index d2af2bc..fbf4be3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -371,7 +371,6 @@ static int rcar_du_crtc_mode_set(struct drm_crtc *crtc,
goto error;

rcrtc->plane->format = format;
-   rcrtc->plane->pitch = crtc->fb->pitches[0];

rcrtc->plane->src_x = x;
rcrtc->plane->src_y = y;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 5300064..3fb69d9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -104,6 +104,15 @@ void rcar_du_plane_update_base(struct rcar_du_plane *plane)
 {
struct rcar_du_group *rgrp = plane->group;
unsigned int index = plane->hwindex;
+   u32 mwr;
+
+   /* Memory pitch (expressed in pixels) */
+   if (plane->format->planes == 2)
+   mwr = plane->pitch;
+   else
+   mwr = plane->pitch * 8 / plane->format->bpp;
+
+   rcar_du_plane_write(rgrp, index, PnMWR, mwr);

/* The Y position is expressed in raster line units and must be doubled
 * for 32bpp formats, according to the R8A7790 datasheet. No mention of
@@ -133,6 +142,8 @@ void rcar_du_plane_compute_base(struct rcar_du_plane *plane,
 {
struct drm_gem_cma_object *gem;

+   plane->pitch = fb->pitches[0];
+
gem = drm_fb_cma_get_gem_obj(fb, 0);
plane->dma[0] = gem->paddr + fb->offsets[0];

@@ -209,7 +220,6 @@ static void __rcar_du_plane_setup(struct rcar_du_plane 
*plane,
struct rcar_du_group *rgrp = plane->group;
u32 ddcr2 = PnDDCR2_CODE;
u32 ddcr4;
-   u32 mwr;

/* Data format
 *
@@ -240,14 +250,6 @@ static void __rcar_du_plane_setup(struct rcar_du_plane 
*plane,
rcar_du_plane_write(rgrp, index, PnDDCR2, ddcr2);
rcar_du_plane_write(rgrp, index, PnDDCR4, ddcr4);

-   /* Memory pitch (expressed in pixels) */
-   if (plane->format->planes == 2)
-   mwr = plane->pitch;
-   else
-   mwr = plane->pitch * 8 / plane->format->bpp;
-
-   rcar_du_plane_write(rgrp, index, PnMWR, mwr);
-
/* Destination position and size */
rcar_du_plane_write(rgrp, index, PnDSXR, plane->width);
rcar_du_plane_write(rgrp, index, PnDSYR, plane->height);
@@ -309,7 +311,6 @@ rcar_du_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,

rplane->crtc = crtc;
rplane->format = format;
-   rplane->pitch = fb->pitches[0];

rplane->src_x = src_x >> 16;
rplane->src_y = src_y >> 16;
-- 
1.8.3.2

[PATCH 1/5] drm/rcar-du: Don't cast crtc to rcrtc twice in the same function

[Laurent Pinchart]

Reuse the previously cast variable instead.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index a9d24e4..d2af2bc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -413,7 +413,7 @@ static int rcar_du_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
rcrtc->plane->src_x = x;
rcrtc->plane->src_y = y;

-   rcar_du_crtc_update_base(to_rcar_crtc(crtc));
+   rcar_du_crtc_update_base(rcrtc);

return 0;
 }
-- 
1.8.3.2

[PATCH 0/5] R-Car DU fixes and support for R8A7791

[Laurent Pinchart]

Hello,

This patch series adds support for the DU found in the R8A7791 SoC. It starts
by a cleanup patch (1/5), a bug fix (2/5), two preparation patches (3/5 and
4/5) and finally adds support for the R8A7791 DU (5/5).

Patch 2/5 is a candidate for stable kernels. There's no rush to get this
upstreamed in v3.13, v3.14 is fine.

The series is based on top of the latest drm-next branch.

Laurent Pinchart (5):
  drm/rcar-du: Don't cast crtc to rcrtc twice in the same function
  drm/rcar-du: Update plane pitch in .mode_set_base() operation
  drm/rcar-du: Split features and quirks
  drm/rcar-du: Add LVDS_LANES quirk
  drm/rcar-du: Add support for the r8a7791 DU

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  3 +--
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 24 ++--
 drivers/gpu/drm/rcar-du/rcar_du_drv.h | 14 --
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ++-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   | 21 +++--
 6 files changed, 58 insertions(+), 23 deletions(-)

-- 
Regards,

Laurent Pinchart

[Bug 62601] 3.11 radeon hdmi audio does not work

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=62601

Alan  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 62601] 3.11 radeon hdmi audio does not work

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=62601

Alan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||alan at lxorguk.ukuu.org.uk
 Resolution|--- |CODE_FIX

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCHv4][ 4/7] staging: imx-drm: parallel display: add regulator support.

[Alexander Shiyan]

Hello.

?, 13 ?? 2013, 10:23 +01:00 ?? Denis Carikli :
...
> --- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
...
> @@ -139,6 +141,12 @@ static void imx_pd_encoder_prepare(struct drm_encoder 
> *encoder)
>  {
>   struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
>  
> + if (imxpd->disp_reg && !regulator_is_enabled(imxpd->disp_reg)) {

if (!IS_ERR(imxpd->disp_reg) && ...

> + if (regulator_enable(imxpd->disp_reg))
> + dev_err(imxpd->dev,
> + "Failed to enable regulator.\n");
> + }
> +
>   imx_drm_crtc_panel_format(encoder->crtc, DRM_MODE_ENCODER_NONE,
>   imxpd->interface_pix_fmt);
>  }
> @@ -155,6 +163,12 @@ static void imx_pd_encoder_mode_set(struct drm_encoder 
> *encoder,
>  
>  static void imx_pd_encoder_disable(struct drm_encoder *encoder)
>  {
> + struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
> +
> + if (imxpd->disp_reg && regulator_is_enabled(imxpd->disp_reg)) {

if (!IS_ERR(imxpd->disp_reg) && ...

> + if (regulator_disable(imxpd->disp_reg))
> + dev_err(imxpd->dev, "Failed to disable regulator.\n");
> + }
>  }
>  
>  static void imx_pd_encoder_destroy(struct drm_encoder *encoder)
> @@ -258,6 +272,14 @@ static int imx_pd_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
>  
> + imxpd->disp_reg = devm_regulator_get(>dev, "display");
> + if (IS_ERR(imxpd->disp_reg)) {

if (PTR_ERR(imxpd->disp_reg) == -EPROBE_DEFER)
return -EPROBE_DEFER;

> + dev_warn(>dev, "Operating without display regulator.\n");

dev_dbg

> + imxpd->disp_reg = NULL;

No need set this to NULL;

> + } else {
> + dev_info(>dev, "Using display regulator.\n");

Useless.

...

---

[Bug 64225] bfgminer --scyte generates Segmentation Fault on Northern Island

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64225

--- Comment #9 from Alexey Shvetsov  ---
Still failes 

0x7f57a0454d20: i32 = GlobalAddress*)* @salsa> 0 [ORD=9236]

-- 
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/20131113/87426880/attachment.html>

[Bug 71570] vdpau freeze the browsers, after play a flash video

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71570

--- Comment #1 from Kertesz Laszlo  ---
Sorry for not being contrtructive with this reply, but hardware decoding with
flash player was always shoddy even with nvidia for which it was intended in
the first place and bug reports like this should be directed to the flash
developers first since the flash plugin is not open source and has issues with
nvidia too (read below).

Also note that the plugin destined for browsers that are not Chrome will not be
updated anymore so the only possible solution would be filing a bug for the
Chrome version of Flash (which in my experience is worse than the Firefox
flash on radeon at the moment).

The only site which works ok ish is youtube (there might be others), but hw
decoding enabled crashes the plugin on many other sites.
This happened with nvidia (i had a nvidia 8200 IGP which had vdpau B class
which worked very well with VDPAU otherwise) and it still happens with my
A8-5500 (Radeon 7560 IGP) with the latest git Mesa, kernel, drm.

So its most likely a Flash issue.

Funny thing is that the AMD GPU with radeon/VDPAU works better with the legacy
flash on Seamonkey/Firefox (nvidia had inverted colors sometimes on youtube and
HW decoding wasnt working consitently)...

-- 
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/20131113/70dc95a3/attachment.html>

[PATCHv4][ 3/7] staging: imx-drm: Add RGB666 support for parallel display.

[Troy Kisky]

On 11/13/2013 2:23 AM, Denis Carikli wrote:
>   
> + /* rgb666 */
> + ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
> + ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
> + ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
> + ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
> +
>   return 0;
>   }
>   
>

Since,  rgb24 and bgr24 reverse the byte numbers
/* rgb24 */
 ipu_dc_map_clear(priv, IPU_DC_MAP_RGB24);
 ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 0, 7, 0xff); /* blue */
 ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 1, 15, 0xff); /* green */
 ipu_dc_map_config(priv, IPU_DC_MAP_RGB24, 2, 23, 0xff); /* red */

/* bgr24 */
 ipu_dc_map_clear(priv, IPU_DC_MAP_BGR24);
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 2, 7, 0xff); /* red */
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */


Shouldn't rgb666 and bgr666 do the same?
Currently we have,

/* bgr666 */
 ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* 
green */
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */

Where I'd expect to see
/* bgr666 */
 ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* 
green */
 ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */


So, it looks like you are adding a duplicate of bgr666 because bgr666 is 
wrong.
Also, I'd prefer to keep the entries in 0,1,2 byte number order(blue, 
green, red,
assuming byte 0 is always blue) so that duplicates are easier to spot.

Not related to this patch, but the comments on gbr24 appear wrong as well.

/* gbr24 */
 ipu_dc_map_clear(priv, IPU_DC_MAP_GBR24);
 ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 2, 15, 0xff); /* green */
 ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 1, 7, 0xff); /* blue */
 ipu_dc_map_config(priv, IPU_DC_MAP_GBR24, 0, 23, 0xff); /* red */

Should be
/* brg24 */
 ipu_dc_map_clear(priv, IPU_DC_MAP_BRG24);
 ipu_dc_map_config(priv, IPU_DC_MAP_BRG24, 0, 23, 0xff); /* blue*/
 ipu_dc_map_config(priv, IPU_DC_MAP_BRG24, 1, 7, 0xff); /* green */
 ipu_dc_map_config(priv, IPU_DC_MAP_BRG24, 2, 15, 0xff); /* red */

Of course, my understanding may be totally wrong. If so, please show me 
the light!


Troy

[PATCH] drm: check for !kdev in drm_unplug_minor()

[David Herrmann]

We moved minor deallocation to drm_dev_free() in:
  commit 8f6599da8e772fa8de54cdf98e9e03cbaf3946da
  Author: David Herrmann 
  Date:   Sun Oct 20 18:55:45 2013 +0200

  drm: delay minor destruction to drm_dev_free()

However, this causes a call to drm_unplug_minor(), which should just do
nothing as drm_dev_unregister() already called this.

But a separate patch caused kdev lifetime changes:
  commit 5bdebb183c9702a8c57a01dff09337be3de337a6
  Author: Dave Airlie 
  Date:   Fri Oct 11 14:07:25 2013 +1000

  drm/sysfs: sort out minor and connector device object lifetimes.

Thus making our dev_is_registered() call useles (and even segfault if it
is NULL). Replace it with a simple !kdev test and we're fine.

Reported-by: Huax Lu 
Reported-by: Daniel Vetter 
Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_stub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index c200136..f53d524 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -338,7 +338,7 @@ err_idr:
  */
 static void drm_unplug_minor(struct drm_minor *minor)
 {
-   if (!minor || !device_is_registered(minor->kdev))
+   if (!minor || !minor->kdev)
return;

 #if defined(CONFIG_DEBUG_FS)
-- 
1.8.4.2

[Bug 71570] New: vdpau freeze the browsers, after play a flash video

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71570

  Priority: medium
Bug ID: 71570
  Assignee: dri-devel at lists.freedesktop.org
   Summary: vdpau freeze the browsers, after play a flash video
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: markurujapan at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

When I play a flash video on ubuntu 13.10, with vdpau enabled, when the video
ends, the browsers freeze for 10/15 seconds, ( the bug doesn't happen in
youtube, only on others webs.


francesco at francesco-desktop:~$ glxinfo | grep "OpenGL version"
OpenGL version string: 3.0 Mesa 10.0.0-devel (git-08122e1 saucy-oibaf-ppa)

-- 
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/20131113/b05210a8/attachment.html>

[patch] drm/nouveau/disp: add a comment on confusing loop

[Dan Carpenter]

The "ret = -EIO" is deliberate.  It's a very uncommon thing to do and it
upsets static checkers because they normally would expect "ret == -EIO".

Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
index 1bd4c63..2bc45ae 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
@@ -322,6 +322,7 @@ nouveau_dp_train(struct nouveau_disp *disp, const struct 
nouveau_dp_func *func,
while (*link_bw > (dp->dpcd[1] * 27000))
link_bw++;

+   /* set ret to -EIO on the last loop iteration */
while ((ret = -EIO) && link_bw[0]) {
/* find minimum required lane count at this link rate */
dp->link_nr = dp->dpcd[2] & DPCD_RC02_MAX_LANE_COUNT;

[PATCHv4][ 7/7] ARM: imx_v6_v7_defconfig: Enable backlight gpio support.

[Denis Carikli]

The eukrea mbimxsd51 has a gpio backlight for its
  LCD display, so we turn that driver on.

Cc: Sascha Hauer 
Cc: linux-arm-kernel at lists.infradead.org
Cc: Fabio Estevam 
Cc: Shawn Guo 
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
---
 arch/arm/configs/imx_v6_v7_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index c814e0e..910122c 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -178,6 +178,7 @@ CONFIG_LCD_L4F00242T03=y
 CONFIG_LCD_PLATFORM=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_GPIO=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 CONFIG_SOUND=y
-- 
1.7.9.5

[PATCHv4][ 6/7] ARM: dts: mbimx51sd: Add CMO-QVGA backlight support.

[Denis Carikli]

Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
---
ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51 
boards.
- This patch now only adds backlight support.
- Added some interested people in the Cc list, and removed some people that
  might be annoyed by the receiving of that patch which is unrelated to their
  subsystem.
---
 .../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts  |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts 
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
index 4c781e7..73b00b7 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -22,6 +22,14 @@
model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga", 
"eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";

+   backlight {
+   compatible = "gpio-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_backlight_1>;
+   gpios = < 4 0>;
+   default-brightness-level = <1>;
+   };
+
reg_lcd_3v3: lcd-en {
compatible = "regulator-fixed";
pinctrl-names = "default";
-- 
1.7.9.5

[PATCHv4][ 5/7] ARM: dts: mbimx51sd: Add display support.

[Denis Carikli]

The CMO-QVGA, DVI-SVGA and DVI-VGA are added.

Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
---
ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51 
boards.
- This patch now only adds display support.
- Added some interested people in the Cc list, and removed some people that
  might be annoyed by the receiving of that patch which is unrelated to their
  subsystem.
- rebased and reworked the dts displays addition.
- Also rebased and reworked the fsl,pins usage.
---
 .../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts  |   61 
 .../imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts  |   47 +++
 .../imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts   |   47 +++
 .../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts  |   13 +
 4 files changed, 168 insertions(+)
 create mode 100644 
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
 create mode 100644 
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
 create mode 100644 
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts

diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts 
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
new file mode 100644
index 000..4c781e7
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -0,0 +1,61 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+   model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
+   compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga", 
"eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+
+   reg_lcd_3v3: lcd-en {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_reg_lcd_3v3>;
+   regulator-name = "lcd-3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 13 0>;
+   enable-active-high;
+   };
+
+};
+
+ {
+   display-supply = <_lcd_3v3>;
+   status = "okay";
+   display-timings {
+   model = "CMO-QVGA";
+   bits-per-pixel = <16>;
+   cmoqvga {
+   native-mode;
+   clock-frequency = <650>;
+   hactive = <320>;
+   vactive = <240>;
+   hfront-porch = <20>;
+   hback-porch = <38>;
+   vfront-porch = <4>;
+   vback-porch = <15>;
+   hsync-len = <30>;
+   vsync-len = <3>;
+   hsync-active = <0>;
+   vsync-active = <0>;
+   de-active = <0>;
+   pixelclk-active = <1>;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts 
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
new file mode 100644
index 000..e9be19c
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2013 Eukr?a Electromatique 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+   model = "Eukrea MBIMXSD51 with the DVI-SVGA Display";
+   compatible = "eukrea,mbimxsd51-baseboard-dvi-svga", 

[PATCHv4][ 4/7] staging: imx-drm: parallel display: add regulator support.

[Denis Carikli]

Cc: Dan Carpenter 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Stephen Warren 
Cc: Ian Campbell 
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- the lcd-supply is now called display-supply (not all display are LCD).
- The code and documentation was updated accordingly.
- regulator_is_enabled now guard the regulator enables/disables because
  regulator_disable does not check the regulator state.
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |1 +
 drivers/staging/imx-drm/parallel-display.c |   22 
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index 2d24425..4dd7ce5 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -28,6 +28,7 @@ Required properties:
 - compatible: Should be "fsl,imx-parallel-display"
 - crtc: the crtc this display is connected to, see below
 Optional properties:
+- display-supply : phandle to the regulator device tree node if needed.
 - interface_pix_fmt: How this display is connected to the
   crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
 - edid: verbatim EDID data block describing attached display.
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index 46b6fce..195ec60 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "imx-drm.h"
@@ -35,6 +36,7 @@ struct imx_parallel_display {
struct drm_encoder encoder;
struct imx_drm_encoder *imx_drm_encoder;
struct device *dev;
+   struct regulator *disp_reg;
void *edid;
int edid_len;
u32 interface_pix_fmt;
@@ -139,6 +141,12 @@ static void imx_pd_encoder_prepare(struct drm_encoder 
*encoder)
 {
struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);

+   if (imxpd->disp_reg && !regulator_is_enabled(imxpd->disp_reg)) {
+   if (regulator_enable(imxpd->disp_reg))
+   dev_err(imxpd->dev,
+   "Failed to enable regulator.\n");
+   }
+
imx_drm_crtc_panel_format(encoder->crtc, DRM_MODE_ENCODER_NONE,
imxpd->interface_pix_fmt);
 }
@@ -155,6 +163,12 @@ static void imx_pd_encoder_mode_set(struct drm_encoder 
*encoder,

 static void imx_pd_encoder_disable(struct drm_encoder *encoder)
 {
+   struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
+
+   if (imxpd->disp_reg && regulator_is_enabled(imxpd->disp_reg)) {
+   if (regulator_disable(imxpd->disp_reg))
+   dev_err(imxpd->dev, "Failed to disable regulator.\n");
+   }
 }

 static void imx_pd_encoder_destroy(struct drm_encoder *encoder)
@@ -258,6 +272,14 @@ static int imx_pd_probe(struct platform_device *pdev)
if (ret)
return ret;

+   imxpd->disp_reg = devm_regulator_get(>dev, "display");
+   if (IS_ERR(imxpd->disp_reg)) {
+   dev_warn(>dev, "Operating without display regulator.\n");
+   imxpd->disp_reg = NULL;
+   } else {
+   dev_info(>dev, "Using display regulator.\n");
+   }
+
ret = imx_drm_encoder_add_possible_crtcs(imxpd->imx_drm_encoder, np);

platform_set_drvdata(pdev, imxpd);
-- 
1.7.9.5

[PATCHv4][ 3/7] staging: imx-drm: Add RGB666 support for parallel display.

[Denis Carikli]

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Stephen Warren 
Cc: Ian Campbell 
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Mauro Carvalho Chehab 
Cc: Laurent Pinchart 
Cc: linux-media at vger.kernel.org
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
---
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed the commit message long desciption that was just a copy of the short
  description.
- Rebased the patch.
- Fixed a copy-paste error in the ipu_dc_map_clear parameter.
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |2 +-
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|9 +
 drivers/staging/imx-drm/parallel-display.c |2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d49..2d24425 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -29,7 +29,7 @@ Required properties:
 - crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+  crtc. Currently supported types: "rgb24", "rgb565", "bgr666", "rgb666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c 
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index d0e3bc3..bcc7680 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
@@ -92,6 +92,7 @@ enum ipu_dc_map {
IPU_DC_MAP_GBR24, /* TVEv2 */
IPU_DC_MAP_BGR666,
IPU_DC_MAP_BGR24,
+   IPU_DC_MAP_RGB666,
 };

 struct ipu_dc {
@@ -155,6 +156,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_BGR666;
case V4L2_PIX_FMT_BGR24:
return IPU_DC_MAP_BGR24;
+   case V4L2_PIX_FMT_RGB666:
+   return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -404,6 +407,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */

+   /* rgb666 */
+   ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+   ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+
return 0;
 }

diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index b34f3a3..46b6fce 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -248,6 +248,8 @@ static int imx_pd_probe(struct platform_device *pdev)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, "bgr666"))
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+   else if (!strcmp(fmt, "rgb666"))
+   imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
}

imxpd->dev = >dev;
-- 
1.7.9.5

[PATCHv4][ 2/7] staging: imx-drm: Use de-active and pixelclk-active display-timings.

[Denis Carikli]

If de-active and/or pixelclk-active properties were set in the
display-timings DT node, they were not used.

Instead the data-enable and the pixel data clock polarity
were hardcoded.

This change is needed for making the eukrea-cpuimx51
  QVGA display work.

Greg Kroah-Hartman 
Cc: driverdev-devel at linuxdriverproject.org
Cc: Philipp Zabel 
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
---
ChangeLog v3->v4:
- The old patch was named "staging: imx-drm: ipuv3-crtc: don't harcode some 
mode".
- Reworked the patch entierly: we now takes the mode flags from the device tree.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Ajusted the flags to match the changes in "drm: Add the lacking
  DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
---
 drivers/staging/imx-drm/imx-drm.h  |3 +++
 drivers/staging/imx-drm/ipuv3-crtc.c   |   11 +--
 drivers/staging/imx-drm/parallel-display.c |   28 
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/imx-drm/imx-drm.h 
b/drivers/staging/imx-drm/imx-drm.h
index ae90c9c..dfdc180 100644
--- a/drivers/staging/imx-drm/imx-drm.h
+++ b/drivers/staging/imx-drm/imx-drm.h
@@ -5,6 +5,9 @@

 #define IPU_PIX_FMT_GBR24  v4l2_fourcc('G', 'B', 'R', '3')

+#define IMXDRM_MODE_FLAG_DE_HIGH   (1<<0)
+#define IMXDRM_MODE_FLAG_PIXDATA_POSEDGE   (1<<1)
+
 struct drm_crtc;
 struct drm_connector;
 struct drm_device;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 670a56a..82dce06 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -156,8 +156,15 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;

-   sig_cfg.enable_pol = 1;
-   sig_cfg.clk_pol = 1;
+   /* Such flags are not availables in the DRM modes header,
+* and we don't want to export them to userspace.
+*/
+   if (mode->private_flags & IMXDRM_MODE_FLAG_DE_HIGH)
+   sig_cfg.enable_pol = 1;
+
+   if (mode->private_flags & IMXDRM_MODE_FLAG_PIXDATA_POSEDGE)
+   sig_cfg.clk_pol = 1;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
index 24aa9be..09658ac 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -74,7 +74,35 @@ static int imx_pd_connector_get_modes(struct drm_connector 
*connector)

if (np) {
struct drm_display_mode *mode = drm_mode_create(connector->dev);
+   struct device_node *timings_np;
+   struct device_node *mode_np;
+   u32 val;
+
of_get_drm_display_mode(np, >mode, 0);
+
+   /* Such flags are not availables in the DRM modes header,
+* and we don't want to export them to userspace.
+*/
+   timings_np = of_get_child_by_name(np, "display-timings");
+   if (timings_np) {
+   /* get the display mode node */
+   mode_np = of_parse_phandle(timings_np,
+  "native-mode", 0);
+   if (!mode_np)
+   mode_np = of_get_next_child(timings_np, NULL);
+
+   /* set de-active to 1 if not set */
+   of_property_read_u32(mode_np, "de-active", );
+   if (!!val)
+   imxpd->mode.private_flags |=
+   IMXDRM_MODE_FLAG_DE_HIGH;
+
+   /* set pixelclk-active to 1 if not set */
+   of_property_read_u32(mode_np, "pixelclk-active", );
+   if (!!val)
+   imxpd->mode.private_flags |=
+   IMXDRM_MODE_FLAG_PIXDATA_POSEDGE;
+   }
drm_mode_copy(mode, >mode);
mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
drm_mode_probed_add(connector, mode);
-- 
1.7.9.5

[PATCHv4][ 1/7] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

[Denis Carikli]

That new macro is needed by the imx_drm staging driver
  for supporting the QVGA display of the eukrea-cpuimx51 board.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Stephen Warren 
Cc: Ian Campbell 
Cc: devicetree at vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: driverdev-devel at linuxdriverproject.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: Mauro Carvalho Chehab 
Cc: Laurent Pinchart 
Cc: linux-media at vger.kernel.org
Cc: Sascha Hauer 
Cc: Shawn Guo 
Cc: linux-arm-kernel at lists.infradead.org
Cc: Eric B?nard 
Signed-off-by: Denis Carikli 
Acked-by: Mauro Carvalho Chehab 
Acked-by: Laurent Pinchart 
---
ChangeLog v3->v4:
- Added Laurent Pinchart's Ack.

ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Added Mauro Carvalho Chehab's Ack.
- Added documentation.
---
 .../DocBook/media/v4l/pixfmt-packed-rgb.xml|   78 
 include/uapi/linux/videodev2.h |1 +
 2 files changed, 79 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml 
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 166c8d6..f6a3e84 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -279,6 +279,45 @@ colorspace 
V4L2_COLORSPACE_SRGB.


  
+ 
+   V4L2_PIX_FMT_RGB666
+   'RGBH'
+   
+   r5
+   r4
+   r3
+   r2
+   r1
+   r0
+   g5
+   g4
+   
+   g3
+   g2
+   g1
+   g0
+   b5
+   b4
+   b3
+   b2
+   
+   b1
+   b0
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+ 
  
V4L2_PIX_FMT_BGR24
'BGR3'
@@ -781,6 +820,45 @@ defined in error. Drivers may interpret them as in 

  
+ 
+   V4L2_PIX_FMT_RGB666
+   'RGBH'
+   
+   r5
+   r4
+   r3
+   r2
+   r1
+   r0
+   g5
+   g4
+   
+   g3
+   g2
+   g1
+   g0
+   b5
+   b4
+   b3
+   b2
+   
+   b1
+   b0
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+   
+ 
  
V4L2_PIX_FMT_BGR24
'BGR3'
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..e8ff410 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -294,6 +294,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16  RGB-5-5-5 
BE  */
 #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16  RGB-5-6-5 
BE  */
 #define V4L2_PIX_FMT_BGR666  v4l2_fourcc('B', 'G', 'R', 'H') /* 18  BGR-6-6-6  
  */
+#define V4L2_PIX_FMT_RGB666  v4l2_fourcc('R', 'G', 'B', 'H') /* 18  RGB-6-6-6  
  */
 #define V4L2_PIX_FMT_BGR24   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8  
   */
 #define V4L2_PIX_FMT_RGB24   v4l2_fourcc('R', 'G', 'B', '3') /* 24  RGB-8-8-8  
   */
 #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R', '4') /* 32  
BGR-8-8-8-8   */
-- 
1.7.9.5

[Linaro-mm-sig] [PATCH RFC] dma-buf/fs Add get_[file|dma_buf]_unless_doomed

[Thomas Hellstrom]

On 11/08/2013 06:28 PM, Daniel Vetter wrote:
> On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom  
> wrote:
>> This, however comes with two implications
>> 1) Once a DMA-buf is added, it stays alive at least until someone removes
>> the gem name of the exporting object, regardless whether there are any
>> external users or not. I think this is OK, but unnecessary.
> Imo that's actually fairly nice guarantee, since if you have dumb
> userspace that always re-does the export/import dance accross a device
> the importer can check whether it has the same object already
> somewhere.
>
> Without this guarantee we'll end up mapping the same underlying
> storage multiple times. btw this is the part where userspace can still
> trick the kernel. I have testcases for it, but thus far lacked the
> time to implement the fix. It needs a combination of nasty+dumb
> userspace though to be a real issue.
>
>> 2) If someone decides to get a new handle from fd, and the gem name has
>> already been removed, a new gem name is created for the exporting dma-buf by
>> the requested client. This is why I can't do the same. Because of the
>> relaxed RCU locking, I can't re-add a name to a TTM base object. Removing it
>> is always part of the object destruction sequence.
> Yeah, we seem to have a bit a split in how gem handles userspace
> handles and the weak references they cause and how ttm does it. ttm
> uses kref_get_unless_zero for weak references. Atm gem objects
> themselves still need the big mutex, but the only blocker is the mmap
> code (actually the has table). My plan (somewhere on my todo list) is
> to do the same trick for that weak reference from the mmap offset
> lookup structure.
>
> Anyway I just wanted to point out with my original mail that this
> problem can be solved in different ways. But I see that the weak ref
> approach with a possibly failing get call suits the current ttm design
> (and so I guess vmwgfx) a bit better.

Yes. But anyway, I'll keep that get_dma_buf_unless_doomed() in local 
code until someone else finds it useful.
The fs guys had issues with it as well.

Thanks,
Thomas



> Cheers, Daniel

[PATCH 4/4] drm/vmwgfx: Make vmwgfx dma buffers prime aware

[Thomas Hellstrom]

Should we need to share dma buffers using prime, let's make them prime
aware.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |   45 +-
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index bf49e82..d7ebfc6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -35,7 +35,7 @@
 #define VMW_RES_EVICT_ERR_COUNT 10

 struct vmw_user_dma_buffer {
-   struct ttm_base_object base;
+   struct ttm_prime_object prime;
struct vmw_dma_buffer dma;
 };

@@ -387,7 +387,7 @@ static void vmw_user_dmabuf_destroy(struct 
ttm_buffer_object *bo)
 {
struct vmw_user_dma_buffer *vmw_user_bo = vmw_user_dma_buffer(bo);

-   ttm_base_object_kfree(vmw_user_bo, base);
+   ttm_prime_object_kfree(vmw_user_bo, prime);
 }

 static void vmw_user_dmabuf_release(struct ttm_base_object **p_base)
@@ -401,7 +401,8 @@ static void vmw_user_dmabuf_release(struct ttm_base_object 
**p_base)
if (unlikely(base == NULL))
return;

-   vmw_user_bo = container_of(base, struct vmw_user_dma_buffer, base);
+   vmw_user_bo = container_of(base, struct vmw_user_dma_buffer,
+  prime.base);
bo = _user_bo->dma.base;
ttm_bo_unref();
 }
@@ -442,18 +443,19 @@ int vmw_user_dmabuf_alloc(struct vmw_private *dev_priv,
return ret;

tmp = ttm_bo_reference(_bo->dma.base);
-   ret = ttm_base_object_init(tfile,
-  _bo->base,
-  shareable,
-  ttm_buffer_type,
-  _user_dmabuf_release, NULL);
+   ret = ttm_prime_object_init(tfile,
+   size,
+   _bo->prime,
+   shareable,
+   ttm_buffer_type,
+   _user_dmabuf_release, NULL);
if (unlikely(ret != 0)) {
ttm_bo_unref();
goto out_no_base_object;
}

*p_dma_buf = _bo->dma;
-   *handle = user_bo->base.hash.key;
+   *handle = user_bo->prime.base.hash.key;

 out_no_base_object:
return ret;
@@ -475,8 +477,8 @@ int vmw_user_dmabuf_verify_access(struct ttm_buffer_object 
*bo,
return -EPERM;

vmw_user_bo = vmw_user_dma_buffer(bo);
-   return (vmw_user_bo->base.tfile == tfile ||
-   vmw_user_bo->base.shareable) ? 0 : -EPERM;
+   return (vmw_user_bo->prime.base.tfile == tfile ||
+   vmw_user_bo->prime.base.shareable) ? 0 : -EPERM;
 }

 int vmw_dmabuf_alloc_ioctl(struct drm_device *dev, void *data,
@@ -538,14 +540,15 @@ int vmw_user_dmabuf_lookup(struct ttm_object_file *tfile,
return -ESRCH;
}

-   if (unlikely(base->object_type != ttm_buffer_type)) {
+   if (unlikely(ttm_base_object_type(base) != ttm_buffer_type)) {
ttm_base_object_unref();
printk(KERN_ERR "Invalid buffer object handle 0x%08lx.\n",
   (unsigned long)handle);
return -EINVAL;
}

-   vmw_user_bo = container_of(base, struct vmw_user_dma_buffer, base);
+   vmw_user_bo = container_of(base, struct vmw_user_dma_buffer,
+  prime.base);
(void)ttm_bo_reference(_user_bo->dma.base);
ttm_base_object_unref();
*out = _user_bo->dma;
@@ -562,7 +565,8 @@ int vmw_user_dmabuf_reference(struct ttm_object_file *tfile,
return -EINVAL;

user_bo = container_of(dma_buf, struct vmw_user_dma_buffer, dma);
-   return ttm_ref_object_add(tfile, _bo->base, TTM_REF_USAGE, NULL);
+   return ttm_ref_object_add(tfile, _bo->prime.base,
+ TTM_REF_USAGE, NULL);
 }

 /*
@@ -807,15 +811,16 @@ int vmw_dumb_create(struct drm_file *file_priv,
goto out_no_dmabuf;

tmp = ttm_bo_reference(_user_bo->dma.base);
-   ret = ttm_base_object_init(vmw_fpriv(file_priv)->tfile,
-  _user_bo->base,
-  false,
-  ttm_buffer_type,
-  _user_dmabuf_release, NULL);
+   ret = ttm_prime_object_init(vmw_fpriv(file_priv)->tfile,
+   args->size,
+   _user_bo->prime,
+   false,
+   ttm_buffer_type,
+   _user_dmabuf_release, NULL);
if (unlikely(ret != 0))
goto out_no_base_object;

-   args->handle = vmw_user_bo->base.hash.key;
+   args->handle = vmw_user_bo->prime.base.hash.key;

 

[PATCH 3/4] drm/vmwgfx: Make surfaces prime-aware

[Thomas Hellstrom]

Add prime exporting and imporing operations to surfaces

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c  |   30 --
 2 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 941e5ff..bf49e82 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -297,7 +297,7 @@ int vmw_user_resource_lookup_handle(struct vmw_private 
*dev_priv,
if (unlikely(base == NULL))
return -EINVAL;

-   if (unlikely(base->object_type != converter->object_type))
+   if (unlikely(ttm_base_object_type(base) != converter->object_type))
goto out_bad_resource;

res = converter->base_obj_to_res(base);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index 5828143..7de2ea8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -38,7 +38,7 @@
  * @size:   TTM accounting size for the surface.
  */
 struct vmw_user_surface {
-   struct ttm_base_object base;
+   struct ttm_prime_object prime;
struct vmw_surface srf;
uint32_t size;
uint32_t backup_handle;
@@ -580,7 +580,8 @@ static int vmw_surface_init(struct vmw_private *dev_priv,
 static struct vmw_resource *
 vmw_user_surface_base_to_res(struct ttm_base_object *base)
 {
-   return &(container_of(base, struct vmw_user_surface, base)->srf.res);
+   return &(container_of(base, struct vmw_user_surface,
+ prime.base)->srf.res);
 }

 /**
@@ -599,7 +600,7 @@ static void vmw_user_surface_free(struct vmw_resource *res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
-   ttm_base_object_kfree(user_srf, base);
+   ttm_prime_object_kfree(user_srf, prime);
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 }

@@ -616,7 +617,7 @@ static void vmw_user_surface_base_release(struct 
ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
struct vmw_user_surface *user_srf =
-   container_of(base, struct vmw_user_surface, base);
+   container_of(base, struct vmw_user_surface, prime.base);
struct vmw_resource *res = _srf->srf.res;

*p_base = NULL;
@@ -790,8 +791,8 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,
}
srf->snooper.crtc = NULL;

-   user_srf->base.shareable = false;
-   user_srf->base.tfile = NULL;
+   user_srf->prime.base.shareable = false;
+   user_srf->prime.base.tfile = NULL;

/**
 * From this point, the generic resource management functions
@@ -803,9 +804,9 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,
goto out_unlock;

tmp = vmw_resource_reference(>res);
-   ret = ttm_base_object_init(tfile, _srf->base,
-  req->shareable, VMW_RES_SURFACE,
-  _user_surface_base_release, NULL);
+   ret = ttm_prime_object_init(tfile, res->backup_size, _srf->prime,
+   req->shareable, VMW_RES_SURFACE,
+   _user_surface_base_release, NULL);

if (unlikely(ret != 0)) {
vmw_resource_unreference();
@@ -813,7 +814,7 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,
goto out_unlock;
}

-   rep->sid = user_srf->base.hash.key;
+   rep->sid = user_srf->prime.base.hash.key;
vmw_resource_unreference();

ttm_read_unlock(>lock);
@@ -823,7 +824,7 @@ out_no_copy:
 out_no_offsets:
kfree(srf->sizes);
 out_no_sizes:
-   ttm_base_object_kfree(user_srf, base);
+   ttm_prime_object_kfree(user_srf, prime);
 out_no_user_srf:
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 out_unlock:
@@ -859,13 +860,14 @@ int vmw_surface_reference_ioctl(struct drm_device *dev, 
void *data,
return -EINVAL;
}

-   if (unlikely(base->object_type != VMW_RES_SURFACE))
+   if (unlikely(ttm_base_object_type(base) != VMW_RES_SURFACE))
goto out_bad_resource;

-   user_srf = container_of(base, struct vmw_user_surface, base);
+   user_srf = container_of(base, struct vmw_user_surface, prime.base);
srf = _srf->srf;

-   ret = ttm_ref_object_add(tfile, _srf->base, TTM_REF_USAGE, NULL);
+   ret = ttm_ref_object_add(tfile, _srf->prime.base,
+TTM_REF_USAGE, NULL);
if (unlikely(ret != 0)) {
DRM_ERROR("Could not add a reference to a surface.\n");
goto out_no_reference;
-- 
1.7.10.4

[PATCH 2/4] drm/vmwgfx: Hook up the prime ioctls

[Thomas Hellstrom]

Also provide a completely dumb dma-buf ops implementation.
Once we have other virtual dma-buf aware devices, we need to provide
something better.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/Makefile   |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |7 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |   14 
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c |  137 +
 4 files changed, 157 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 2cc6cd9..9f8b690 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -6,6 +6,6 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o 
vmwgfx_drv.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_marker.o vmwgfx_gmrid_manager.o \
vmwgfx_fence.o vmwgfx_dmabuf.o vmwgfx_scrn.o vmwgfx_context.o \
-   vmwgfx_surface.o
+   vmwgfx_surface.o vmwgfx_prime.o

 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index a278581..4669459 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -677,7 +677,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
}

dev_priv->tdev = ttm_object_device_init
-   (dev_priv->mem_global_ref.object, 12);
+   (dev_priv->mem_global_ref.object, 12, _prime_dmabuf_ops);

if (unlikely(dev_priv->tdev == NULL)) {
DRM_ERROR("Unable to initialize TTM object management.\n");
@@ -1203,7 +1203,7 @@ static const struct file_operations vmwgfx_driver_fops = {

 static struct drm_driver driver = {
.driver_features = DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED |
-   DRIVER_MODESET,
+   DRIVER_MODESET | DRIVER_PRIME,
.load = vmw_driver_load,
.unload = vmw_driver_unload,
.lastclose = vmw_lastclose,
@@ -1228,6 +1228,9 @@ static struct drm_driver driver = {
.dumb_map_offset = vmw_dumb_map_offset,
.dumb_destroy = vmw_dumb_destroy,

+   .prime_fd_to_handle = vmw_prime_fd_to_handle,
+   .prime_handle_to_fd = vmw_prime_handle_to_fd,
+
.fops = _driver_fops,
.name = VMWGFX_DRIVER_NAME,
.desc = VMWGFX_DRIVER_DESC,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index e401d5d..db85985 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -819,6 +819,20 @@ int vmw_overlay_num_free_overlays(struct vmw_private 
*dev_priv);
 extern const struct ttm_mem_type_manager_func vmw_gmrid_manager_func;

 /**
+ * Prime - vmwgfx_prime.c
+ */
+
+extern const struct dma_buf_ops vmw_prime_dmabuf_ops;
+extern int vmw_prime_fd_to_handle(struct drm_device *dev,
+ struct drm_file *file_priv,
+ int fd, u32 *handle);
+extern int vmw_prime_handle_to_fd(struct drm_device *dev,
+ struct drm_file *file_priv,
+ uint32_t handle, uint32_t flags,
+ int *prime_fd);
+
+
+/**
  * Inline helper functions
  */

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
new file mode 100644
index 000..647caa6
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
@@ -0,0 +1,137 @@
+/**
+ *
+ * Copyright ? 2013 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/

[PATCH 1/4] drm/ttm: Add a minimal prime implementation for ttm base objects

[Thomas Hellstrom]

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/ttm/ttm_object.c |  254 +-
 include/drm/ttm/ttm_object.h |   61 -
 2 files changed, 307 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index a868176..6fe7b92 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -1,6 +1,6 @@
 /**
  *
- * Copyright (c) 2009 VMware, Inc., Palo Alto, CA., USA
+ * Copyright (c) 2009-2013 VMware, Inc., Palo Alto, CA., USA
  * All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -26,6 +26,12 @@
  **/
 /*
  * Authors: Thomas Hellstrom 
+ *
+ * While no substantial code is shared, the prime code is inspired by
+ * drm_prime.c, with
+ * Authors:
+ *  Dave Airlie 
+ *  Rob Clark 
  */
 /** @file ttm_ref_object.c
  *
@@ -34,6 +40,7 @@
  * and release on file close.
  */

+
 /**
  * struct ttm_object_file
  *
@@ -84,6 +91,9 @@ struct ttm_object_device {
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
+   struct dma_buf_ops ops;
+   void (*dmabuf_release)(struct dma_buf *dma_buf);
+   size_t dma_buf_size;
 };

 /**
@@ -116,6 +126,8 @@ struct ttm_ref_object {
struct ttm_object_file *tfile;
 };

+static void ttm_prime_dmabuf_release(struct dma_buf *dma_buf);
+
 static inline struct ttm_object_file *
 ttm_object_file_ref(struct ttm_object_file *tfile)
 {
@@ -416,9 +428,10 @@ out_err:
 }
 EXPORT_SYMBOL(ttm_object_file_init);

-struct ttm_object_device *ttm_object_device_init(struct ttm_mem_global
-*mem_glob,
-unsigned int hash_order)
+struct ttm_object_device *
+ttm_object_device_init(struct ttm_mem_global *mem_glob,
+  unsigned int hash_order,
+  const struct dma_buf_ops *ops)
 {
struct ttm_object_device *tdev = kmalloc(sizeof(*tdev), GFP_KERNEL);
int ret;
@@ -430,10 +443,17 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
spin_lock_init(>object_lock);
atomic_set(>object_count, 0);
ret = drm_ht_create(>object_hash, hash_order);
+   if (ret != 0)
+   goto out_no_object_hash;

-   if (likely(ret == 0))
-   return tdev;
+   tdev->ops = *ops;
+   tdev->dmabuf_release = tdev->ops.release;
+   tdev->ops.release = ttm_prime_dmabuf_release;
+   tdev->dma_buf_size = ttm_round_pot(sizeof(struct dma_buf)) +
+   ttm_round_pot(sizeof(struct file));
+   return tdev;

+out_no_object_hash:
kfree(tdev);
return NULL;
 }
@@ -452,3 +472,225 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)
kfree(tdev);
 }
 EXPORT_SYMBOL(ttm_object_device_release);
+
+/**
+ * get_dma_buf_unless_doomed - get a dma_buf reference if possible.
+ *
+ * @dma_buf: Non-refcounted pointer to a struct dma-buf.
+ *
+ * Obtain a file reference from a lookup structure that doesn't refcount
+ * the file, but synchronizes with its release method to make sure it has
+ * not been freed yet. See for example kref_get_unless_zero documentation.
+ * Returns true if refcounting succeeds, false otherwise.
+ *
+ * Nobody really wants this as a public API yet, so let it mature here
+ * for some time...
+ */
+static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
+{
+   return atomic_long_inc_not_zero(>file->f_count) != 0L;
+}
+
+/**
+ * ttm_prime_refcount_release - refcount release method for a prime object.
+ *
+ * @p_base: Pointer to ttm_base_object pointer.
+ *
+ * This is a wrapper that calls the refcount_release founction of the
+ * underlying object. At the same time it cleans up the prime object.
+ * This function is called when all references to the base object we
+ * derive from are gone.
+ */
+static void ttm_prime_refcount_release(struct ttm_base_object **p_base)
+{
+   struct ttm_base_object *base = *p_base;
+   struct ttm_prime_object *prime;
+
+   *p_base = NULL;
+   prime = container_of(base, struct ttm_prime_object, base);
+   BUG_ON(prime->dma_buf != NULL);
+   mutex_destroy(>mutex);
+   if (prime->refcount_release)
+   prime->refcount_release();
+}
+
+/**
+ * ttm_prime_dmabuf_release - Release method for the dma-bufs we export
+ *
+ * @dma_buf:
+ *
+ * This function first calls the dma_buf release method the driver
+ * provides. Then it cleans up our dma_buf pointer used for lookup,
+ * and finally releases the reference the dma_buf has on our base
+ * object.
+ */
+static void ttm_prime_dmabuf_release(struct dma_buf *dma_buf)
+{
+   struct 

[PATCH 0/4] vmwgfx prime implementation

[Thomas Hellstrom]

Adds a prime implementation to the vmwgfx driver mostly for inter-process
sharing of buffers.
For now, the dma_bufs we export can't be consumed by another device and also
we don't import any dma_bufs other than the ones we've created ourselves.
This is because there are no other virtual devices that import / export
dma_bufs yet.
Basically this also means we don't have to implement the dma_buf ops

[RFC PATCH] drm/ttm: get rid of ttm bo refcounting

[Thomas Hellstrom]

On 11/13/2013 12:52 AM, Maarten Lankhorst wrote:
> op 12-11-13 22:49, Thomas Hellstrom schreef:
>> On 11/12/2013 07:26 PM, Maarten Lankhorst wrote:
>>> Most drivers have refcounting done in gem, so lets get rid of another 
>>> refcounting layer. ;)
>>> It has been confusing to keep track of 2 refcounts, so lets just let the 
>>> driver worry about
>>> refcounting, and keep it hidden from ttm entirely. The core doesn't need to 
>>> know about the
>>> refcounting anywhere.
>>>
>>> Vmwgfx has 1 bo that doesn't use vmw_dma_buffer, but instead ttm_bo_create. 
>>> Converting this call
>>> makes every bo use vmw_dma_buffer as base, which means I can simply add 
>>> refcount to vmw_dma_buffer.
>>>
>>> Mostly meant as a RFC, so I only took effort into converting vmwgfx, 
>>> radeon, nouveau. Thoughts?
>> Hmm. I don't really see the purpose of this?
> With the patches that embed a GEM object I think it's stupid to keep another 
> refcount. When I was playing with
> TTM in nouveau it was very unclear for me when an object is truly dead due to 
> the various not-dead stages.
> I want to get rid of this confusion and either have a ttm object in a alive 
> state, with the gem object still alive too,
> or in a dying state when ttm_bo_release is called and delayed destroy is used

Vmwgfx embed a ttm base object in the exact same way, and it's working 
perfectly. If there is confusion about
whether the user-interface part is alive or not, that's might to being 
sloppy when passing object pointers around.
Better go fix that up by being strict with pointer types.

The fact is with this code you're going to duplicate a large amount of 
mmap code, and the vmwgfx driver will be uglified to save an IMO 
completely irrelevant amount of memory and cpu-resources.

I believe what you want to do with the gem drivers can be accomplished 
anyway, if needed, by simply not using the ttm bo refcount, but since 
IMO ttm buffer objects are intended to be used standalone and are used 
standalone, this is a NAK for vmwgfx and TTM.

Thanks,
/Thomas

[PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

[Philipp Zabel]

Hi Eric,

Am Mittwoch, den 13.11.2013, 08:53 +0100 schrieb Eric B?nard:
> Hi Russell,
> 
> Le Tue, 12 Nov 2013 17:04:55 +,
> Russell King - ARM Linux  a ?crit :
> > On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > index fc2adb6..586c12f 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct 
> > > videomode *vm,
> > >   dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
> > >   if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
> > >   dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> > > + if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> > > + dmode->flags |= DRM_MODE_FLAG_DE_LOW;
> > > + if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> > > + dmode->flags |= DRM_MODE_FLAG_DE_HIGH;
> > > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> > > + dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE;
> > > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> > > + dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE;
> > > +
> > 
> > I'm still not convinced that these should be exposed in *any* way to
> > userspace - I'm with Ville Syrj?l? on this point.
> > 
> > Yes, you've moved their definition out of a uapi header file, but
> > they're still leaking out of kernel space via calls (and with Xorg,
> > they'll leak into the DisplayMode structures within the X server.)
> > 
> > Now, here's the thing... The polarity of the display enable signal.
> > That's a property of the connected device right?  It doesn't change
> > with respect to the displayed mode unlike the hsync/vsync signals.
> > If that's true, it should not be here.
> > 
> > Same goes for the pixel clock edge.  If it's a property of the
> > connected device and doesn't have a dependence on the displayed
> > mode, then it should not be in the DRM mode structure.
> 
> What would be the right way to configure these settings without
> exposing them to userspace ?

I think as a property of the connected device, this should be obtained
from the device tree node of the panel. In the v4l2 style device tree
model this could also be made a property of the link (endpoint).

> As explained in my answer to Fabio, these settings are currently
> hardcoded into ipuv3-crtc and we need to configure them to support more
> TFT panels using the IPUV3 Parallel Display Interface.

regards
Philipp

[Acer Aspire V5-573G] Black screen on boot due to low brightness setting

[Mario Kleinsasser]

Dear mailing list!

In the last three weeks I've narrowed down the bug described in the
subject through Ubuntu launchpad. My new Laptop (Acer Aspire V5-573G)
with new Haswell CPU shows a black screen on reboot because the
brightness is on zero level. I verified this behaviour with the latest
mainline kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.12-trusty/

I have done the bisect process and tracked the bug down to the following commit.

For explanation:
good commit means: The laptop starts with display brightness on full
power, but low(er) resolution and the Fn+ keys are not working
bad commit means: The laptop starts with black display (0 brightness),
Fn+ keys are working and you can level up the brightness trough the
Fn+ keys. The resolution is the native LCD hardware display resolution

Bisect output:

70b12bb415463c1bd146b67c5fbf6784fd046ad9 is the first bad commit
commit 70b12bb415463c1bd146b67c5fbf6784fd046ad9
Author: Paulo Zanoni 
Date: Tue Nov 20 13:32:30 2012 -0200

drm/i915: promote Haswell to full support

Since it should be working a little bit better now.

Signed-off-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter 

:04 04 f93a7761de2157a8be61f20ca9a5499264bb5c55
1fed098470278830f06b0bca1706f61ba231d38d M drivers

For the full bug report and the additional hardware information please
see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1239183

I've also searched the LKML and maybe this bug could be in conjunction
with http://marc.info/?t=13783778615=1=2

I'am not described to any of the mailing lists. Please CC me if it is
possible! If you need any futher information please let me know!


Mario Kleinsasser


Additional information:
lsb_release -rd
Description:Ubuntu 13.10
Release:13.10

/usr/src/linux-headers-3.12.0-031200/scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux Fenrir 3.12.0-031200-generic #201311071835 SMP Thu Nov 7
23:36:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Gnu C  4.8
Gnu make   3.81
binutils   2.23.52.20130913
util-linux 2.20.1
mount  support
module-init-tools  9
e2fsprogs  1.42.8
pcmciautils018
PPP2.4.5
Linux C Library2.17
Dynamic linker (ldd)   2.17
Procps 3.3.3
Net-tools  1.60
Kbd1.15.5
Sh-utils   8.20
wireless-tools 30
Modules Loaded x86_pkg_temp_thermal parport_pc ppdev coretemp
kvm_intel kvm rfcomm bnep crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper
ablk_helper cryptd joydev snd_hda_codec_hdmi snd_hda_codec_realtek
acer_wmi sparse_keymap snd_hda_intel uvcvideo snd_hda_codec
videobuf2_vmalloc snd_hwdep videobuf2_memops snd_pcm videobuf2_core
videodev snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmidi
arc4 snd_seq ath9k snd_seq_device ath3k ath9k_common ath9k_hw btusb
ath snd_timer mac80211 bluetooth microcode cfg80211 snd rtsx_pci_ms
psmouse soundcore memstick mei_me mei serio_raw lpc_ich mac_hid lp
parport hid_generic usbhid hid rtsx_pci_sdmmc nouveau i915 mxm_wmi
ahci ttm r8169 libahci i2c_algo_bit mii drm_kms_helper rtsx_pci drm
wmi video

cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 69
model name  : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
stepping: 1
microcode   : 0x15
cpu MHz : 1600.027
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1
sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand
lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms
invpcid
bogomips: 4588.93
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 69
model name  : Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
stepping: 1
microcode   : 0x15
cpu MHz : 1688.613
cache size  : 3072 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : 

[PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

[Russell King - ARM Linux]

On Wed, Nov 13, 2013 at 08:53:18AM +0100, Eric B?nard wrote:
> Hi Russell,
> 
> Le Tue, 12 Nov 2013 17:04:55 +,
> Russell King - ARM Linux  a ?crit :
> > On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > index fc2adb6..586c12f 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct 
> > > videomode *vm,
> > >   dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
> > >   if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
> > >   dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> > > + if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> > > + dmode->flags |= DRM_MODE_FLAG_DE_LOW;
> > > + if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> > > + dmode->flags |= DRM_MODE_FLAG_DE_HIGH;
> > > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> > > + dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE;
> > > + if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> > > + dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE;
> > > +
> > 
> > I'm still not convinced that these should be exposed in *any* way to
> > userspace - I'm with Ville Syrj?l? on this point.
> > 
> > Yes, you've moved their definition out of a uapi header file, but
> > they're still leaking out of kernel space via calls (and with Xorg,
> > they'll leak into the DisplayMode structures within the X server.)
> > 
> > Now, here's the thing... The polarity of the display enable signal.
> > That's a property of the connected device right?  It doesn't change
> > with respect to the displayed mode unlike the hsync/vsync signals.
> > If that's true, it should not be here.
> > 
> > Same goes for the pixel clock edge.  If it's a property of the
> > connected device and doesn't have a dependence on the displayed
> > mode, then it should not be in the DRM mode structure.
> 
> What would be the right way to configure these settings without
> exposing them to userspace ?
> 
> As explained in my answer to Fabio, these settings are currently
> hardcoded into ipuv3-crtc and we need to configure them to support more
> TFT panels using the IPUV3 Parallel Display Interface.

First, realise that what you're doing is configuring components within
the IMX driver "suite" so what you need to do is communicate your
requirements _only_ from parallel-display.c to ipuv3-crtc.c.

There's already infrastructure in imx-drm for the display bridges to
communicate various information to the CRTC layer - there's already the
encoder type, and the "pins" for hsync/vsync being communicated via
imx_drm_panel_format*().  This is really no different IMHO.

[Bug 71540] Radeon HD 7420G artefacts

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71540

--- Comment #5 from Vova  ---
Created attachment 89128
  --> https://bugs.freedesktop.org/attachment.cgi?id=89128=edit
Xorg 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/20131113/ef4c43a9/attachment.html>

[Bug 71540] Radeon HD 7420G artefacts

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71540

--- Comment #4 from Vova  ---
Created attachment 89127
  --> https://bugs.freedesktop.org/attachment.cgi?id=89127=edit
glxinfo

-- 
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/20131113/a61eb326/attachment.html>

[Bug 71540] Radeon HD 7420G artefacts

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71540

--- Comment #3 from Vova  ---
Created attachment 89126
  --> https://bugs.freedesktop.org/attachment.cgi?id=89126=edit
dmesg

-- 
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/20131113/2b41e86f/attachment.html>

[PATCHv3 1/8] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

[Eric Bénard]

Hi Russell,

Le Tue, 12 Nov 2013 17:04:55 +,
Russell King - ARM Linux  a ?crit :
> On Tue, Nov 12, 2013 at 05:49:18PM +0100, Denis Carikli wrote:
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index fc2adb6..586c12f 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -537,6 +537,15 @@ int drm_display_mode_from_videomode(const struct 
> > videomode *vm,
> > dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
> > if (vm->flags & DISPLAY_FLAGS_DOUBLECLK)
> > dmode->flags |= DRM_MODE_FLAG_DBLCLK;
> > +   if (vm->flags & DISPLAY_FLAGS_DE_LOW)
> > +   dmode->flags |= DRM_MODE_FLAG_DE_LOW;
> > +   if (vm->flags & DISPLAY_FLAGS_DE_HIGH)
> > +   dmode->flags |= DRM_MODE_FLAG_DE_HIGH;
> > +   if (vm->flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
> > +   dmode->flags |= DRM_MODE_FLAG_PIXDATA_POSEDGE;
> > +   if (vm->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> > +   dmode->flags |= DRM_MODE_FLAG_PIXDATA_NEGEDGE;
> > +
> 
> I'm still not convinced that these should be exposed in *any* way to
> userspace - I'm with Ville Syrj?l? on this point.
> 
> Yes, you've moved their definition out of a uapi header file, but
> they're still leaking out of kernel space via calls (and with Xorg,
> they'll leak into the DisplayMode structures within the X server.)
> 
> Now, here's the thing... The polarity of the display enable signal.
> That's a property of the connected device right?  It doesn't change
> with respect to the displayed mode unlike the hsync/vsync signals.
> If that's true, it should not be here.
> 
> Same goes for the pixel clock edge.  If it's a property of the
> connected device and doesn't have a dependence on the displayed
> mode, then it should not be in the DRM mode structure.

What would be the right way to configure these settings without
exposing them to userspace ?

As explained in my answer to Fabio, these settings are currently
hardcoded into ipuv3-crtc and we need to configure them to support more
TFT panels using the IPUV3 Parallel Display Interface.

Thanks
Eric

[PATCHv3 3/8] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.

[Eric Bénard]

Hi Fabio,

Le Wed, 13 Nov 2013 01:52:25 -0200,
Fabio Estevam  a ?crit :
> On Tue, Nov 12, 2013 at 2:49 PM, Denis Carikli  wrote:
> > +   if (mode->flags & DRM_MODE_FLAG_DE_HIGH)
> > +   sig_cfg.enable_pol = 1;
> > +   if (mode->flags & DRM_MODE_FLAG_PIXDATA_POSEDGE)
> > +   sig_cfg.clk_pol = 1;
> >
> > -   sig_cfg.enable_pol = 1;
> > -   sig_cfg.clk_pol = 1;
> 
> 
> What are the sig_cfg.enable_pol and sig_cfg.clk_pol values you need
> for your display to operate correctly?

in ipuv3-crtc, line 159 :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm/ipuv3-crtc.c#n159

polarity of the enable signal and the pixel clock are hard coded to 1.

These settings are then used in ipu-di.c to configurer the IPU display
interface :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm/ipu-v3/ipu-di.c#n631
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm/ipu-v3/ipu-di.c#n642

This is a problem as the polarity of these signals can vary from one
TFT panel to an other. In our case, we need and active low enable and a
negative edge clock but currently there is no way to configure these
settings in ipuv3-crtc as they are hardcoded to 1 : that's what Denis
is trying to fix.

Eric

[Bug 63101] Hard lockup whel launching games like TF2 on kernels 3.11.5 and 3.12 rc4 and above if radeon.dpm=1 is used

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=63101

--- Comment #19 from Kertesz Laszlo  ---
Enabling any of enable_mg_clock_gating, enable_gfx_dynamic_mgpg,
override_dynamic_mgpg and uvd_dpm will cause the GPU softreset, TF2 to crash
and most times an unusable desktop, sometimes with garbled image (composed of
the real desktop tiles with some of the TF2 tiles. Exactly the behavior
described with the unmodified 3.12.0-next-2013 kernel.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=69689

--- Comment #9 from Johannes Jordan  ---
I am sorry my testcase uses Qt, but it would be much more time consuming for me
to learn/rewrite everything without Qt.

This is the qmake file:
# cat fbotest.pro 
QT   += core gui opengl
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
TARGET = fbotest
TEMPLATE = app
SOURCES += fbotest.cpp
HEADERS += fbotest.h

Then run qmake, make, ./fbotest

The testcase draws a rectangle and some text into a FBO, then blits it onto
another FBO due to multisampling, finally draws the texture on screen. This is
common practice.

Thank you for taking your time to try the testcase!

-- 
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/20131113/367f38a3/attachment.html>

[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=69689

--- Comment #8 from Johannes Jordan  ---
Created attachment 89121
  --> https://bugs.freedesktop.org/attachment.cgi?id=89121=edit
Testcase source file

-- 
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/20131113/cfce2e31/attachment.html>

[Bug 69689] FBO with GL_RGBA16F texture format silent drawing corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=69689

--- Comment #7 from Johannes Jordan  ---
Created attachment 89120
  --> https://bugs.freedesktop.org/attachment.cgi?id=89120=edit
Testcase header file

-- 
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/20131113/2fb61378/attachment.html>

[Bug 71285] Xonotic LLVM ERROR

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71285

--- Comment #1 from Michel D?nzer  ---
Which version of LLVM are you using? If it's 3.3, does a 3.4 snapshot work
better?

-- 
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/20131113/9688d914/attachment.html>

[Bug 71285] Xonotic LLVM ERROR

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71285

Michel D?nzer  changed:

   What|Removed |Added

  Attachment #88735|text/plain  |application/zip
  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/20131113/efacdb72/attachment.html>

[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71516

--- Comment #6 from Michel D?nzer  ---
libGL is directly loading swrast instead of r300 for some reason. Make sure the
environment variable LIBGL_ALWAYS_SOFTWARE is not set.

-- 
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/20131113/42c13a4d/attachment.html>

[Bug 71540] Radeon HD 7420G artefacts

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71540

--- Comment #2 from Michel D?nzer  ---
Please attach the corresponding /var/log/Xorg.0.log and the output of dmesg and
glxinfo.

-- 
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/20131113/6b079251/attachment-0001.html>

[PATCHv3 2/8] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

[Laurent Pinchart]

Hi Denis,

(Dropping the DT reviewers from the CC list to avoid spamming them)

Thank you for the patch.

On Tuesday 12 November 2013 17:49:19 Denis Carikli wrote:
> That new macro is needed by the imx_drm staging driver
>   for supporting the QVGA display of the eukrea-cpuimx51 board.
> 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Stephen Warren 
> Cc: Ian Campbell 
> Cc: devicetree at vger.kernel.org
> Cc: Greg Kroah-Hartman 
> Cc: driverdev-devel at linuxdriverproject.org
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Mauro Carvalho Chehab 
> Cc: Laurent Pinchart 
> Cc: linux-media at vger.kernel.org
> Cc: Sascha Hauer 
> Cc: Shawn Guo 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: Eric B?nard 
> Signed-off-by: Denis Carikli 
> Acked-by: Mauro Carvalho Chehab 

Acked-by: Laurent Pinchart 

> ---
> ChangeLog v2->v3:
> - Added some interested people in the Cc list.
> - Added Mauro Carvalho Chehab's Ack.
> - Added documentation.
> ---
>  .../DocBook/media/v4l/pixfmt-packed-rgb.xml|   78
>  include/uapi/linux/videodev2.h |  
>  1 +
>  2 files changed, 79 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index
> 166c8d6..f6a3e84 100644
> --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
> @@ -279,6 +279,45 @@ colorspace
> V4L2_COLORSPACE_SRGB. 
>   
> 
> +   
> + V4L2_PIX_FMT_RGB666
> + 'RGBH'
> + 
> + r5
> + r4
> + r3
> + r2
> + r1
> + r0
> + g5
> + g4
> + 
> + g3
> + g2
> + g1
> + g0
> + b5
> + b4
> + b3
> + b2
> + 
> + b1
> + b0
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +   
> 
>   V4L2_PIX_FMT_BGR24
>   'BGR3'
> @@ -781,6 +820,45 @@ defined in error. Drivers may interpret them as in
> 
>   
> 
> +   
> + V4L2_PIX_FMT_RGB666
> + 'RGBH'
> + 
> + r5
> + r4
> + r3
> + r2
> + r1
> + r0
> + g5
> + g4
> + 
> + g3
> + g2
> + g1
> + g0
> + b5
> + b4
> + b3
> + b2
> + 
> + b1
> + b0
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> + 
> +   
> 
>   V4L2_PIX_FMT_BGR24
>   'BGR3'
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 437f1b0..e8ff410 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -294,6 +294,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 
> RGB-5-5-5 BE  */ #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B',
> 'R') /* 16  RGB-5-6-5 BE  */ #define V4L2_PIX_FMT_BGR666  v4l2_fourcc('B',
> 'G', 'R', 'H') /* 18  BGR-6-6-6 */ +#define V4L2_PIX_FMT_RGB666 
> v4l2_fourcc('R', 'G', 'B', 'H') /* 18  RGB-6-6-6*/ #define
> V4L2_PIX_FMT_BGR24   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8
> */ #define V4L2_PIX_FMT_RGB24   v4l2_fourcc('R', 'G', 'B', '3') /* 24 
> RGB-8-8-8 */ #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B', 'G', 'R',
> '4') /* 32  BGR-8-8-8-8   */
-- 
Regards,

Laurent Pinchart

[Bug 71516] RV350 Radeon 9550 - no Unity 3D hardware support in Ubuntu 13.10, extremely slow

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71516

--- Comment #5 from Elven Decker  ---
Added dri configuration file, but realized that still left me with software
acceleration.  Still puzzled.

-- 
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/20131113/0342c952/attachment.html>

[PATCHv3 3/8] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.

[Fabio Estevam]

Hi Denis,

On Tue, Nov 12, 2013 at 2:49 PM, Denis Carikli  wrote:
> This change is needed for making the eukrea-cpuimx51
>   QVGA display work.
>
> Greg Kroah-Hartman 
> Cc: driverdev-devel at linuxdriverproject.org
> Cc: Philipp Zabel 
> Cc: Sascha Hauer 
> Cc: Shawn Guo 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: David Airlie 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Eric B?nard 
> Signed-off-by: Denis Carikli 
> ---
>  drivers/staging/imx-drm/ipuv3-crtc.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> ChangeLog v2->v3:
> - Added some interested people in the Cc list.
> - Ajusted the flags to match the changes in "drm: Add the lacking
>   DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*"
> ---
> diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
> b/drivers/staging/imx-drm/ipuv3-crtc.c
> index 670a56a..917818c 100644
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -155,9 +155,11 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
> sig_cfg.Hsync_pol = 1;
> if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> sig_cfg.Vsync_pol = 1;
> +   if (mode->flags & DRM_MODE_FLAG_DE_HIGH)
> +   sig_cfg.enable_pol = 1;
> +   if (mode->flags & DRM_MODE_FLAG_PIXDATA_POSEDGE)
> +   sig_cfg.clk_pol = 1;
>
> -   sig_cfg.enable_pol = 1;
> -   sig_cfg.clk_pol = 1;


What are the sig_cfg.enable_pol and sig_cfg.clk_pol values you need
for your display to operate correctly?

[Bug 71540] Radeon HD 7420G artefacts

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=71540

--- Comment #1 from Vova  ---
http://rghost.ru/50134158.view Textures blinks, some lines at scene. Like that

-- 
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/20131113/cb004728/attachment.html>

[RFC PATCH] drm/ttm: get rid of ttm bo refcounting

[Maarten Lankhorst]

op 12-11-13 22:49, Thomas Hellstrom schreef:
> On 11/12/2013 07:26 PM, Maarten Lankhorst wrote:
>> Most drivers have refcounting done in gem, so lets get rid of another 
>> refcounting layer. ;)
>> It has been confusing to keep track of 2 refcounts, so lets just let the 
>> driver worry about
>> refcounting, and keep it hidden from ttm entirely. The core doesn't need to 
>> know about the
>> refcounting anywhere.
>>
>> Vmwgfx has 1 bo that doesn't use vmw_dma_buffer, but instead ttm_bo_create. 
>> Converting this call
>> makes every bo use vmw_dma_buffer as base, which means I can simply add 
>> refcount to vmw_dma_buffer.
>>
>> Mostly meant as a RFC, so I only took effort into converting vmwgfx, radeon, 
>> nouveau. Thoughts?
>
> Hmm. I don't really see the purpose of this?
With the patches that embed a GEM object I think it's stupid to keep another 
refcount. When I was playing with
TTM in nouveau it was very unclear for me when an object is truly dead due to 
the various not-dead stages.
I want to get rid of this confusion and either have a ttm object in a alive 
state, with the gem object still alive too,
or in a dying state when ttm_bo_release is called and delayed destroy is used.

> First the ttm bo reference is used by the vm system, so you need to duplicate 
> a lot of vm stuff across all drivers, which is
> bad because if something needs to change here, we need to change it in all 
> drivers. Seems you've forgotten qxl, cirrus,
> mgag200 and ast mmap() here?
"Mostly meant as a RFC, so I only took effort into converting vmwgfx, radeon, 
nouveau."

I inlined ttm_bo_mmap because extending the callbacks with an ops structure 
parameter was more
complicated. Now that everything is done with the drm_vma_offset helpers I 
don't expect big changes here.

The fault handler is still in core ttm, and radeon was already wrapping it 
poorly. Implementing it in the driver means core ttm
does not need to worry about refcounting any more, any refcounting is now 
entirely up to the drivers.

> Second, the vmwgfx driver relies so much on ttm refcounting that you needed 
> to re-add it for this driver, and actually will rely even more
> on bare ttm objects in our upcoming hardware revision where they are used as 
> page table bos.
Where have I heard this before? :P I don't believe page table bo's would need 
refcounting anyway, so just call ttm_bo_release.
If you really do need refcounting on them just create a vmw_dma_buffer bo again.

> Finally, it looks to me like the gain in the gem drivers can be accomplished 
> by just implementing ttm_bo_release() on top of
> ttm_bo_unref(), and leave the vm system alone. Sure, you'll add an extra 
> atomic operation on object destruction, but that's not a high price to pay...
And extra memory usage, and keeping the confusion of when to use a ttm or a gem 
refcount.

[Bug 52136] Mesa fails to link r600_dri.so with LLVM

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=52136

--- Comment #2 from Tom Stellard  ---
Is this still an issue?

-- 
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/20131113/a04eaeaa/attachment.html>

[Bug 64225] bfgminer --scyte generates Segmentation Fault on Northern Island

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64225

--- Comment #8 from Tom Stellard  ---
(In reply to comment #7)
> IT still failes with 
> 
> 0x7fe5003bfc10: i32 = GlobalAddress*, <4 x i32>*, <4 x i32>,
> <4 x i32>, <4 x i32>, <4 x i32>)* @SHA256> 0 [ORD=6879]
> Stack dump:
> 0.  Running pass 'Function Pass Manager' on module 'radeon'.
> 1.  Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on
> function '@search'

I think this may be working now if you try the git versions of Mesa and LLVM,
can you test?

-- 
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/20131113/f3754181/attachment.html>

[PULL] ttm-next-3.13

[Thomas Hellstrom]

The page-prot bit fix.

The following changes since commit 59c8e66378fb78adbcd05f0d09783dde6fef282b:

  drm/ttm: Fix memory type compatibility check (2013-11-06 04:36:22 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux ttm-next-3.13

for you to fetch changes up to 3943875e7b73fdd94dd9e911d69f0cee9ab66a89:

  drm/ttm: Fix vma page_prot bit manipulation (2013-11-12 23:55:31 -0800)


Thomas Hellstrom (1):
  drm/ttm: Fix vma page_prot bit manipulation

 drivers/gpu/drm/ttm/ttm_bo_vm.c |   30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)