[Bug 63698] Build error with libdri in non standard prefix

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

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

--- Comment #1 from Daniel Narvaez  ---
Created attachment 78201
  --> https://bugs.freedesktop.org/attachment.cgi?id=78201=edit
Add libdrm cflags

-- 
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/20130418/d7a859de/attachment.html>

[Bug 63698] New: Build error with libdri in non standard prefix

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

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

  Priority: medium
Bug ID: 63698
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Build error with libdri in non standard prefix
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: dwnarvaez at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

libtool: compile:  gcc -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\"
-DPACKAGE_VERSION=\"9.2.0\" "-DPACKAGE_STRING=\"Mesa 9.2.0\""
"-DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\";
-DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"9.2.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1
-DHAVE_PTHREAD=1 -DHAVE_LIBEXPAT=1 -I. -I../../../../include
-I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
-D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_X86_64_ASM -DHAVE_DLOPEN
-DHAVE_POSIX_MEMALIGN -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING
-DGLX_DIRECT_RENDERING -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS
-DHAVE_MINCORE -DHAVE_LIBUDEV -DHAVE_LLVM=0x0300 -g -O2 -Wall -std=c99
-Werror=implicit-function-declaration -Werror=missing-prototypes
-fno-strict-aliasing -fno-builtin-memcmp -MT radeon_uvd.lo -MD -MP -MF
.deps/radeon_uvd.Tpo -c radeon_uvd.c  -fPIC -DPIC -o .libs/radeon_uvd.o
In file included from radeon_uvd.c:48:0:
../../winsys/radeon/drm/radeon_winsys.h:44:35: fatal error:
libdrm/radeon_surface.h: No such file or directory

-- 
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/20130418/89e59aa6/attachment-0001.html>

linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ]

[Daniel Vetter]

On Thu, Apr 18, 2013 at 3:05 PM, Sedat Dilek  wrote:
> On Thu, Apr 18, 2013 at 10:28 AM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> Changes since 20130417:
>>
>> New Trees:  rpmsg (actually added yesterday)
>> ppc-temp (replacing powerpc for this week)
>>
>> The ceph tree gained a conflict against Linus' tree.
>>
>> The net-next tree gained a conflict against the infiniband tree.
>>
>> The usb tree gained a build failure so I used the version from
>> next-20130417.
>>
>> I added two merge fix patches after the gen-gpio tree.
>>
>> The ppc-temp tree gained a conflict against the metag tree.
>>
>> The akpm tree lost a patch that turned up elsewhere.
>>
>> 
>>
>
> Not sure what the root-cause for this call-trace is (see screenshot).
>
> This is reproducible when running my kernel build-script (4 
> parallel-make-jobs).
>
> Any hints welcome!

The panic handlers in our modeset code are pretty decent fubar - they
take mutexes all over the place. So I think the backtrace you see
there is actually a secondary effect. I've looked into fixing this up,
but the issue is that drivers themselves have tons of state protected
with mutexes, which all potentially affects the panic handler. So I've
given up on that for now ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

drm/radeon: add radeon_atom_get_clock_dividers helper

[Dan Carpenter]

Hello Christian K?nig,

The patch 7062ab67d4c6: "drm/radeon: add
radeon_atom_get_clock_dividers helper" from Apr 8, 2013, has endian
bugs.

drivers/gpu/drm/radeon/radeon_atombios.c
  2712  if (clock_type == COMPUTE_ENGINE_PLL_PARAM) {
  2713  args.v3.ulClock.ulComputeClockFlag = 
clock_type;
  2714  args.v3.ulClock.ulClockFreq = 
cpu_to_le32(clock);   /* 10 khz */
^^^
This is 24 bit bitfield so it can't store a __le32.  On little endian
systems it will truncate high bits away so that's ok, but on big endian
it will break.

  2715  
  2716  
atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *));
  2717  
  2718  dividers->post_div = args.v3.ucPostDiv;
  2719  dividers->enable_post_div = 
(args.v3.ucCntlFlag &
  2720   
ATOM_PLL_CNTL_FLAG_PLL_POST_DIV_EN) ? true : false;

There are a lot of other Sparse endian warnings but I haven't looked
at them.  Here is how to check:  http://lwn.net/Articles/205624/

regards,
dan carpenter

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

[Ville Syrjälä]

On Wed, Apr 17, 2013 at 09:08:17PM +0200, Daniel Vetter wrote:
> On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt  
> wrote:
> > On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> >> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> >> > The thing is now that you're not expected to hold these locks for a
> >> > long
> >> > time - if you need to synchronously stall while holding a lock
> >> > performance
> >> > will go down the gutters anyway. And since most current
> >> > gpus/co-processors
> >> > still can't really preempt fairness isn't that high a priority,
> >> > either.
> >> > So we didn't think too much about that.
> >>
> >> Yeah but you're proposing a new synchronization primitive for the core
> >> kernel.. all such 'fun' details need to be considered, not only those
> >> few that bear on the one usecase.
> >
> > Which bares the question, what other use cases are there?
> 
> Just stumbled over one I think: If we have a big graph of connected
> things (happens really often for video pipelines). And we want
> multiple users to use them in parallel. But sometimes a configuration
> change could take way too long and so would unduly stall a 2nd thread
> with just a global mutex, then per-object ww_mutexes would be a fit:
> You'd start with grabbing all the locks for the objects you want to
> change anything with, then grab anything in the graph that you also
> need to check. Thanks to loop detection and self-recursion this would
> all nicely work out, even for cyclic graphs of objects.

Indeed, that would make the locking for atomic modeset/page flip very
easy to handle, while still allowing the use of suitable fine grained
locks. I like the idea.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Christoph Fritz]

On Thu, 2013-04-18 at 17:37 +0300, Tomi Valkeinen wrote:
> > But here with linux-next (in contrast to 3.9-rc) removing all regulator
> > dependencies from drivers/video/omap2/dss/dpi.c does not make the trick.
> > The display stays dark :-( ...
> 
> That's with your DT hacked kernel, right? Not the official supported one.

yeah - it's fixed and working right now again.

 Thanks
   -- Christoph

[PATCH 0/3] Additional radeon audio cleanups

[Christian König]

Am 18.04.2013 17:35, schrieb alexdeucher at gmail.com:
> From: Alex Deucher 
>
> This set of patches does some additional audio cleanups
> and switches to per asic callbacks for audio.
>
> Alex Deucher (3):
>drm/radeon: clean up audio supported check
>drm/radeon: clean up audio dto programming
>drm/radeon: switch audio handling to use callbacks

Looks good to me and is:

Reviewed-by: Christian K?nig 

>
>   drivers/gpu/drm/radeon/atombios_encoders.c |   17 ++--
>   drivers/gpu/drm/radeon/evergreen_hdmi.c|   43 +-
>   drivers/gpu/drm/radeon/r600_audio.c|   64 +-
>   drivers/gpu/drm/radeon/r600_hdmi.c |  135 
> ---
>   drivers/gpu/drm/radeon/radeon.h|   10 +-
>   drivers/gpu/drm/radeon/radeon_asic.c   |   18 
>   drivers/gpu/drm/radeon/radeon_asic.h   |5 +-
>   7 files changed, 138 insertions(+), 154 deletions(-)
>

[RFC v2] video: ARM CLCD: Add DT & CDF support

[Pawel Moll]

This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them, together with the
Common Display Framework.

The DT provides information about the hardware configuration
and limitations (eg. the largest supported resolution)
but the video modes come exclusively from the Common
Display Framework drivers, referenced to by the standard CDF
binding.

Signed-off-by: Pawel Moll 
---
 .../devicetree/bindings/video/arm,pl11x.txt|   35 +++
 drivers/video/Kconfig  |1 +
 drivers/video/amba-clcd.c  |  247 
 include/linux/amba/clcd.h  |2 +
 4 files changed, 285 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt

diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt 
b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 000..ee9534a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,35 @@
+* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
+
+Required properties:
+
+- compatible : must be one of:
+   "arm,pl110", "arm,primecell"
+   "arm,pl111", "arm,primecell"
+- reg : base address and size of the control registers block
+- interrupts : the combined interrupt
+- clocks : phandles to the CLCD (pixel) clock and the APB clocks
+- clock-names : "clcdclk", "apb_pclk"
+- display : phandle to the display entity connected to the controller
+
+Optional properties:
+
+- label : string describing the controller location and/or usage
+- video-ram : phandle to DT node of the specialized video RAM to be used
+- max-hactive : maximum frame buffer width in pixels
+- max-vactive : maximum frame buffer height in pixels
+- max-bpp : maximum number of bits per pixel
+- big-endian-pixels : defining this property makes the pixel bytes being
+   accessed in Big Endian organization
+
+Example:
+
+   clcd at 1f {
+   compatible = "arm,pl111", "arm,primecell";
+   reg = <0x1f 0x1000>;
+   interrupts = <14>;
+   clocks = <_oscclk1>, <>;
+   clock-names = "clcdclk", "apb_pclk";
+   label = "IOFPGA CLCD";
+   video-ram = <_vram>;
+   display = <_muxfpga>;
+   };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 281e548..bad8166 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -340,6 +340,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+   select FB_MODE_HELPERS if OF
help
  This framebuffer device driver is for the ARM PrimeCell PL110
  Colour LCD controller.  ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..853f74c 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 

 #include 

@@ -62,6 +67,10 @@ static void clcdfb_disable(struct clcd_fb *fb)
 {
u32 val;

+   if (fb->panel->display)
+   display_entity_set_state(fb->panel->display,
+   DISPLAY_ENTITY_STATE_OFF);
+
if (fb->board->disable)
fb->board->disable(fb);

@@ -115,6 +124,11 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
 */
if (fb->board->enable)
fb->board->enable(fb);
+
+   if (fb->panel->display)
+   display_entity_set_state(fb->panel->display,
+   DISPLAY_ENTITY_STATE_ON);
+
 }

 static int
@@ -304,6 +318,13 @@ static int clcdfb_set_par(struct fb_info *info)

clcdfb_enable(fb, regs.cntl);

+   if (fb->panel->display) {
+   struct videomode mode;
+
+   videomode_from_fb_var_screeninfo(>fb.var, );
+   display_entity_update(fb->panel->display, );
+   }
+
 #ifdef DEBUG
printk(KERN_INFO
   "CLCD: Registers set to\n"
@@ -542,6 +563,229 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
 }

+#if defined(CONFIG_OF)
+static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
+   struct display_entity_interface_params *params)
+{
+   int r = params->p.tft_parallel.r_bits;
+   int g = params->p.tft_parallel.g_bits;
+   int b = params->p.tft_parallel.b_bits;
+
+   /* Bypass pixel clock divider, data output on the falling edge */
+   panel->tim2 = TIM2_BCD | TIM2_IPC;
+
+   /* TFT display, vert. comp. interrupt at the start of the back porch */
+   panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);

[PATCH 0/4] drm/edid: Recognize 60Hz and 59.94Hz CEA modes

[Ville Syrjälä]

On Wed, Apr 17, 2013 at 05:38:57PM -0300, Paulo Zanoni wrote:
> 2013/4/17  :
> > This series attempts to make our CEA mode matching recognize both the
> > 60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97,
> > 30/29.97, etc.).
> >
> > The benefits should include:
> > - Send the correct VIC in the AVI infoframe
> > - Pick the correct RGB quantization range in automatic mode
> 
> Everything looks correct, but I really didn't test anything. If you
> apply my comments from patch 2, then you have "Reviewed-by: Paulo
> Zanoni " for all the 4 patches.

Thanks for the review.

> 
> Optional bikeshedding: you could add a follow-up patch fixing the
> comments inside edid_cea_modes to reflect the correct Hz used,
> replacing, for example, "AxB at 60Hz" with "AxB at 59.94Hz". But I can
> certainly live without this :)

I think I'll defer on that one until we decide whether we want add
both 60Hz and 59.94HZ versions to the connector's mode list. Daniel
suggested we do it, but I disagree slightly since CEA-861 says that
monitors should only advertise one variant in their detailed timings.
I was thinking that we'd follow that rule here as well. But I can
be easily convinced otherwise, in case someone else has an
opinion...

-- 
Ville Syrj?l?
Intel OTC

[PATCH libdrm 3/3] modetest: Add YUV420 support and fix YVU420 Cb/Cr ordering

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

YUV420 support is trivial to add since the code already supports
YVU420.

But it looks like the YVU420 support is a bit broken. The chroma
planes are passed in the wrong order to the fill functions, so
fix that while were at it.

Signed-off-by: Ville Syrj?l? 
---
Note: I determined the the Cb/Cr ordering issue based on a very cursory
glance at the code, I didn't really read through the rendering code to make
sure I got it right. Also I couldn't test this since I don't have
hardware/driver support for planar formats currently.

 tests/modetest/buffers.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index abacea5..b75cca7 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -100,6 +100,7 @@ static const struct format_info format_info[] = {
{ DRM_FORMAT_NV16, "NV16", MAKE_YUV_INFO(YUV_YCbCr, 2, 1, 2) },
{ DRM_FORMAT_NV61, "NV61", MAKE_YUV_INFO(YUV_YCrCb, 2, 1, 2) },
/* YUV planar */
+   { DRM_FORMAT_YUV420, "YU12", MAKE_YUV_INFO(YUV_YCbCr, 2, 2, 1) },
{ DRM_FORMAT_YVU420, "YV12", MAKE_YUV_INFO(YUV_YCrCb, 2, 2, 1) },
/* RGB16 */
{ DRM_FORMAT_ARGB, "AR12", MAKE_RGB_INFO(4, 8, 4, 4, 4, 0, 4, 12) },
@@ -600,10 +601,14 @@ fill_smpte(const struct format_info *info, void 
*planes[3], unsigned int width,
return fill_smpte_yuv_planar(>yuv, planes[0], u, v,
 width, height, stride);

-   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV420:
return fill_smpte_yuv_planar(>yuv, planes[0], planes[1],
 planes[2], width, height, stride);

+   case DRM_FORMAT_YVU420:
+   return fill_smpte_yuv_planar(>yuv, planes[0], planes[2],
+planes[1], width, height, stride);
+
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ABGR:
@@ -883,10 +888,14 @@ fill_tiles(const struct format_info *info, void 
*planes[3], unsigned int width,
return fill_tiles_yuv_planar(info, planes[0], u, v,
 width, height, stride);

-   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV420:
return fill_tiles_yuv_planar(info, planes[0], planes[1],
 planes[2], width, height, stride);

+   case DRM_FORMAT_YVU420:
+   return fill_tiles_yuv_planar(info, planes[0], planes[2],
+planes[1], width, height, stride);
+
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ABGR:
@@ -1075,6 +1084,7 @@ create_test_buffer(struct kms_driver *kms, unsigned int 
format,
planes[1] = virtual + offsets[1];
break;

+   case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
offsets[0] = 0;
kms_bo_get_prop(bo, KMS_HANDLE, [0]);
-- 
1.8.1.5

[PATCH v2 libdrm 2/3] modetest: Make RGB565 pwetty too

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

Render the crosshairs for 565 and x888/a888 formats.

v2: Use the drm format to determine cairo format

Signed-off-by: Ville Syrj?l? 
---
 tests/modetest/buffers.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 2f3adf8..abacea5 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -656,15 +656,32 @@ fill_smpte(const struct format_info *info, void 
*planes[3], unsigned int width,
 #define BLUE  0

 static void
-make_pwetty(void *data, int width, int height, int stride)
+make_pwetty(void *data, int width, int height, int stride, uint32_t format)
 {
 #ifdef HAVE_CAIRO
cairo_surface_t *surface;
cairo_t *cr;
int x, y;
+   cairo_format_t cairo_format;
+
+   /* we can ignore the order of R,G,B channels */
+   switch (format) {
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   cairo_format = CAIRO_FORMAT_ARGB32;
+   break;
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565:
+   cairo_format = CAIRO_FORMAT_RGB16_565;
+   break;
+   default:
+   return;
+   }

surface = cairo_image_surface_create_for_data(data,
- CAIRO_FORMAT_ARGB32,
+ cairo_format,
  width, height,
  stride);
cr = cairo_create(surface);
@@ -774,6 +791,7 @@ fill_tiles_rgb16(const struct format_info *info, unsigned 
char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
const struct rgb_info *rgb = >rgb;
+   unsigned char *mem_base = mem;
unsigned int x, y;

for (y = 0; y < height; ++y) {
@@ -790,6 +808,8 @@ fill_tiles_rgb16(const struct format_info *info, unsigned 
char *mem,
}
mem += stride;
}
+
+   make_pwetty(mem_base, width, height, stride, info->format);
 }

 static void
@@ -837,7 +857,7 @@ fill_tiles_rgb32(const struct format_info *info, unsigned 
char *mem,
mem += stride;
}

-   make_pwetty(mem_base, width, height, stride);
+   make_pwetty(mem_base, width, height, stride, info->format);
 }

 static void
-- 
1.8.1.5

[PATCH libdrm 1/3] modetest: Pass format_info to fill_tiles functions

[ville.syrj...@linux.intel.com]

From: Ville Syrj?l? 

The fourcc is inside the format_info structure, so if we want to use
it inside the various fill_tiles functions, we need to pass down the
whole format_info, not just the rgb/yuv infos.

Signed-off-by: Ville Syrj?l? 
---
 tests/modetest/buffers.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index b249f1f..2f3adf8 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -702,11 +702,12 @@ make_pwetty(void *data, int width, int height, int stride)
 }

 static void
-fill_tiles_yuv_planar(const struct yuv_info *yuv,
+fill_tiles_yuv_planar(const struct format_info *info,
  unsigned char *y_mem, unsigned char *u_mem,
  unsigned char *v_mem, unsigned int width,
  unsigned int height, unsigned int stride)
 {
+   const struct yuv_info *yuv = >yuv;
unsigned int cs = yuv->chroma_stride;
unsigned int xsub = yuv->xsub;
unsigned int ysub = yuv->ysub;
@@ -736,10 +737,11 @@ fill_tiles_yuv_planar(const struct yuv_info *yuv,
 }

 static void
-fill_tiles_yuv_packed(const struct yuv_info *yuv, unsigned char *mem,
+fill_tiles_yuv_packed(const struct format_info *info, unsigned char *mem,
  unsigned int width, unsigned int height,
  unsigned int stride)
 {
+   const struct yuv_info *yuv = >yuv;
unsigned char *y_mem = (yuv->order & YUV_YC) ? mem : mem + 1;
unsigned char *c_mem = (yuv->order & YUV_CY) ? mem : mem + 1;
unsigned int u = (yuv->order & YUV_YCrCb) ? 2 : 0;
@@ -768,9 +770,10 @@ fill_tiles_yuv_packed(const struct yuv_info *yuv, unsigned 
char *mem,
 }

 static void
-fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
+fill_tiles_rgb16(const struct format_info *info, unsigned char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
+   const struct rgb_info *rgb = >rgb;
unsigned int x, y;

for (y = 0; y < height; ++y) {
@@ -790,9 +793,10 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char 
*mem,
 }

 static void
-fill_tiles_rgb24(const struct rgb_info *rgb, unsigned char *mem,
+fill_tiles_rgb24(const struct format_info *info, unsigned char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
+   const struct rgb_info *rgb = >rgb;
unsigned int x, y;

for (y = 0; y < height; ++y) {
@@ -811,9 +815,10 @@ fill_tiles_rgb24(const struct rgb_info *rgb, unsigned char 
*mem,
 }

 static void
-fill_tiles_rgb32(const struct rgb_info *rgb, unsigned char *mem,
+fill_tiles_rgb32(const struct format_info *info, unsigned char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
+   const struct rgb_info *rgb = >rgb;
unsigned char *mem_base = mem;
unsigned int x, y;

@@ -846,7 +851,7 @@ fill_tiles(const struct format_info *info, void *planes[3], 
unsigned int width,
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
-   return fill_tiles_yuv_packed(>yuv, planes[0],
+   return fill_tiles_yuv_packed(info, planes[0],
 width, height, stride);

case DRM_FORMAT_NV12:
@@ -855,11 +860,11 @@ fill_tiles(const struct format_info *info, void 
*planes[3], unsigned int width,
case DRM_FORMAT_NV61:
u = info->yuv.order & YUV_YCbCr ? planes[1] : planes[1] + 1;
v = info->yuv.order & YUV_YCrCb ? planes[1] : planes[1] + 1;
-   return fill_tiles_yuv_planar(>yuv, planes[0], u, v,
+   return fill_tiles_yuv_planar(info, planes[0], u, v,
 width, height, stride);

case DRM_FORMAT_YVU420:
-   return fill_tiles_yuv_planar(>yuv, planes[0], planes[1],
+   return fill_tiles_yuv_planar(info, planes[0], planes[1],
 planes[2], width, height, stride);

case DRM_FORMAT_ARGB:
@@ -880,12 +885,12 @@ fill_tiles(const struct format_info *info, void 
*planes[3], unsigned int width,
case DRM_FORMAT_RGBX5551:
case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_BGRX5551:
-   return fill_tiles_rgb16(>rgb, planes[0],
+   return fill_tiles_rgb16(info, planes[0],
width, height, stride);

case DRM_FORMAT_BGR888:
case DRM_FORMAT_RGB888:
-   return fill_tiles_rgb24(>rgb, planes[0],
+   return fill_tiles_rgb24(info, planes[0],
width, height, stride);
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
@@ -903,7 +908,7 @@ fill_tiles(const struct format_info *info, void *planes[3], 
unsigned int width,
   

[PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Ville Syrjälä]

On Thu, Apr 18, 2013 at 04:19:30PM +0200, Laurent Pinchart wrote:
> On Thursday 18 April 2013 17:06:57 Ville Syrj?l? wrote:
> > On Thu, Apr 18, 2013 at 03:43:23PM +0200, Laurent Pinchart wrote:
> > > On Wednesday 17 April 2013 22:18:01 ville.syrjala at linux.intel.com 
> > > wrote:
> > > > From: Ville Syrj?l? 
> > > > 
> > > > Signed-off-by: Ville Syrj?l? 
> > > > ---
> > > > 
> > > >  tests/modetest/buffers.c | 9 ++---
> > > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> > > > index 5086381..6b117b4 100644
> > > > --- a/tests/modetest/buffers.c
> > > > +++ b/tests/modetest/buffers.c
> > > > @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
> > > > *planes[3], unsigned int width, #define BLUE  0
> > > > 
> > > >  static void
> > > > 
> > > > -make_pwetty(void *data, int width, int height, int stride)
> > > > +make_pwetty(void *data, int width, int height, int stride, int rgb16)
> > > 
> > > What about passing the format 4cc instead ?
> > 
> > It's a bit more work since I need to pass the whole format_info
> > down from fill_tiles(). But I can make a v2 with that change.
> 
> It was just an idea to make the code more future-proof, in case we decide to 
> make 24-bit formats pwetty at some point. Maybe a bpp value would be a good 
> compromise ?

I already implemented your original idea. Just doing a quick test now.

It's a better idea anyway since we can then check that the color
channels match what we're rendering. My original code just assumed
that it can render RGB565 into an XRGB1555 buffer for example. That
produces some rather ugly results in reality, so it's better to
limit it to the formats where the size/location of RGB channels match.
The order or RGB channels doesn't actually matter since the source
color is always white or black.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Tomi Valkeinen]

On 2013-04-18 13:13, Christoph Fritz wrote:
> On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote:
>> On 2013-04-18 12:09, Tomi Valkeinen wrote:
>>> On 2013-04-18 11:37, Christoph Fritz wrote:
>>
>>>> With linux-next this patch breaks compiling here because DPI now depends
>>>> on DSI - but my omap3 board here doesn't use DSI at all:
>>>>
>>>> drivers/video/omap2/dss/dpi.c: In function ?dpi_calc_pll_cb?:
>>>> drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
>>>> ?dsi_hsdiv_calc?
>>>> drivers/video/omap2/dss/dpi.c: In function ?dpi_dsi_clk_calc?:
>>>> drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
>>>> ?dsi_get_pll_clkin?
>>>> drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
>>>> ?dsi_pll_calc?
>>>>
>>>> Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be 
>>>> want to merge it?
>>>
>>> Thanks for reporting this. We shouldn't make DPI depend on DSI. We
>>> should make dummy functions for the above when DSI is not enabled so
>>> that DPI compiles. I'll make a fix.
>>
>> Patch below. Can you try it out? It works for me on Panda.
> 
> Thanks, it compiles here fine too.
> 
> and while booting I'm now getting as with 3.9-rc:
> [0.409729] OMAP DSS rev 2.0
> [0.410980] omapdss DPI error: can't get VDDS_DSI regulator
> [0.410980] omapdss DPI error: device ips-056t init failed: -517
> 
> But here with linux-next (in contrast to 3.9-rc) removing all regulator
> dependencies from drivers/video/omap2/dss/dpi.c does not make the trick.
> The display stays dark :-( ...

That's with your DT hacked kernel, right? Not the official supported one.

I don't think anything changed related to regulators in omapdss.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130418/2884af88/attachment-0001.pgp>

[PATCH v2 libdrm 2/3] modetest: Make RGB565 pwetty too

[Laurent Pinchart]

On Thursday 18 April 2013 18:26:58 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> Render the crosshairs for 565 and x888/a888 formats.
> 
> v2: Use the drm format to determine cairo format
> 
> Signed-off-by: Ville Syrj?l? 

Acked-by: Laurent Pinchart 

> ---
>  tests/modetest/buffers.c | 26 +++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> index 2f3adf8..abacea5 100644
> --- a/tests/modetest/buffers.c
> +++ b/tests/modetest/buffers.c
> @@ -656,15 +656,32 @@ fill_smpte(const struct format_info *info, void
> *planes[3], unsigned int width, #define BLUE  0
> 
>  static void
> -make_pwetty(void *data, int width, int height, int stride)
> +make_pwetty(void *data, int width, int height, int stride, uint32_t format)
> {
>  #ifdef HAVE_CAIRO
>   cairo_surface_t *surface;
>   cairo_t *cr;
>   int x, y;
> + cairo_format_t cairo_format;
> +
> + /* we can ignore the order of R,G,B channels */
> + switch (format) {
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + cairo_format = CAIRO_FORMAT_ARGB32;
> + break;
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> + cairo_format = CAIRO_FORMAT_RGB16_565;
> + break;
> + default:
> + return;
> + }
> 
>   surface = cairo_image_surface_create_for_data(data,
> -   CAIRO_FORMAT_ARGB32,
> +   cairo_format,
> width, height,
> stride);
>   cr = cairo_create(surface);
> @@ -774,6 +791,7 @@ fill_tiles_rgb16(const struct format_info *info,
> unsigned char *mem, unsigned int width, unsigned int height, unsigned int
> stride)
>  {
>   const struct rgb_info *rgb = >rgb;
> + unsigned char *mem_base = mem;
>   unsigned int x, y;
> 
>   for (y = 0; y < height; ++y) {
> @@ -790,6 +808,8 @@ fill_tiles_rgb16(const struct format_info *info,
> unsigned char *mem, }
>   mem += stride;
>   }
> +
> + make_pwetty(mem_base, width, height, stride, info->format);
>  }
> 
>  static void
> @@ -837,7 +857,7 @@ fill_tiles_rgb32(const struct format_info *info,
> unsigned char *mem, mem += stride;
>   }
> 
> - make_pwetty(mem_base, width, height, stride);
> + make_pwetty(mem_base, width, height, stride, info->format);
>  }
> 
>  static void
-- 
Regards,

Laurent Pinchart

[PATCH libdrm 1/3] modetest: Pass format_info to fill_tiles functions

[Laurent Pinchart]

On Thursday 18 April 2013 18:26:57 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> The fourcc is inside the format_info structure, so if we want to use
> it inside the various fill_tiles functions, we need to pass down the
> whole format_info, not just the rgb/yuv infos.
> 
> Signed-off-by: Ville Syrj?l? 

Acked-by: Laurent Pinchart 

> ---
>  tests/modetest/buffers.c | 27 ---
>  1 file changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> index b249f1f..2f3adf8 100644
> --- a/tests/modetest/buffers.c
> +++ b/tests/modetest/buffers.c
> @@ -702,11 +702,12 @@ make_pwetty(void *data, int width, int height, int
> stride) }
> 
>  static void
> -fill_tiles_yuv_planar(const struct yuv_info *yuv,
> +fill_tiles_yuv_planar(const struct format_info *info,
> unsigned char *y_mem, unsigned char *u_mem,
> unsigned char *v_mem, unsigned int width,
> unsigned int height, unsigned int stride)
>  {
> + const struct yuv_info *yuv = >yuv;
>   unsigned int cs = yuv->chroma_stride;
>   unsigned int xsub = yuv->xsub;
>   unsigned int ysub = yuv->ysub;
> @@ -736,10 +737,11 @@ fill_tiles_yuv_planar(const struct yuv_info *yuv,
>  }
> 
>  static void
> -fill_tiles_yuv_packed(const struct yuv_info *yuv, unsigned char *mem,
> +fill_tiles_yuv_packed(const struct format_info *info, unsigned char *mem,
> unsigned int width, unsigned int height,
> unsigned int stride)
>  {
> + const struct yuv_info *yuv = >yuv;
>   unsigned char *y_mem = (yuv->order & YUV_YC) ? mem : mem + 1;
>   unsigned char *c_mem = (yuv->order & YUV_CY) ? mem : mem + 1;
>   unsigned int u = (yuv->order & YUV_YCrCb) ? 2 : 0;
> @@ -768,9 +770,10 @@ fill_tiles_yuv_packed(const struct yuv_info *yuv,
> unsigned char *mem, }
> 
>  static void
> -fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
> +fill_tiles_rgb16(const struct format_info *info, unsigned char *mem,
>unsigned int width, unsigned int height, unsigned int stride)
>  {
> + const struct rgb_info *rgb = >rgb;
>   unsigned int x, y;
> 
>   for (y = 0; y < height; ++y) {
> @@ -790,9 +793,10 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned
> char *mem, }
> 
>  static void
> -fill_tiles_rgb24(const struct rgb_info *rgb, unsigned char *mem,
> +fill_tiles_rgb24(const struct format_info *info, unsigned char *mem,
>unsigned int width, unsigned int height, unsigned int stride)
>  {
> + const struct rgb_info *rgb = >rgb;
>   unsigned int x, y;
> 
>   for (y = 0; y < height; ++y) {
> @@ -811,9 +815,10 @@ fill_tiles_rgb24(const struct rgb_info *rgb, unsigned
> char *mem, }
> 
>  static void
> -fill_tiles_rgb32(const struct rgb_info *rgb, unsigned char *mem,
> +fill_tiles_rgb32(const struct format_info *info, unsigned char *mem,
>unsigned int width, unsigned int height, unsigned int stride)
>  {
> + const struct rgb_info *rgb = >rgb;
>   unsigned char *mem_base = mem;
>   unsigned int x, y;
> 
> @@ -846,7 +851,7 @@ fill_tiles(const struct format_info *info, void
> *planes[3], unsigned int width, case DRM_FORMAT_VYUY:
>   case DRM_FORMAT_YUYV:
>   case DRM_FORMAT_YVYU:
> - return fill_tiles_yuv_packed(>yuv, planes[0],
> + return fill_tiles_yuv_packed(info, planes[0],
>width, height, stride);
> 
>   case DRM_FORMAT_NV12:
> @@ -855,11 +860,11 @@ fill_tiles(const struct format_info *info, void
> *planes[3], unsigned int width, case DRM_FORMAT_NV61:
>   u = info->yuv.order & YUV_YCbCr ? planes[1] : planes[1] + 1;
>   v = info->yuv.order & YUV_YCrCb ? planes[1] : planes[1] + 1;
> - return fill_tiles_yuv_planar(>yuv, planes[0], u, v,
> + return fill_tiles_yuv_planar(info, planes[0], u, v,
>width, height, stride);
> 
>   case DRM_FORMAT_YVU420:
> - return fill_tiles_yuv_planar(>yuv, planes[0], planes[1],
> + return fill_tiles_yuv_planar(info, planes[0], planes[1],
>planes[2], width, height, stride);
> 
>   case DRM_FORMAT_ARGB:
> @@ -880,12 +885,12 @@ fill_tiles(const struct format_info *info, void
> *planes[3], unsigned int width, case DRM_FORMAT_RGBX5551:
>   case DRM_FORMAT_BGRA5551:
>   case DRM_FORMAT_BGRX5551:
> - return fill_tiles_rgb16(>rgb, planes[0],
> + return fill_tiles_rgb16(info, planes[0],
>   width, height, stride);
> 
>   case DRM_FORMAT_BGR888:
>   case DRM_FORMAT_RGB888:
> - return fill_tiles_rgb24(>rgb, planes[0],
> + return fill_tiles_rgb24(info, planes[0],
>   width, height, stride);
>   

Radeon lockup on 3.8.5-201.fc18.x86_64

[Alex Deucher]

On Thu, Apr 18, 2013 at 5:11 PM, Andy Lutomirski  wrote:
> On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher  wrote:
>> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski  
>> wrote:
>>> Every day or so, I'll click something and my screens go blank for a
>>> second or two.  dmesg complains about a lockup, and afterwards
>>> everything is painfully slow.  (Even switching focus to other emacs
>>> windows takes a second or two.)  Once this happens, if I restart X, I
>>> get a blank screen, although the mouse still works and I can switch
>>> VTs and use the console.
>>
>> Try disabling hyperZ.  Set env var R600_HYPERZ=0 (mesa 9.1) or
>> R600_DEBUG=nohyperz (mesa git).
>
> It lasted longer.  I have both of those environment variables set on
> the Xorg process but not on clients.  Do  I need it everywhere?

For anything that uses the 3D driver.

Alex

>
> The failure was:
>
> [847785.776441] radeon :08:00.0: GPU lockup CP stall for more than 
> 10654msec
> [847785.776449] radeon :08:00.0: GPU lockup (waiting for
> 0x90f8 last fence id 0x90f7)
> [847785.777542] radeon :08:00.0: Saved 71 dwords of commands on ring 0.
> [847785.777548] radeon :08:00.0: GPU softreset: 0x0007
> [847785.789844] radeon :08:00.0:   GRBM_STATUS   = 0xA0003828
> [847785.789847] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
> [847785.789850] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
> [847785.789852] radeon :08:00.0:   SRBM_STATUS   = 0x200080C0
> [847785.789855] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
> [847785.789857] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
> [847785.789860] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x0004
> [847785.789862] radeon :08:00.0:   R_008680_CP_STAT  = 0x80008647
> [847785.789864] radeon :08:00.0:   GRBM_SOFT_RESET=0x7F6B
> [847785.789919] radeon :08:00.0:   GRBM_STATUS   = 0x3828
> [847785.789922] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
> [847785.789924] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
> [847785.789927] radeon :08:00.0:   SRBM_STATUS   = 0x200080C0
> [847785.789929] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
> [847785.789932] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
> [847785.789934] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x
> [847785.789937] radeon :08:00.0:   R_008680_CP_STAT  = 0x
> [847785.789941] radeon :08:00.0:   R_00D034_DMA_STATUS_REG   = 0x04483106
> [847785.789997] radeon :08:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
> [847785.807356] radeon :08:00.0: GPU reset succeeded, trying to resume
> [847785.825791] [drm] probing gen 2 caps for device 8086:1d1a = 2/0
> [847785.825797] [drm] enabling PCIE gen 2 link speeds, disable with
> radeon.pcie_gen2=0
> [847785.832851] [drm] PCIE GART of 512M enabled (table at 0x0004).
> [847785.832993] radeon :08:00.0: WB enabled
> [847785.832996] radeon :08:00.0: fence driver on ring 0 use gpu
> addr 0x4c00 and cpu addr 0x88044295bc00
> [847785.832997] radeon :08:00.0: fence driver on ring 3 use gpu
> addr 0x4c0c and cpu addr 0x88044295bc0c
> [847785.849454] [drm] ring test on 0 succeeded in 2 usecs
> [847785.849523] [drm] ring test on 3 succeeded in 1 usecs
> [847785.849604] [drm] ib test on ring 0 succeeded in 0 usecs
> [847785.849681] [drm] ib test on ring 3 succeeded in 1 usecs
>
> --Andy

[PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Ville Syrjälä]

On Thu, Apr 18, 2013 at 03:43:23PM +0200, Laurent Pinchart wrote:
> Hi Ville,
> 
> Thank you for the patch.
> 
> On Wednesday 17 April 2013 22:18:01 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrj?l? 
> > 
> > Signed-off-by: Ville Syrj?l? 
> > ---
> >  tests/modetest/buffers.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> > index 5086381..6b117b4 100644
> > --- a/tests/modetest/buffers.c
> > +++ b/tests/modetest/buffers.c
> > @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
> > *planes[3], unsigned int width, #define BLUE  0
> > 
> >  static void
> > -make_pwetty(void *data, int width, int height, int stride)
> > +make_pwetty(void *data, int width, int height, int stride, int rgb16)
> 
> What about passing the format 4cc instead ?

It's a bit more work since I need to pass the whole format_info
down from fill_tiles(). But I can make a v2 with that change.

> >  {
> >  #ifdef HAVE_CAIRO
> > cairo_surface_t *surface;
> > @@ -609,7 +609,7 @@ make_pwetty(void *data, int width, int height, int
> > stride) int x, y;
> > 
> > surface = cairo_image_surface_create_for_data(data,
> > - CAIRO_FORMAT_ARGB32,
> > + rgb16 ? 
> > CAIRO_FORMAT_RGB16_565 : 
> CAIRO_FORMAT_ARGB32,
> >   width, height,
> >   stride);
> > cr = cairo_create(surface);
> > @@ -716,6 +716,7 @@ static void
> >  fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
> >  unsigned int width, unsigned int height, unsigned int stride)
> >  {
> > +   unsigned char *mem_base = mem;
> > unsigned int x, y;
> > 
> > for (y = 0; y < height; ++y) {
> > @@ -732,6 +733,8 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned
> > char *mem, }
> > mem += stride;
> > }
> > +
> > +   make_pwetty(mem_base, width, height, stride, 1);
> >  }
> > 
> >  static void
> > @@ -777,7 +780,7 @@ fill_tiles_rgb32(const struct rgb_info *rgb, unsigned
> > char *mem, mem += stride;
> > }
> > 
> > -   make_pwetty(mem_base, width, height, stride);
> > +   make_pwetty(mem_base, width, height, stride, 0);
> >  }
> > 
> >  static void
> 
> -- 
> Regards,
> 
> Laurent Pinchart

-- 
Ville Syrj?l?
Intel OTC

[GIT PULL] drm/tegra: Changes for v3.10-rc1

[Thierry Reding]

drivers/gpu/host1x/job.c   | 603 +++
 drivers/gpu/host1x/job.h   | 162 +++
 drivers/gpu/host1x/syncpt.c| 387 +++
 drivers/gpu/host1x/syncpt.h| 165 +++
 drivers/video/Kconfig  |   2 +
 include/trace/events/host1x.h  | 272 +++
 include/uapi/drm/Kbuild|   1 +
 include/uapi/drm/tegra_drm.h   | 136 ++
 55 files changed, 7558 insertions(+), 644 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/Makefile
 delete mode 100644 drivers/gpu/drm/tegra/drm.c
 delete mode 100644 drivers/gpu/drm/tegra/fb.c
 delete mode 100644 drivers/gpu/drm/tegra/host1x.c
 create mode 100644 drivers/gpu/host1x/Kconfig
 create mode 100644 drivers/gpu/host1x/Makefile
 create mode 100644 drivers/gpu/host1x/cdma.c
 create mode 100644 drivers/gpu/host1x/cdma.h
 create mode 100644 drivers/gpu/host1x/channel.c
 create mode 100644 drivers/gpu/host1x/channel.h
 create mode 100644 drivers/gpu/host1x/debug.c
 create mode 100644 drivers/gpu/host1x/debug.h
 create mode 100644 drivers/gpu/host1x/dev.c
 create mode 100644 drivers/gpu/host1x/dev.h
 rename drivers/gpu/{drm/tegra => host1x/drm}/Kconfig (52%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/dc.c (97%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/dc.h (100%)
 create mode 100644 drivers/gpu/host1x/drm/drm.c
 rename drivers/gpu/{drm/tegra => host1x/drm}/drm.h (77%)
 create mode 100644 drivers/gpu/host1x/drm/fb.c
 create mode 100644 drivers/gpu/host1x/drm/gem.c
 create mode 100644 drivers/gpu/host1x/drm/gem.h
 create mode 100644 drivers/gpu/host1x/drm/gr2d.c
 rename drivers/gpu/{drm/tegra => host1x/drm}/hdmi.c (99%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/hdmi.h (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/output.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/rgb.c (100%)
 create mode 100644 drivers/gpu/host1x/host1x.h
 create mode 100644 drivers/gpu/host1x/host1x_bo.h
 create mode 100644 drivers/gpu/host1x/host1x_client.h
 create mode 100644 drivers/gpu/host1x/hw/Makefile
 create mode 100644 drivers/gpu/host1x/hw/cdma_hw.c
 create mode 100644 drivers/gpu/host1x/hw/channel_hw.c
 create mode 100644 drivers/gpu/host1x/hw/debug_hw.c
 create mode 100644 drivers/gpu/host1x/hw/host1x01.c
 create mode 100644 drivers/gpu/host1x/hw/host1x01.h
 create mode 100644 drivers/gpu/host1x/hw/host1x01_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_channel.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_sync.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_uclass.h
 create mode 100644 drivers/gpu/host1x/hw/intr_hw.c
 create mode 100644 drivers/gpu/host1x/hw/syncpt_hw.c
 create mode 100644 drivers/gpu/host1x/intr.c
 create mode 100644 drivers/gpu/host1x/intr.h
 create mode 100644 drivers/gpu/host1x/job.c
 create mode 100644 drivers/gpu/host1x/job.h
 create mode 100644 drivers/gpu/host1x/syncpt.c
 create mode 100644 drivers/gpu/host1x/syncpt.h
 create mode 100644 include/trace/events/host1x.h
 create mode 100644 include/uapi/drm/tegra_drm.h
-- 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/20130418/2157864c/attachment-0001.pgp>

[PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Laurent Pinchart]

On Thursday 18 April 2013 17:06:57 Ville Syrj?l? wrote:
> On Thu, Apr 18, 2013 at 03:43:23PM +0200, Laurent Pinchart wrote:
> > On Wednesday 17 April 2013 22:18:01 ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrj?l? 
> > > 
> > > Signed-off-by: Ville Syrj?l? 
> > > ---
> > > 
> > >  tests/modetest/buffers.c | 9 ++---
> > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> > > index 5086381..6b117b4 100644
> > > --- a/tests/modetest/buffers.c
> > > +++ b/tests/modetest/buffers.c
> > > @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
> > > *planes[3], unsigned int width, #define BLUE  0
> > > 
> > >  static void
> > > 
> > > -make_pwetty(void *data, int width, int height, int stride)
> > > +make_pwetty(void *data, int width, int height, int stride, int rgb16)
> > 
> > What about passing the format 4cc instead ?
> 
> It's a bit more work since I need to pass the whole format_info
> down from fill_tiles(). But I can make a v2 with that change.

It was just an idea to make the code more future-proof, in case we decide to 
make 24-bit formats pwetty at some point. Maybe a bpp value would be a good 
compromise ?


-- 
Regards,

Laurent Pinchart

[PATCH 0/6] drm/radeon: minor HDMI improvements

[Rafał Miłecki]

2013/4/18 Alex Deucher :
> On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki  wrote:
>> I've managed to track fglrx operations on HDMI regs, so we can finally setup
>> everything in (hopefully) the correct way and order.
>>
>> This changes HDMI setup on Evergreen to mostly match fglrx and was tested on:
>> 1) AMD Radeon HD 6320 (PALM == DCE41)
>> 2) AMD Radeon HD 6970M (BARTS == DCE5)
>> No regressions noticed, I can still play audio, including LPCM, AC3 and DTS.
>>
>> Unfortunately I don't have any DCE4 hardware to test this, but that changes
>> shouldn't cause any regressions. I hope that with such improvements we will
>> finally able to enable audio by default.
>
> I've applied patches 1, 4, 5, 6.  For patch 2, I'd prefer we just not
> enable the interrupts rather than removing the code altogether at this
> point.  See the attached patch.  For patch 3, none of the registers
> mentioned are directly related to audio setup.

I agree with that, thanks a lot for handling this patchset!

Your change from r600_hdmi.c should be probably also made in
r600_audio_chipset_supported.

-- 
Rafa?

[PATCH libdrm 3/5] modetest: Add support for all 16/32 bpp RGB formats

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:03 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> Signed-off-by: Ville Syrj?l? 

Acked-by: Laurent Pinchart 

> ---
>  tests/modetest/buffers.c | 120 ++--
>  1 file changed, 115 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> index 7f534a1..3b1685c 100644
> --- a/tests/modetest/buffers.c
> +++ b/tests/modetest/buffers.c
> @@ -102,17 +102,44 @@ static const struct format_info format_info[] = {
>   /* YUV planar */
>   { DRM_FORMAT_YVU420, "YV12", MAKE_YUV_INFO(YUV_YCrCb, 2, 2, 1) },
>   /* RGB16 */
> + { DRM_FORMAT_ARGB, "AR12", MAKE_RGB_INFO(4, 8, 4, 4, 4, 0, 4, 12) },
> + { DRM_FORMAT_XRGB, "XR12", MAKE_RGB_INFO(4, 8, 4, 4, 4, 0, 0, 0) },
> + { DRM_FORMAT_ABGR, "AB12", MAKE_RGB_INFO(4, 0, 4, 4, 4, 8, 4, 12) },
> + { DRM_FORMAT_XBGR, "XB12", MAKE_RGB_INFO(4, 0, 4, 4, 4, 8, 0, 0) },
> + { DRM_FORMAT_RGBA, "RA12", MAKE_RGB_INFO(4, 12, 4, 8, 4, 4, 4, 0) },
> + { DRM_FORMAT_RGBX, "RX12", MAKE_RGB_INFO(4, 12, 4, 8, 4, 4, 0, 0) },
> + { DRM_FORMAT_BGRA, "BA12", MAKE_RGB_INFO(4, 4, 4, 8, 4, 12, 4, 0) },
> + { DRM_FORMAT_BGRX, "BX12", MAKE_RGB_INFO(4, 4, 4, 8, 4, 12, 0, 0) },
>   { DRM_FORMAT_ARGB1555, "AR15", MAKE_RGB_INFO(5, 10, 5, 5, 5, 0, 1, 15) 
> },
>   { DRM_FORMAT_XRGB1555, "XR15", MAKE_RGB_INFO(5, 10, 5, 5, 5, 0, 0, 0) },
> + { DRM_FORMAT_ABGR1555, "AB15", MAKE_RGB_INFO(5, 0, 5, 5, 5, 10, 1, 15) 
> },
> + { DRM_FORMAT_XBGR1555, "XB15", MAKE_RGB_INFO(5, 0, 5, 5, 5, 10, 0, 0) },
> + { DRM_FORMAT_RGBA5551, "RA15", MAKE_RGB_INFO(5, 11, 5, 6, 5, 1, 1, 0) },
> + { DRM_FORMAT_RGBX5551, "RX15", MAKE_RGB_INFO(5, 11, 5, 6, 5, 1, 0, 0) },
> + { DRM_FORMAT_BGRA5551, "BA15", MAKE_RGB_INFO(5, 1, 5, 6, 5, 11, 1, 0) },
> + { DRM_FORMAT_BGRX5551, "BX15", MAKE_RGB_INFO(5, 1, 5, 6, 5, 11, 0, 0) },
>   { DRM_FORMAT_RGB565, "RG16", MAKE_RGB_INFO(5, 11, 6, 5, 5, 0, 0, 0) },
> + { DRM_FORMAT_BGR565, "BG16", MAKE_RGB_INFO(5, 0, 6, 5, 5, 11, 0, 0) },
>   /* RGB24 */
>   { DRM_FORMAT_BGR888, "BG24", MAKE_RGB_INFO(8, 0, 8, 8, 8, 16, 0, 0) },
>   { DRM_FORMAT_RGB888, "RG24", MAKE_RGB_INFO(8, 16, 8, 8, 8, 0, 0, 0) },
>   /* RGB32 */
>   { DRM_FORMAT_ARGB, "AR24", MAKE_RGB_INFO(8, 16, 8, 8, 8, 0, 8, 24) 
> },
> - { DRM_FORMAT_BGRA, "BA24", MAKE_RGB_INFO(8, 8, 8, 16, 8, 24, 8, 0) 
> },
>   { DRM_FORMAT_XRGB, "XR24", MAKE_RGB_INFO(8, 16, 8, 8, 8, 0, 0, 0) },
> + { DRM_FORMAT_ABGR, "AB24", MAKE_RGB_INFO(8, 0, 8, 8, 8, 16, 8, 24) 
> },
> + { DRM_FORMAT_XBGR, "XB24", MAKE_RGB_INFO(8, 0, 8, 8, 8, 16, 0, 0) },
> + { DRM_FORMAT_RGBA, "RA24", MAKE_RGB_INFO(8, 24, 8, 16, 8, 8, 8, 0) 
> },
> + { DRM_FORMAT_RGBX, "RX24", MAKE_RGB_INFO(8, 24, 8, 16, 8, 8, 0, 0) 
> },
> + { DRM_FORMAT_BGRA, "BA24", MAKE_RGB_INFO(8, 8, 8, 16, 8, 24, 8, 0) 
> },
>   { DRM_FORMAT_BGRX, "BX24", MAKE_RGB_INFO(8, 8, 8, 16, 8, 24, 0, 0) 
> },
> + { DRM_FORMAT_ARGB2101010, "AR30", MAKE_RGB_INFO(10, 20, 10, 10, 10, 0, 
> 2,
> 30) }, +  { DRM_FORMAT_XRGB2101010, "XR30", MAKE_RGB_INFO(10, 20, 10, 10,
> 10, 0, 0, 0) }, + { DRM_FORMAT_ABGR2101010, "AB30", MAKE_RGB_INFO(10, 0,
> 10, 10, 10, 20, 2, 30) }, +   { DRM_FORMAT_XBGR2101010, "XB30",
> MAKE_RGB_INFO(10, 0, 10, 10, 10, 20, 0, 0) }, +   { 
> DRM_FORMAT_RGBA1010102,
> "RA30", MAKE_RGB_INFO(10, 22, 10, 12, 10, 2, 2, 0) }, +   {
> DRM_FORMAT_RGBX1010102, "RX30", MAKE_RGB_INFO(10, 22, 10, 12, 10, 2, 0, 0)
> }, +  { DRM_FORMAT_BGRA1010102, "BA30", MAKE_RGB_INFO(10, 2, 10, 12, 10, 
22,
> 2, 0) }, +{ DRM_FORMAT_BGRX1010102, "BX30", MAKE_RGB_INFO(10, 2, 10, 12,
> 10, 22, 0, 0) }, };
> 
>  unsigned int format_fourcc(const char *name)
> @@ -577,19 +604,47 @@ fill_smpte(const struct format_info *info, void
> *planes[3], unsigned int width, return fill_smpte_yuv_planar(>yuv,
> planes[0], planes[1],
>planes[2], width, height, stride);
> 
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_RGBX:
> + case DRM_FORMAT_BGRA:
> + case DRM_FORMAT_BGRX:
>   case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
>   case DRM_FORMAT_ARGB1555:
>   case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_ABGR1555:
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_RGBA5551:
> + case DRM_FORMAT_RGBX5551:
> + case DRM_FORMAT_BGRA5551:
> + case DRM_FORMAT_BGRX5551:
>   return fill_smpte_rgb16(>rgb, planes[0],
>   width, height, stride);
> +
>   case DRM_FORMAT_BGR888:
>   case DRM_FORMAT_RGB888:
>   return fill_smpte_rgb24(>rgb, planes[0],
>   width, 

[PATCH libdrm 4/5] modetest: Print possible_crtcs for planes

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:04 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> Signed-off-by: Ville Syrj?l? 

Acked-by: Laurent Pinchart 

> ---
>  tests/modetest/modetest.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index c91bb9d..27cd2ce 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -429,7 +429,7 @@ static void dump_planes(void)
>   }
> 
>   printf("Planes:\n");
> - printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n");
> + printf("id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\tpossible crtcs\n");
>   for (i = 0; i < plane_resources->count_planes; i++) {
>   ovr = drmModeGetPlane(fd, plane_resources->planes[i]);
>   if (!ovr) {
> @@ -438,10 +438,10 @@ static void dump_planes(void)
>   continue;
>   }
> 
> - printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n",
> + printf("%d\t%d\t%d\t%d,%d\t\t%d,%d\t%-8d\t0x%08x\n",
>  ovr->plane_id, ovr->crtc_id, ovr->fb_id,
>  ovr->crtc_x, ovr->crtc_y, ovr->x, ovr->y,
> -ovr->gamma_size);
> +ovr->gamma_size, ovr->possible_crtcs);
> 
>   if (!ovr->count_formats)
>   continue;
-- 
Regards,

Laurent Pinchart

[PATCH libdrm 5/5] modetest: Reduce the length of the connector type string

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:05 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> Spelling out eDP or DP make for a ridicilously long string which plays
> havoc with formatting. Just say eDP or DP.
> 
> Signed-off-by: Ville Syrj?l? 

Acked-by: Laurent Pinchart 

> ---
>  tests/modetest/modetest.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 27cd2ce..8afd2b1 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -106,11 +106,11 @@ struct type_name connector_type_names[] = {
>   { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
>   { DRM_MODE_CONNECTOR_Component, "component" },
>   { DRM_MODE_CONNECTOR_9PinDIN, "9-pin DIN" },
> - { DRM_MODE_CONNECTOR_DisplayPort, "displayport" },
> + { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
>   { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
>   { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
>   { DRM_MODE_CONNECTOR_TV, "TV" },
> - { DRM_MODE_CONNECTOR_eDP, "embedded displayport" },
> + { DRM_MODE_CONNECTOR_eDP, "eDP" },
>  };
> 
>  type_name_fn(connector_type)
-- 
Regards,

Laurent Pinchart

[PATCH libdrm 2/5] modetest: Fix pitches, somewhat

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:02 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> libkms only has the xrgb format, so we're overallocating the bo by
> quite a lot in some cases. But we still need to get the pitch from the
> libkms since it's the driver that decides how to align it.
> 
> Signed-off-by: Ville Syrj?l? 

Acked-by: Laurent Pinchart 

> ---
>  tests/modetest/buffers.c | 34 ++
>  1 file changed, 10 insertions(+), 24 deletions(-)
> 
> diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> index 6b117b4..7f534a1 100644
> --- a/tests/modetest/buffers.c
> +++ b/tests/modetest/buffers.c
> @@ -948,9 +948,9 @@ create_test_buffer(struct kms_driver *kms, unsigned int
> format, case DRM_FORMAT_VYUY:
>   case DRM_FORMAT_YUYV:
>   case DRM_FORMAT_YVYU:
> - pitches[0] = width * 2;
>   offsets[0] = 0;
>   kms_bo_get_prop(bo, KMS_HANDLE, [0]);
> + kms_bo_get_prop(bo, KMS_PITCH, [0]);
> 
>   planes[0] = virtual;
>   break;
> @@ -959,11 +959,11 @@ create_test_buffer(struct kms_driver *kms, unsigned
> int format, case DRM_FORMAT_NV21:
>   case DRM_FORMAT_NV16:
>   case DRM_FORMAT_NV61:
> - pitches[0] = width;
>   offsets[0] = 0;
>   kms_bo_get_prop(bo, KMS_HANDLE, [0]);
> - pitches[1] = width;
> - offsets[1] = width * height;
> + kms_bo_get_prop(bo, KMS_PITCH, [0]);
> + pitches[1] = pitches[0];
> + offsets[1] = pitches[0] * height;
>   kms_bo_get_prop(bo, KMS_HANDLE, [1]);
> 
>   planes[0] = virtual;
> @@ -971,14 +971,14 @@ create_test_buffer(struct kms_driver *kms, unsigned
> int format, break;
> 
>   case DRM_FORMAT_YVU420:
> - pitches[0] = width;
>   offsets[0] = 0;
>   kms_bo_get_prop(bo, KMS_HANDLE, [0]);
> - pitches[1] = width / 2;
> - offsets[1] = width * height;
> + kms_bo_get_prop(bo, KMS_PITCH, [0]);
> + pitches[1] = pitches[0] / 2;
> + offsets[1] = pitches[0] * height;
>   kms_bo_get_prop(bo, KMS_HANDLE, [1]);
> - pitches[2] = width / 2;
> - offsets[2] = offsets[1] + (width * height) / 4;
> + pitches[2] = pitches[1];
> + offsets[2] = offsets[1] + pitches[1] * height / 2;
>   kms_bo_get_prop(bo, KMS_HANDLE, [2]);
> 
>   planes[0] = virtual;
> @@ -989,29 +989,15 @@ create_test_buffer(struct kms_driver *kms, unsigned
> int format, case DRM_FORMAT_RGB565:
>   case DRM_FORMAT_ARGB1555:
>   case DRM_FORMAT_XRGB1555:
> - pitches[0] = width * 2;
> - offsets[0] = 0;
> - kms_bo_get_prop(bo, KMS_HANDLE, [0]);
> -
> - planes[0] = virtual;
> - break;
> -
>   case DRM_FORMAT_BGR888:
>   case DRM_FORMAT_RGB888:
> - pitches[0] = width * 3;
> - offsets[0] = 0;
> - kms_bo_get_prop(bo, KMS_HANDLE, [0]);
> -
> - planes[0] = virtual;
> - break;
> -
>   case DRM_FORMAT_ARGB:
>   case DRM_FORMAT_BGRA:
>   case DRM_FORMAT_XRGB:
>   case DRM_FORMAT_BGRX:
> - pitches[0] = width * 4;
>   offsets[0] = 0;
>   kms_bo_get_prop(bo, KMS_HANDLE, [0]);
> + kms_bo_get_prop(bo, KMS_PITCH, [0]);
> 
>   planes[0] = virtual;
>   break;
-- 
Regards,

Laurent Pinchart

[PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Wednesday 17 April 2013 22:18:01 ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l? 
> 
> Signed-off-by: Ville Syrj?l? 
> ---
>  tests/modetest/buffers.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
> index 5086381..6b117b4 100644
> --- a/tests/modetest/buffers.c
> +++ b/tests/modetest/buffers.c
> @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
> *planes[3], unsigned int width, #define BLUE  0
> 
>  static void
> -make_pwetty(void *data, int width, int height, int stride)
> +make_pwetty(void *data, int width, int height, int stride, int rgb16)

What about passing the format 4cc instead ?

>  {
>  #ifdef HAVE_CAIRO
>   cairo_surface_t *surface;
> @@ -609,7 +609,7 @@ make_pwetty(void *data, int width, int height, int
> stride) int x, y;
> 
>   surface = cairo_image_surface_create_for_data(data,
> -   CAIRO_FORMAT_ARGB32,
> +   rgb16 ? 
> CAIRO_FORMAT_RGB16_565 : 
CAIRO_FORMAT_ARGB32,
> width, height,
> stride);
>   cr = cairo_create(surface);
> @@ -716,6 +716,7 @@ static void
>  fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
>unsigned int width, unsigned int height, unsigned int stride)
>  {
> + unsigned char *mem_base = mem;
>   unsigned int x, y;
> 
>   for (y = 0; y < height; ++y) {
> @@ -732,6 +733,8 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned
> char *mem, }
>   mem += stride;
>   }
> +
> + make_pwetty(mem_base, width, height, stride, 1);
>  }
> 
>  static void
> @@ -777,7 +780,7 @@ fill_tiles_rgb32(const struct rgb_info *rgb, unsigned
> char *mem, mem += stride;
>   }
> 
> - make_pwetty(mem_base, width, height, stride);
> + make_pwetty(mem_base, width, height, stride, 0);
>  }
> 
>  static void

-- 
Regards,

Laurent Pinchart

[ANNOUNCE] libdrm 2.4.44

[Jerome Glisse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

New release for radeonsi tiling support

Daniel Kurtz (1):
  drm: Fix error message in drmWaitVBlank

Daniel Vetter (1):
  intel-decode: Fix gen6 HIER_DEPTH_BUFFER decoding

Jerome Glisse (3):
  radeon: update radeon_drm.h to kernel last API additions v2
  radeon: add si tiling support v5
  libdrm 2.4.44

Kenneth Graunke (1):
  intel: Fix Haswell CRW PCI IDs.

Laurent Pinchart (2):
  kms: Make libkms.h usable in C++
  kms: Return a negative error code in kms_bo_create()

Maarten Lankhorst (2):
  Remove unused header xf86mm.h.
  makefiles: Add missing headers.

Rob Clark (1):
  freedreno: add shifted reloc

Ville Syrj?l? (6):
  modetest: Fix pitches, somewhat
  modetest: Add support for all 16/32 bpp RGB formats
  modetest: Print possible_crtcs for planes
  modetest: Reduce the length of the connector type string
  modetest: Pass format_info to fill_tiles functions
  modetest: Add YUV420 support and fix YVU420 Cb/Cr ordering

git tag: libdrm-2.4.44

http://dri.freedesktop.org/libdrm/libdrm-2.4.44.tar.bz2

SHA1: d7e0f76d69084a2c8e1353696b990d64b1bc04c8  libdrm-2.4.44.tar.bz2
SHA256: 42b45ad15bb1bc52630a4b37b7afcfaea27e01b3c0b4791ef25d0f7b2456f6a2  
libdrm-2.4.44.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.44.tar.gz
MD5:  205fbaedfab827a874265420d38547f0  libdrm-2.4.44.tar.gz
SHA1: ea3b24bc13c84874878d6d0a7d0f9efbd902ed39  libdrm-2.4.44.tar.gz
SHA256: 38ee219ccda32789879e9918fb2ea8ce418601e947e9cc176fcca2441cdac034  
libdrm-2.4.44.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJRcEp9AAoJEIVJ8RRNBF02vxsP/3QLRyfNx8a+D9ikIsDjguoq
Tr6mLT/2K2HasgasIwCeP0bHDCUFXuvUh89/dwcMpOZ9x6nWVxh4Y5tBLZRBXbEX
H62OHFNXKoNG7Q7AHYjsh6Sz3faoC1t2LM3fl8gafk8SvDXgjpBp927TOyRJmRmE
QWYMNVqmdjiOn2ddrv2Hu7HIiD1nLyJkeU9XZkbWhQhrCZ35V+M1KqtlC8zwDzQn
JRfsgqoMzq6gx6FFW7f97ppy/ffiDOssoGceXO8LvmDSq4ckxIF2Plbw6o94CI+Q
v7NfVaX/8X6dokLiDTgqsqlqMy+SC/PD6Raw85dY+ROaPN0cfdS6FAYT7rrLtV/O
3EYPeHPsM6oEf1X+EIp1ayd/SEQIDVTo2tGHHhxct90fXuIiTWjB80WYRCX5+761
lRxtvghW4gtqrVX5eHqzhYGCbFBwmWrxWY/iudGlm/+/3Li8jlHX4SWb5E2IE6s4
mRQqeyts8zvP9qS0PMv0T2LLdXwlLIruMSvuHRmCS7yFx0HismFptCC620vcJEyN
v8fZ0w2iBflD6K+nNLOq9V2ifwqNjodEQAgDvYugi5gzNS/EV7z1NQk8V5Ot61WJ
YJtTi+0UeTIRbHpYSVpUwzyTUp8mLDO6WGybquN+pweNi3Iw4euCmECMZMKrEdVJ
S3MLD29vjZbQ2fhun72g
=pBE9
-END PGP SIGNATURE-

[PATCH 2/2] drm/radeon: raise UVD clocks only on demand

[Christian König]

From: Christian K?nig 

That not only saves some power, but also solves problems with
older chips where an idle UVD block on higher clocks can
cause problems.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon.h |2 ++
 drivers/gpu/drm/radeon/radeon_cs.c  |4 
 drivers/gpu/drm/radeon/radeon_uvd.c |   30 --
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 18904fb..deafb54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1143,6 +1143,7 @@ struct radeon_uvd {
uint64_tgpu_addr;
atomic_thandles[RADEON_MAX_UVD_HANDLES];
struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
+   struct delayed_work idle_work;
 };

 int radeon_uvd_init(struct radeon_device *rdev);
@@ -1157,6 +1158,7 @@ void radeon_uvd_force_into_uvd_segment(struct radeon_bo 
*rbo);
 void radeon_uvd_free_handles(struct radeon_device *rdev,
 struct drm_file *filp);
 int radeon_uvd_cs_parse(struct radeon_cs_parser *parser);
+void radeon_uvd_note_usage(struct radeon_device *rdev);

 struct r600_audio {
int channels;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index c740707..7e265a5 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -549,6 +549,10 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
r = radeon_cs_handle_lockup(rdev, r);
return r;
}
+
+   if (parser.ring == R600_RING_TYPE_UVD_INDEX)
+   radeon_uvd_note_usage(rdev);
+
r = radeon_cs_ib_chunk(rdev, );
if (r) {
goto out;
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 15580fb..0312a7f 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -36,6 +36,9 @@
 #include "radeon.h"
 #include "r600d.h"

+/* 1 second timeout */
+#define UVD_IDLE_TIMEOUT_MS1000
+
 /* Firmware Names */
 #define FIRMWARE_RV710 "radeon/RV710_uvd.bin"
 #define FIRMWARE_CYPRESS   "radeon/CYPRESS_uvd.bin"
@@ -47,6 +50,8 @@ MODULE_FIRMWARE(FIRMWARE_CYPRESS);
 MODULE_FIRMWARE(FIRMWARE_SUMO);
 MODULE_FIRMWARE(FIRMWARE_TAHITI);

+static void radeon_uvd_idle_work_handler(struct work_struct *work);
+
 int radeon_uvd_init(struct radeon_device *rdev)
 {
struct platform_device *pdev;
@@ -54,6 +59,8 @@ int radeon_uvd_init(struct radeon_device *rdev)
const char *fw_name;
int i, r;

+   INIT_DELAYED_WORK(>uvd.idle_work, radeon_uvd_idle_work_handler);
+
pdev = platform_device_register_simple("radeon_uvd", 0, NULL, 0);
r = IS_ERR(pdev);
if (r) {
@@ -188,8 +195,6 @@ int radeon_uvd_resume(struct radeon_device *rdev)

radeon_bo_unreserve(rdev->uvd.vcpu_bo);

-   radeon_set_uvd_clocks(rdev, 53300, 4);
-
return 0;
 }

@@ -666,3 +671,24 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, 
int ring,

return radeon_uvd_send_msg(rdev, ring, bo, fence);
 }
+
+static void radeon_uvd_idle_work_handler(struct work_struct *work)
+{
+   struct radeon_device *rdev =
+   container_of(work, struct radeon_device, uvd.idle_work.work);
+
+   if (radeon_fence_count_emitted(rdev, R600_RING_TYPE_UVD_INDEX) == 0)
+   radeon_set_uvd_clocks(rdev, 0, 0);
+   else
+   schedule_delayed_work(>uvd.idle_work,
+ msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS));
+}
+
+void radeon_uvd_note_usage(struct radeon_device *rdev)
+{
+   bool set_clocks = !cancel_delayed_work_sync(>uvd.idle_work);
+   set_clocks &= schedule_delayed_work(>uvd.idle_work,
+   
msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS));
+   if (set_clocks)
+   radeon_set_uvd_clocks(rdev, 53300, 4);
+}
-- 
1.7.10.4

[PATCH 1/2] drm/radeon: put UVD PLLs in bypass mode

[Christian König]

From: Christian K?nig 

Just power down the PLL when we get a VCLK or DCLK of zero.
Enabling the bypass mode early should also allow us to
switch UVD clocks on the fly.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/evergreen.c |   22 ++
 drivers/gpu/drm/radeon/rv770.c |   20 +---
 drivers/gpu/drm/radeon/si.c|   22 ++
 3 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 124c193..facfa84 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -189,6 +189,20 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
u32 vclk, u32 dclk)
unsigned vco_freq;
int r;

+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   /* put PLL in bypass mode */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
+
+   if (!vclk || !dclk) {
+   /* keep the Bypass mode, put PLL to sleep */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   return 0;
+   }
+
/* loop through vco from low to high */
for (vco_freq = 125000; vco_freq <= 25; vco_freq += 100) {
unsigned fb_div = vco_freq / rdev->clock.spll.reference_freq * 
16384;
@@ -236,14 +250,6 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
u32 vclk, u32 dclk)

mdelay(1);

-   /* bypass vclk and dclk with bclk */
-   WREG32_P(CG_UPLL_FUNC_CNTL_2,
-   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
-   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
-
-   /* put PLL in bypass mode */
-   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
-
r = evergreen_uvd_send_upll_ctlreq(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 777f537..59065ba 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -100,6 +100,17 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
if (rdev->family == CHIP_RV740)
return evergreen_set_uvd_clocks(rdev, vclk, dclk);

+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   if (!vclk || !dclk) {
+   /* keep the Bypass mode, put PLL to sleep */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   return 0;
+   }
+
/* loop through vco from low to high */
vco_min = max(max(vco_min, vclk), dclk);
for (vco_freq = vco_min; vco_freq <= vco_max; vco_freq += 500) {
@@ -139,16 +150,11 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
}
}

-   /* bypass vclk and dclk with bclk */
-   WREG32_P(CG_UPLL_FUNC_CNTL_2,
-VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
-~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
-
/* set UPLL_FB_DIV to 0x5 */
WREG32_P(CG_UPLL_FUNC_CNTL_3, UPLL_FB_DIV(0x5), ~UPLL_FB_DIV_MASK);

-   /* deassert UPLL_RESET */
-   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_RESET_MASK);
+   /* deassert UPLL_RESET and UPLL_SLEEP */
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~(UPLL_RESET_MASK | UPLL_SLEEP_MASK));

/* assert BYPASS EN and FB_DIV[0] <- ??? why? */
WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index aa2c555..b7d78f2 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4680,6 +4680,20 @@ int si_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
unsigned vco_freq;
int r;

+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   /* put PLL in bypass mode */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
+
+   if (!vclk || !dclk) {
+   /* keep the Bypass mode, put PLL to sleep */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   return 0;
+   }
+
/* loop through vco from low to high */
for (vco_freq = 125000; vco_freq <= 25; vco_freq += 100) {
unsigned fb_div = vco_freq / rdev->clock.spll.reference_freq * 
16384;
@@ -4730,14 +4744,6 @@ int si_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)

mdelay(1);

-   /* 

Standalone DRM application

[David Herrmann]

Hi

On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek  wrote:
> David,
>
> I'm developing a small application that uses libdrm (DRM ioctls) to change
> the
> resolution of a single graphics display and show a framebuffer. I've run
> into
> two problems with this implementation that I'm hoping you can address.
>
>
> 1. Each application is its own process, which is designed to control 1
> graphics
> display. This is unlike X, for instance, which could be configured to grab
> all
> of the displays in the system at once.
>
> Depending on our stackup, there can be as many as 4 displays connected to a
> single graphics card. One process could open /dev/dri/card0 and call
> drmModeSetCrtc() to initialize one of its displays to the requested
> resolution.
> However, whenever a second process calls drmModeSetCrtc() to control a
> second
> display on the same card, it gets -EPERM back from the ioctl.
>
> I've traced this down to the following line in
> linux/drivers/gpu/drm/drm_drv.c:
>
> DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>
> If I remove the DRM_MASTER flag, then my application behaves correctly, and
> 4
> separate processes can then control each individual display on the card
> without
> issue.
>
> My question is, is there any real benefit to restricting drm_mode_setcrtc()
> with DRM_MASTER, or can we lose this flag in order to support
> one-process-per-
> display programs like the above?

Only one open-file can be DRM-Master. And only DRM-Master is allowed
to perform mode-setting. This is to prevent render-clients (like
OpenGL clients) to perform mode-setting, which should be restricted to
the compositor/...

In your scenario, you should share a single open-file between the
processes by passing the FDs to each. Or do all of that in a single
process. There is no way to split CRTCs/connectors between different
nodes or have multiple DRM-Masters on a single node at once. (There is
work going on to allow this, but it will take a while...)

You can acquire/drop DRM-Master via drmSetMaster/drmDropMaster.

>
> 2. My application has the design requirement that "screen 1" always refers
> to
> the card that was initialized by the PC BIOS for bootup. This is the same
> card
> that the Linux Console framebuffer will come up on by default, and therefore
> extra processing is required to handle VT switches (e.g. pause the display,
> restore original CRTC mode, etc.)
>
> Depending on the "Boot Display First [Onboard] or [PCI Slot]" option in the
> BIOS, this might mean either /dev/dri/card0 or /dev/dri/card1 becomes the
> default VGA card, as set by the vga_set_default_device() call in
> arch/x86/pci/fixup.c.
>
> Is there a way in userspace to identify which card# is the default card? Or
> alternatively, is there some way to get the underlying PCI bus/slot ID from
> a
> /dev/dri/card# device.

If your DRM card is a PCI device, you can use the sysfs "boot_vga"
attribute of the parent PCI device.
(/sys/class/drm/card0/device/boot_vga)

Regards
David

Radeon lockup on 3.8.5-201.fc18.x86_64

[Andy Lutomirski]

On Mon, Apr 8, 2013 at 7:01 AM, Alex Deucher  wrote:
> On Fri, Apr 5, 2013 at 5:11 PM, Andy Lutomirski  
> wrote:
>> Every day or so, I'll click something and my screens go blank for a
>> second or two.  dmesg complains about a lockup, and afterwards
>> everything is painfully slow.  (Even switching focus to other emacs
>> windows takes a second or two.)  Once this happens, if I restart X, I
>> get a blank screen, although the mouse still works and I can switch
>> VTs and use the console.
>
> Try disabling hyperZ.  Set env var R600_HYPERZ=0 (mesa 9.1) or
> R600_DEBUG=nohyperz (mesa git).

It lasted longer.  I have both of those environment variables set on
the Xorg process but not on clients.  Do  I need it everywhere?

The failure was:

[847785.776441] radeon :08:00.0: GPU lockup CP stall for more than 10654msec
[847785.776449] radeon :08:00.0: GPU lockup (waiting for
0x90f8 last fence id 0x90f7)
[847785.777542] radeon :08:00.0: Saved 71 dwords of commands on ring 0.
[847785.777548] radeon :08:00.0: GPU softreset: 0x0007
[847785.789844] radeon :08:00.0:   GRBM_STATUS   = 0xA0003828
[847785.789847] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
[847785.789850] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
[847785.789852] radeon :08:00.0:   SRBM_STATUS   = 0x200080C0
[847785.789855] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[847785.789857] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[847785.789860] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x0004
[847785.789862] radeon :08:00.0:   R_008680_CP_STAT  = 0x80008647
[847785.789864] radeon :08:00.0:   GRBM_SOFT_RESET=0x7F6B
[847785.789919] radeon :08:00.0:   GRBM_STATUS   = 0x3828
[847785.789922] radeon :08:00.0:   GRBM_STATUS_SE0   = 0x0007
[847785.789924] radeon :08:00.0:   GRBM_STATUS_SE1   = 0x0007
[847785.789927] radeon :08:00.0:   SRBM_STATUS   = 0x200080C0
[847785.789929] radeon :08:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[847785.789932] radeon :08:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[847785.789934] radeon :08:00.0:   R_00867C_CP_BUSY_STAT = 0x
[847785.789937] radeon :08:00.0:   R_008680_CP_STAT  = 0x
[847785.789941] radeon :08:00.0:   R_00D034_DMA_STATUS_REG   = 0x04483106
[847785.789997] radeon :08:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[847785.807356] radeon :08:00.0: GPU reset succeeded, trying to resume
[847785.825791] [drm] probing gen 2 caps for device 8086:1d1a = 2/0
[847785.825797] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[847785.832851] [drm] PCIE GART of 512M enabled (table at 0x0004).
[847785.832993] radeon :08:00.0: WB enabled
[847785.832996] radeon :08:00.0: fence driver on ring 0 use gpu
addr 0x4c00 and cpu addr 0x88044295bc00
[847785.832997] radeon :08:00.0: fence driver on ring 3 use gpu
addr 0x4c0c and cpu addr 0x88044295bc0c
[847785.849454] [drm] ring test on 0 succeeded in 2 usecs
[847785.849523] [drm] ring test on 3 succeeded in 1 usecs
[847785.849604] [drm] ib test on ring 0 succeeded in 0 usecs
[847785.849681] [drm] ib test on ring 3 succeeded in 1 usecs

--Andy

[PATCH] drm/exynos: do not use generic flags to dumb

[Inki Dae]

This patch removes the use of dumb flags from driver.

As Dave pointed out, the dumb flags are not driver specific
so this should be removed from driver.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 0e6fe00..cf4543f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -682,7 +682,8 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
args->pitch = args->width * ((args->bpp + 7) / 8);
args->size = args->pitch * args->height;

-   exynos_gem_obj = exynos_drm_gem_create(dev, args->flags, args->size);
+   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
+   EXYNOS_BO_WC, args->size);
if (IS_ERR(exynos_gem_obj))
return PTR_ERR(exynos_gem_obj);

-- 
1.7.5.4

abuse of dumb ioctls in exynos

[Inki Dae]

Hi, Dave


2013/4/18 Dave Airlie 

> It appears exynos is passing the generic flags from the dumb ioctls
> straight into the the GEM creation code.
>
> The dumb flags are NOT driver specific, and are NOT to be used in this
> fashion. Please remove this use of the flags from your driver.
>
>

Got it. I will post one patch to it soon.

Thanks for your pointing out.
Inki Dae



> I was going to add one new flag to the interface for SCANOUT vs CURSOR
> for some drivers.
>
> Dave.
> ___
> 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/20130418/e313c476/attachment.html>

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Tomi Valkeinen]

On 2013-04-18 12:09, Tomi Valkeinen wrote:
> On 2013-04-18 11:37, Christoph Fritz wrote:

>> With linux-next this patch breaks compiling here because DPI now depends
>> on DSI - but my omap3 board here doesn't use DSI at all:
>>
>> drivers/video/omap2/dss/dpi.c: In function ?dpi_calc_pll_cb?:
>> drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
>> ?dsi_hsdiv_calc?
>> drivers/video/omap2/dss/dpi.c: In function ?dpi_dsi_clk_calc?:
>> drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
>> ?dsi_get_pll_clkin?
>> drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
>> ?dsi_pll_calc?
>>
>> Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be 
>> want to merge it?
> 
> Thanks for reporting this. We shouldn't make DPI depend on DSI. We
> should make dummy functions for the above when DSI is not enabled so
> that DPI compiles. I'll make a fix.

Patch below. Can you try it out? It works for me on Panda.

 Tomi

[PATCH] OMAPDSS: DPI: fix compilation if DSI not compiled in

[Tomi Valkeinen]

Commit 100c826235793345efe06b3558cc9d36166b1e26 (OMAPDSS: DPI: use new
clock calculation code) breaks dpi.c compilation if DSI is not enabled
in the kernel configuration.

Fix compilation by adding dummy inline functions for the ones that dpi.c
references. The functions will never be called, as dpi.c knows that
there is no DSI device available.

Signed-off-by: Tomi Valkeinen 
---
 drivers/video/omap2/dss/dss.h |   31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index faaf358..8475893 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -277,6 +277,12 @@ int sdi_init_platform_driver(void) __init;
 void sdi_uninit_platform_driver(void) __exit;

 /* DSI */
+
+typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
+   unsigned long pll, void *data);
+typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
+   void *data);
+
 #ifdef CONFIG_OMAP2_DSS_DSI

 struct dentry;
@@ -295,10 +301,6 @@ u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);

 unsigned long dsi_get_pll_clkin(struct platform_device *dsidev);

-typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
-   unsigned long pll, void *data);
-typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
-   void *data);
 bool dsi_hsdiv_calc(struct platform_device *dsidev, unsigned long pll,
unsigned long out_min, dsi_hsdiv_calc_func func, void *data);
 bool dsi_pll_calc(struct platform_device *dsidev, unsigned long clkin,
@@ -358,6 +360,27 @@ static inline struct platform_device 
*dsi_get_dsidev_from_id(int module)
 {
return NULL;
 }
+
+static inline unsigned long dsi_get_pll_clkin(struct platform_device *dsidev)
+{
+   return 0;
+}
+
+static inline bool dsi_hsdiv_calc(struct platform_device *dsidev,
+   unsigned long pll, unsigned long out_min,
+   dsi_hsdiv_calc_func func, void *data)
+{
+   return false;
+}
+
+static inline bool dsi_pll_calc(struct platform_device *dsidev,
+   unsigned long clkin,
+   unsigned long pll_min, unsigned long pll_max,
+   dsi_pll_calc_func func, void *data)
+{
+   return false;
+}
+
 #endif

 /* DPI */
-- 
1.7.10.4



-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130418/a6ed2ab5/attachment.pgp>

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Christoph Fritz]

On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote:
> On 2013-04-18 12:09, Tomi Valkeinen wrote:
> > On 2013-04-18 11:37, Christoph Fritz wrote:
> 
> >> With linux-next this patch breaks compiling here because DPI now depends
> >> on DSI - but my omap3 board here doesn't use DSI at all:
> >>
> >> drivers/video/omap2/dss/dpi.c: In function ?dpi_calc_pll_cb?:
> >> drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
> >> ?dsi_hsdiv_calc?
> >> drivers/video/omap2/dss/dpi.c: In function ?dpi_dsi_clk_calc?:
> >> drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
> >> ?dsi_get_pll_clkin?
> >> drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
> >> ?dsi_pll_calc?
> >>
> >> Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be 
> >> want to merge it?
> > 
> > Thanks for reporting this. We shouldn't make DPI depend on DSI. We
> > should make dummy functions for the above when DSI is not enabled so
> > that DPI compiles. I'll make a fix.
> 
> Patch below. Can you try it out? It works for me on Panda.

Thanks, it compiles here fine too.

and while booting I'm now getting as with 3.9-rc:
[0.409729] OMAP DSS rev 2.0
[0.410980] omapdss DPI error: can't get VDDS_DSI regulator
[0.410980] omapdss DPI error: device ips-056t init failed: -517

But here with linux-next (in contrast to 3.9-rc) removing all regulator
dependencies from drivers/video/omap2/dss/dpi.c does not make the trick.
The display stays dark :-( ...

 Thanks
  -- Christoph

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Tomi Valkeinen]

On 2013-04-18 11:37, Christoph Fritz wrote:
> Hi Tomi
> 
> On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
>> Tomi Valkeinen (38):
>>   OMAPDSS: add fields to panels' platform data
>>   OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev
>>   OMAPDSS: HDMI: remove HDMI clk divisors from dssdev
>>   OMAPDSS: DPI: remove omap_dss_device uses
>>   OMAPDSS: DSI: remove omap_dss_device uses
>>   OMAPDSS: Taal: remove multi-panel support
>>   OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync
>>   OMAPDSS: add missing export for omap_dss_get_output()
>>   OMAPDSS: HDMI: init output earlier
>>   OMAPDSS: add output->name
>>   OMAPDSS: add output->dispc_channel
>>   OMAPDSS: DSI: delay dispc initialization
>>   OMAPDSS: DSI: fix DSI channel source initialization
>>   OMAPDSS: Taal: remove rotate & mirror support
>>   OMAPDSS: DPI: fix dpi_get_dsidev() for omap5
>>   OMAPDSS: DISPC: store core clk rate
>>   OMAPDSS: DSI: fix wrong unsigned long long use
>>   OMAPDSS: DSI: simplify dsi configuration
>>   OMAPDSS: DSI: get line buffer size at probe
>>   OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode
>>   OMAPDSS: DSI remove unneeded clk source setup code
>>   OMAPDSS: DISPC: add new clock calculation code
>>   OMAPDSS: DSS: add new clock calculation code
>>   OMAPDSS: DSI: add new clock calculation code
>>   OMAPDSS: SDI: use new clock calculation code
>>   OMAPDSS: DPI: use new clock calculation code
> 
> With linux-next this patch breaks compiling here because DPI now depends
> on DSI - but my omap3 board here doesn't use DSI at all:
> 
> drivers/video/omap2/dss/dpi.c: In function ?dpi_calc_pll_cb?:
> drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
> ?dsi_hsdiv_calc?
> drivers/video/omap2/dss/dpi.c: In function ?dpi_dsi_clk_calc?:
> drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
> ?dsi_get_pll_clkin?
> drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
> ?dsi_pll_calc?
> 
> Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want 
> to merge it?

Thanks for reporting this. We shouldn't make DPI depend on DSI. We
should make dummy functions for the above when DSI is not enabled so
that DPI compiles. I'll make a fix.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130418/25f26f61/attachment.pgp>

[PATCH 3/3] drm/radeon: switch audio handling to use callbacks

[alexdeuc...@gmail.com]

From: Alex Deucher 

Register audio callbacks for asic where we support
audio.  Cleans up the code and makes it easier to
add support for newer asics.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_encoders.c |   17 ++---
 drivers/gpu/drm/radeon/evergreen_hdmi.c|   17 +
 drivers/gpu/drm/radeon/r600_hdmi.c |  109 +---
 drivers/gpu/drm/radeon/radeon.h|   10 ++--
 drivers/gpu/drm/radeon/radeon_asic.c   |   18 +
 drivers/gpu/drm/radeon/radeon_asic.h   |4 +
 6 files changed, 87 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 4552d4a..44a7da6 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2150,13 +2150,10 @@ radeon_atom_encoder_mode_set(struct drm_encoder 
*encoder,
atombios_apply_encoder_quirks(encoder, adjusted_mode);

if (atombios_get_encoder_mode(encoder) == ATOM_ENCODER_MODE_HDMI) {
-   r600_hdmi_enable(encoder);
-   if (ASIC_IS_DCE6(rdev))
-   ; /* TODO (use pointers instead of if-s?) */
-   else if (ASIC_IS_DCE4(rdev))
-   evergreen_hdmi_setmode(encoder, adjusted_mode);
-   else
-   r600_hdmi_setmode(encoder, adjusted_mode);
+   if (rdev->asic->display.hdmi_enable)
+   radeon_hdmi_enable(rdev, encoder, true);
+   if (rdev->asic->display.hdmi_setmode)
+   radeon_hdmi_setmode(rdev, encoder, adjusted_mode);
}
 }

@@ -2413,8 +2410,10 @@ static void radeon_atom_encoder_disable(struct 
drm_encoder *encoder)

 disable_done:
if (radeon_encoder_is_digital(encoder)) {
-   if (atombios_get_encoder_mode(encoder) == 
ATOM_ENCODER_MODE_HDMI)
-   r600_hdmi_disable(encoder);
+   if (atombios_get_encoder_mode(encoder) == 
ATOM_ENCODER_MODE_HDMI) {
+   if (rdev->asic->display.hdmi_enable)
+   radeon_hdmi_enable(rdev, encoder, false);
+   }
dig = radeon_encoder->enc_priv;
dig->dig_encoder = -1;
}
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 9fc22ee..e32fd2c 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -219,3 +219,20 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
WREG32(AFMT_RAMP_CONTROL2 + offset, 0x0001);
WREG32(AFMT_RAMP_CONTROL3 + offset, 0x0001);
 }
+
+void evergreen_hdmi_enable(struct drm_encoder *encoder, bool enable)
+{
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+
+   /* Silent, r600_hdmi_enable will raise WARN for us */
+   if (enable && dig->afmt->enabled)
+   return;
+   if (!enable && !dig->afmt->enabled)
+   return;
+
+   dig->afmt->enabled = enable;
+
+   DRM_DEBUG("%sabling HDMI interface @ 0x%04X for encoder 0x%x\n",
+ enable ? "En" : "Dis", dig->afmt->offset, 
radeon_encoder->encoder_id);
+}
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 62721bf..2e15888 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -439,112 +439,73 @@ void r600_hdmi_update_audio_settings(struct drm_encoder 
*encoder)
 /*
  * enable the HDMI engine
  */
-void r600_hdmi_enable(struct drm_encoder *encoder)
+void r600_hdmi_enable(struct drm_encoder *encoder, bool enable)
 {
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
-   uint32_t offset;
-   u32 hdmi;
-
-   if (ASIC_IS_DCE6(rdev))
-   return;
+   u32 hdmi = HDMI0_ERROR_ACK;

/* Silent, r600_hdmi_enable will raise WARN for us */
-   if (dig->afmt->enabled)
+   if (enable && dig->afmt->enabled)
+   return;
+   if (!enable && !dig->afmt->enabled)
return;
-   offset = dig->afmt->offset;

/* Older chipsets require setting HDMI and routing manually */
-   if (ASIC_IS_DCE2(rdev) && !ASIC_IS_DCE3(rdev)) {
-   hdmi = HDMI0_ERROR_ACK | HDMI0_ENABLE;
+   if (!ASIC_IS_DCE3(rdev)) {
+   if (enable)
+   hdmi |= HDMI0_ENABLE;
switch (radeon_encoder->encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
-   WREG32_OR(AVIVO_TMDSA_CNTL, AVIVO_TMDSA_CNTL_HDMI_EN);
-   

[PATCH 2/3] drm/radeon: clean up audio dto programming

[alexdeuc...@gmail.com]

From: Alex Deucher 

Split into DCE2/3 and DCE4/5 variants. Still todo is to
calculate the DTO dividers properly.  Add proper formula
to the comments.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen_hdmi.c |   26 +-
 drivers/gpu/drm/radeon/r600_audio.c |   59 ---
 drivers/gpu/drm/radeon/r600_hdmi.c  |   26 +-
 drivers/gpu/drm/radeon/radeon_asic.h|1 -
 4 files changed, 50 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 380933b..9fc22ee 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -85,6 +85,30 @@ static void evergreen_hdmi_update_avi_infoframe(struct 
drm_encoder *encoder,
frame[0xC] | (frame[0xD] << 8));
 }

+static void evergreen_audio_set_dto(struct drm_encoder *encoder, u32 clock)
+{
+   struct drm_device *dev = encoder->dev;
+   struct radeon_device *rdev = dev->dev_private;
+   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
+   struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
+   u32 base_rate = 48000;
+
+   if (!dig || !dig->afmt)
+   return;
+
+   /* XXX: properly calculate this */
+   /* XXX two dtos; generally use dto0 for hdmi */
+   /* Express [24MHz / target pixel clock] as an exact rational
+* number (coefficient of two integer numbers.  DCCG_AUDIO_DTOx_PHASE
+* is the numerator, DCCG_AUDIO_DTOx_MODULE is the denominator
+*/
+   WREG32(DCCG_AUDIO_DTO0_PHASE, (base_rate*50) & 0xff);
+   WREG32(DCCG_AUDIO_DTO0_MODULE, (clock*100) & 0xff);
+   WREG32(DCCG_AUDIO_DTO_SOURCE, 
DCCG_AUDIO_DTO0_SOURCE_SEL(radeon_crtc->crtc_id));
+}
+
+
 /*
  * update the info frames with the data from the current display mode
  */
@@ -104,7 +128,7 @@ void evergreen_hdmi_setmode(struct drm_encoder *encoder, 
struct drm_display_mode
return;
offset = dig->afmt->offset;

-   r600_audio_set_clock(encoder, mode->clock);
+   evergreen_audio_set_dto(encoder, mode->clock);

WREG32(HDMI_VBI_PACKET_CONTROL + offset,
   HDMI_NULL_SEND); /* send null packets when required */
diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index 72561e4..c92eb86 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -181,65 +181,6 @@ int r600_audio_init(struct radeon_device *rdev)
 }

 /*
- * atach the audio codec to the clock source of the encoder
- */
-void r600_audio_set_clock(struct drm_encoder *encoder, int clock)
-{
-   struct drm_device *dev = encoder->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
-   struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
-   struct radeon_crtc *radeon_crtc = to_radeon_crtc(encoder->crtc);
-   int base_rate = 48000;
-
-   switch (radeon_encoder->encoder_id) {
-   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
-   case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
-   WREG32_P(R600_AUDIO_TIMING, 0, ~0x301);
-   break;
-   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
-   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
-   case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
-   case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
-   WREG32_P(R600_AUDIO_TIMING, 0x100, ~0x301);
-   break;
-   default:
-   dev_err(rdev->dev, "Unsupported encoder type 0x%02X\n",
- radeon_encoder->encoder_id);
-   return;
-   }
-
-   if (ASIC_IS_DCE4(rdev)) {
-   /* TODO: other PLLs? */
-   WREG32(EVERGREEN_AUDIO_PLL1_MUL, base_rate * 10);
-   WREG32(EVERGREEN_AUDIO_PLL1_DIV, clock * 10);
-   WREG32(EVERGREEN_AUDIO_PLL1_UNK, 0x0071);
-
-   /* Select DTO source */
-   WREG32(0x5ac, radeon_crtc->crtc_id);
-   } else {
-   switch (dig->dig_encoder) {
-   case 0:
-   WREG32(R600_AUDIO_PLL1_MUL, base_rate * 50);
-   WREG32(R600_AUDIO_PLL1_DIV, clock * 100);
-   WREG32(R600_AUDIO_CLK_SRCSEL, 0);
-   break;
-
-   case 1:
-   WREG32(R600_AUDIO_PLL2_MUL, base_rate * 50);
-   WREG32(R600_AUDIO_PLL2_DIV, clock * 100);
-   WREG32(R600_AUDIO_CLK_SRCSEL, 1);
-   break;
-   default:
-   dev_err(rdev->dev,
-   "Unsupported DIG on encoder 0x%02X\n",
-   radeon_encoder->encoder_id);
-   

[PATCH 1/3] drm/radeon: clean up audio supported check

[alexdeuc...@gmail.com]

From: Alex Deucher 

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/r600_audio.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_audio.c 
b/drivers/gpu/drm/radeon/r600_audio.c
index cb03fe2..72561e4 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -57,10 +57,7 @@ static bool radeon_dig_encoder(struct drm_encoder *encoder)
  */
 static int r600_audio_chipset_supported(struct radeon_device *rdev)
 {
-   return (rdev->family >= CHIP_R600 && !ASIC_IS_DCE6(rdev))
-   || rdev->family == CHIP_RS600
-   || rdev->family == CHIP_RS690
-   || rdev->family == CHIP_RS740;
+   return ASIC_IS_DCE2(rdev) && !ASIC_IS_DCE6(rdev);
 }

 struct r600_audio r600_audio_status(struct radeon_device *rdev)
-- 
1.7.7.5

[PATCH 0/3] Additional radeon audio cleanups

[alexdeuc...@gmail.com]

From: Alex Deucher 

This set of patches does some additional audio cleanups
and switches to per asic callbacks for audio.

Alex Deucher (3):
  drm/radeon: clean up audio supported check
  drm/radeon: clean up audio dto programming
  drm/radeon: switch audio handling to use callbacks

 drivers/gpu/drm/radeon/atombios_encoders.c |   17 ++--
 drivers/gpu/drm/radeon/evergreen_hdmi.c|   43 +-
 drivers/gpu/drm/radeon/r600_audio.c|   64 +-
 drivers/gpu/drm/radeon/r600_hdmi.c |  135 ---
 drivers/gpu/drm/radeon/radeon.h|   10 +-
 drivers/gpu/drm/radeon/radeon_asic.c   |   18 
 drivers/gpu/drm/radeon/radeon_asic.h   |5 +-
 7 files changed, 138 insertions(+), 154 deletions(-)

-- 
1.7.7.5

[RFC 06/10] video: ARM CLCD: Add DT & CDF support

[Russell King - ARM Linux]

On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
> +#if defined(CONFIG_OF)
> +static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
> + struct display_entity_interface_params *params)
> +{
> + int r = params->p.tft_parallel.r_bits;
> + int g = params->p.tft_parallel.g_bits;
> + int b = params->p.tft_parallel.b_bits;
> +
> + /* Bypass pixel clock divider, data output on the falling edge */
> + panel->tim2 = TIM2_BCD | TIM2_IPC;
> +
> + /* TFT display, vert. comp. interrupt at the start of the back porch */
> + panel->cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
> +
> + if (params->p.tft_parallel.r_b_swapped)
> + panel->cntl |= CNTL_BGR;

NAK.  Do not set this explicitly.  Note the driver talks about this being
"the old way" - this should not be used with the panel capabilities - and
in fact it will be overwritten.

Instead, you need to encode this into the capabilities by masking the
below with CLCD_CAP_RGB or CLCD_CAP_BGR depending on the ordering.

[PATCH 2/2] drm/radeon: fix alignment of UVD fence

[Christian König]

From: Christian K?nig 

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_fence.c |7 +++
 drivers/gpu/drm/radeon/radeon_uvd.c   |2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 82fe183..1a699ce 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -776,10 +776,9 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)

} else {
/* put fence directly behind firmware */
-   rdev->fence_drv[ring].cpu_addr = rdev->uvd.cpu_addr +
-rdev->uvd_fw->size;
-   rdev->fence_drv[ring].gpu_addr = rdev->uvd.gpu_addr +
-rdev->uvd_fw->size;
+   index = ALIGN(rdev->uvd_fw->size, 8);
+   rdev->fence_drv[ring].cpu_addr = rdev->uvd.cpu_addr + 
index;
+   rdev->fence_drv[ring].gpu_addr = rdev->uvd.gpu_addr + 
index;
}

} else {
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 2fb4d6c..15580fb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -107,7 +107,7 @@ int radeon_uvd_init(struct radeon_device *rdev)

platform_device_unregister(pdev);

-   bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 4) +
+   bo_size = RADEON_GPU_PAGE_ALIGN(rdev->uvd_fw->size + 8) +
  RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE;
r = radeon_bo_create(rdev, bo_size, PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM, NULL, >uvd.vcpu_bo);
-- 
1.7.10.4

[PATCH 1/2] drm/radeon: cleanup UVD address checks

[Christian König]

From: Christian K?nig 

Message and feedback buffers must be at start of
VRAM, not at start of address space.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_uvd.c |   26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 30a9460..2fb4d6c 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -415,24 +415,26 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
return -EINVAL;
}

-   if (cmd == 0) {
-   if (end & 0xF000) {
-   DRM_ERROR("msg buffer %LX-%LX out of 256MB segment!\n",
- start, end);
-   return -EINVAL;
-   }
-
-   r = radeon_uvd_cs_msg(p, reloc->robj, offset, buf_sizes);
-   if (r)
-   return r;
+   if ((start >> 28) != (end >> 28)) {
+   DRM_ERROR("reloc %LX-%LX crossing 256MB boundary!\n",
+ start, end);
+   return -EINVAL;
}

-   if ((start & 0xF000) != (end & 0xF000)) {
-   DRM_ERROR("reloc %LX-%LX crossing 256MB boundary!\n",
+   /* TODO: is this still necessary on NI+ ? */
+   if ((cmd == 0 || cmd == 0x3) &&
+   (start >> 28) != (p->rdev->uvd.gpu_addr >> 28)) {
+   DRM_ERROR("msg/fb buffer %LX-%LX out of 256MB segment!\n",
  start, end);
return -EINVAL;
}

+   if (cmd == 0) {
+   r = radeon_uvd_cs_msg(p, reloc->robj, offset, buf_sizes);
+   if (r)
+   return r;
+   }
+
return 0;
 }

-- 
1.7.10.4

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Christoph Fritz]

Hi Tomi

On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
> Tomi Valkeinen (38):
>   OMAPDSS: add fields to panels' platform data
>   OMAPDSS: DSI: remove DSI & DISPC clk divisors from dssdev
>   OMAPDSS: HDMI: remove HDMI clk divisors from dssdev
>   OMAPDSS: DPI: remove omap_dss_device uses
>   OMAPDSS: DSI: remove omap_dss_device uses
>   OMAPDSS: Taal: remove multi-panel support
>   OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync
>   OMAPDSS: add missing export for omap_dss_get_output()
>   OMAPDSS: HDMI: init output earlier
>   OMAPDSS: add output->name
>   OMAPDSS: add output->dispc_channel
>   OMAPDSS: DSI: delay dispc initialization
>   OMAPDSS: DSI: fix DSI channel source initialization
>   OMAPDSS: Taal: remove rotate & mirror support
>   OMAPDSS: DPI: fix dpi_get_dsidev() for omap5
>   OMAPDSS: DISPC: store core clk rate
>   OMAPDSS: DSI: fix wrong unsigned long long use
>   OMAPDSS: DSI: simplify dsi configuration
>   OMAPDSS: DSI: get line buffer size at probe
>   OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode
>   OMAPDSS: DSI remove unneeded clk source setup code
>   OMAPDSS: DISPC: add new clock calculation code
>   OMAPDSS: DSS: add new clock calculation code
>   OMAPDSS: DSI: add new clock calculation code
>   OMAPDSS: SDI: use new clock calculation code
>   OMAPDSS: DPI: use new clock calculation code

With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my omap3 board here doesn't use DSI at all:

drivers/video/omap2/dss/dpi.c: In function ?dpi_calc_pll_cb?:
drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
?dsi_hsdiv_calc?
drivers/video/omap2/dss/dpi.c: In function ?dpi_dsi_clk_calc?:
drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
?dsi_get_pll_clkin?
drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
?dsi_pll_calc?

Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want 
to merge it?

From: Christoph Fritz 
Date: Thu, 18 Apr 2013 10:26:54 +0200
Subject: [PATCH] OMAPDSS: DPI: add dependency to DSI

A dependency from DPI to DSI is introduced by commit 100c82623
"OMAPDSS: DPI: use new clock calculation code".
This patch adds the dependency also on Kconfig-Level.

Signed-off-by: Christoph Fritz 
---
 drivers/video/omap2/dss/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index cb0f145..b4211c5 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -36,6 +36,7 @@ config OMAP2_DSS_COLLECT_IRQ_STATS
 config OMAP2_DSS_DPI
bool "DPI support"
default y
+   select OMAP2_DSS_DSI
help
  DPI Interface. This is the Parallel Display Interface.

-- 
1.7.10.4

libdrm release next week ?

[Jerome Glisse]

On Fri, Apr 12, 2013 at 10:06 AM, Laurent Pinchart <
laurent.pinchart at ideasonboard.com> wrote:

> Hi Jerome,
>
> On Friday 12 April 2013 09:51:04 Jerome Glisse wrote:
> > Hi,
> >
> > I would like to make a libdrm release sometime next week, does anybody
> have
> > anything they want to include ?
>
> kms: Return a negative error code in kms_bo_create()
> kms: Make libkms.h usable in C++
>
> would be nice.
>
> --
> Regards,
>
> Laurent Pinchart
>
>
If no objection i gonna make a release latter today. Above patch are
included.

Cheers,
Jerome
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130418/a24c5cbd/attachment.html>

[PATCH 1/2] drm/radeon: put UVD PLLs in bypass mode

[Alex Deucher]

On Thu, Apr 18, 2013 at 9:25 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> Just power down the PLL when we get a VCLK or DCLK of zero.
> Enabling the bypass mode early should also allow us to
> switch UVD clocks on the fly.
>
> Signed-off-by: Christian K?nig 

Looks good.  both applied.

Alex

> ---
>  drivers/gpu/drm/radeon/evergreen.c |   22 ++
>  drivers/gpu/drm/radeon/rv770.c |   20 +---
>  drivers/gpu/drm/radeon/si.c|   22 ++
>  3 files changed, 41 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 124c193..facfa84 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -189,6 +189,20 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
> u32 vclk, u32 dclk)
> unsigned vco_freq;
> int r;
>
> +   /* bypass vclk and dclk with bclk */
> +   WREG32_P(CG_UPLL_FUNC_CNTL_2,
> +   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
> +   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
> +
> +   /* put PLL in bypass mode */
> +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
> ~UPLL_BYPASS_EN_MASK);
> +
> +   if (!vclk || !dclk) {
> +   /* keep the Bypass mode, put PLL to sleep */
> +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, 
> ~UPLL_SLEEP_MASK);
> +   return 0;
> +   }
> +
> /* loop through vco from low to high */
> for (vco_freq = 125000; vco_freq <= 25; vco_freq += 100) {
> unsigned fb_div = vco_freq / rdev->clock.spll.reference_freq 
> * 16384;
> @@ -236,14 +250,6 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
> u32 vclk, u32 dclk)
>
> mdelay(1);
>
> -   /* bypass vclk and dclk with bclk */
> -   WREG32_P(CG_UPLL_FUNC_CNTL_2,
> -   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
> -   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
> -
> -   /* put PLL in bypass mode */
> -   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
> ~UPLL_BYPASS_EN_MASK);
> -
> r = evergreen_uvd_send_upll_ctlreq(rdev);
> if (r)
> return r;
> diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
> index 777f537..59065ba 100644
> --- a/drivers/gpu/drm/radeon/rv770.c
> +++ b/drivers/gpu/drm/radeon/rv770.c
> @@ -100,6 +100,17 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 
> vclk, u32 dclk)
> if (rdev->family == CHIP_RV740)
> return evergreen_set_uvd_clocks(rdev, vclk, dclk);
>
> +   /* bypass vclk and dclk with bclk */
> +   WREG32_P(CG_UPLL_FUNC_CNTL_2,
> +VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
> +~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
> +
> +   if (!vclk || !dclk) {
> +   /* keep the Bypass mode, put PLL to sleep */
> +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, 
> ~UPLL_SLEEP_MASK);
> +   return 0;
> +   }
> +
> /* loop through vco from low to high */
> vco_min = max(max(vco_min, vclk), dclk);
> for (vco_freq = vco_min; vco_freq <= vco_max; vco_freq += 500) {
> @@ -139,16 +150,11 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, 
> u32 vclk, u32 dclk)
> }
> }
>
> -   /* bypass vclk and dclk with bclk */
> -   WREG32_P(CG_UPLL_FUNC_CNTL_2,
> -VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
> -~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
> -
> /* set UPLL_FB_DIV to 0x5 */
> WREG32_P(CG_UPLL_FUNC_CNTL_3, UPLL_FB_DIV(0x5), 
> ~UPLL_FB_DIV_MASK);
>
> -   /* deassert UPLL_RESET */
> -   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_RESET_MASK);
> +   /* deassert UPLL_RESET and UPLL_SLEEP */
> +   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~(UPLL_RESET_MASK | UPLL_SLEEP_MASK));
>
> /* assert BYPASS EN and FB_DIV[0] <- ??? why? */
> WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
> ~UPLL_BYPASS_EN_MASK);
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index aa2c555..b7d78f2 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -4680,6 +4680,20 @@ int si_set_uvd_clocks(struct radeon_device *rdev, u32 
> vclk, u32 dclk)
> unsigned vco_freq;
> int r;
>
> +   /* bypass vclk and dclk with bclk */
> +   WREG32_P(CG_UPLL_FUNC_CNTL_2,
> +   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
> +   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
> +
> +   /* put PLL in bypass mode */
> +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
> ~UPLL_BYPASS_EN_MASK);
> +
> +   if (!vclk || !dclk) {
> +   /* keep the Bypass mode, put PLL to sleep */
> +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, 
> ~UPLL_SLEEP_MASK);
> +   return 0;
> +   }
> +
>

[PATCH 1/2] drm/radeon: cleanup UVD address checks

[Alex Deucher]

On Thu, Apr 18, 2013 at 4:42 AM, Christian K?nig
 wrote:
> From: Christian K?nig 
>
> Message and feedback buffers must be at start of
> VRAM, not at start of address space.
>
> Signed-off-by: Christian K?nig 

Looks good.  Both applied.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_uvd.c |   26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 30a9460..2fb4d6c 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -415,24 +415,26 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser 
> *p,
> return -EINVAL;
> }
>
> -   if (cmd == 0) {
> -   if (end & 0xF000) {
> -   DRM_ERROR("msg buffer %LX-%LX out of 256MB 
> segment!\n",
> - start, end);
> -   return -EINVAL;
> -   }
> -
> -   r = radeon_uvd_cs_msg(p, reloc->robj, offset, buf_sizes);
> -   if (r)
> -   return r;
> +   if ((start >> 28) != (end >> 28)) {
> +   DRM_ERROR("reloc %LX-%LX crossing 256MB boundary!\n",
> + start, end);
> +   return -EINVAL;
> }
>
> -   if ((start & 0xF000) != (end & 0xF000)) {
> -   DRM_ERROR("reloc %LX-%LX crossing 256MB boundary!\n",
> +   /* TODO: is this still necessary on NI+ ? */
> +   if ((cmd == 0 || cmd == 0x3) &&
> +   (start >> 28) != (p->rdev->uvd.gpu_addr >> 28)) {
> +   DRM_ERROR("msg/fb buffer %LX-%LX out of 256MB segment!\n",
>   start, end);
> return -EINVAL;
> }
>
> +   if (cmd == 0) {
> +   r = radeon_uvd_cs_msg(p, reloc->robj, offset, buf_sizes);
> +   if (r)
> +   return r;
> +   }
> +
> return 0;
>  }
>
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/6] drm/radeon: minor HDMI improvements

[Alex Deucher]

On Sat, Apr 13, 2013 at 7:26 PM, Rafa? Mi?ecki  wrote:
> I've managed to track fglrx operations on HDMI regs, so we can finally setup
> everything in (hopefully) the correct way and order.
>
> This changes HDMI setup on Evergreen to mostly match fglrx and was tested on:
> 1) AMD Radeon HD 6320 (PALM == DCE41)
> 2) AMD Radeon HD 6970M (BARTS == DCE5)
> No regressions noticed, I can still play audio, including LPCM, AC3 and DTS.
>
> Unfortunately I don't have any DCE4 hardware to test this, but that changes
> shouldn't cause any regressions. I hope that with such improvements we will
> finally able to enable audio by default.

I've applied patches 1, 4, 5, 6.  For patch 2, I'd prefer we just not
enable the interrupts rather than removing the code altogether at this
point.  See the attached patch.  For patch 3, none of the registers
mentioned are directly related to audio setup.

Alex

>
> Rafa? Mi?ecki (6):
>   drm/radeon: add helpers for masking and setting bits in regs
>   drm/radeon: remove HDMI interrupts on Evergreen
>   drm/radeon: add some HDMI comments
>   drm/radeon/evergreen: setup HDMI before enabling it
>   drm/radeon/evergreen: reorder HDMI setup
>   drm/radeon/evergreen: write default channel numbers
>
>  drivers/gpu/drm/radeon/evergreen.c  |  127 
> +--
>  drivers/gpu/drm/radeon/evergreen_hdmi.c |   77 +++
>  drivers/gpu/drm/radeon/evergreend.h |1 +
>  drivers/gpu/drm/radeon/r600_hdmi.c  |   16 ++--
>  drivers/gpu/drm/radeon/radeon.h |2 +
>  drivers/gpu/drm/radeon/radeon_display.c |5 ++
>  6 files changed, 76 insertions(+), 152 deletions(-)
>
> --
> 1.7.10.4
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-disable-audio-format-interrupts-on-Evergr.patch
Type: text/x-patch
Size: 1067 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130418/48db3883/attachment.bin>

Standalone DRM application

[Ilija Hadzic]

On Thu, 18 Apr 2013, David Herrmann wrote:

> Hi
>
> On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek  
> wrote:
>> David,
>>
>> I'm developing a small application that uses libdrm (DRM ioctls) to change
>> the
>> resolution of a single graphics display and show a framebuffer. I've run
>> into
>> two problems with this implementation that I'm hoping you can address.
>>
>>
>> 1. Each application is its own process, which is designed to control 1
>> graphics
>> display. This is unlike X, for instance, which could be configured to grab
>> all
>> of the displays in the system at once.
>>
>> Depending on our stackup, there can be as many as 4 displays connected to a
>> single graphics card. One process could open /dev/dri/card0 and call
>> drmModeSetCrtc() to initialize one of its displays to the requested
>> resolution.
>> However, whenever a second process calls drmModeSetCrtc() to control a
>> second
>> display on the same card, it gets -EPERM back from the ioctl.
>>
>> I've traced this down to the following line in
>> linux/drivers/gpu/drm/drm_drv.c:
>>
>> DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
>> DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
>>
>> If I remove the DRM_MASTER flag, then my application behaves correctly, and
>> 4
>> separate processes can then control each individual display on the card
>> without
>> issue.
>>
>> My question is, is there any real benefit to restricting drm_mode_setcrtc()
>> with DRM_MASTER, or can we lose this flag in order to support
>> one-process-per-
>> display programs like the above?
>
> Only one open-file can be DRM-Master. And only DRM-Master is allowed
> to perform mode-setting. This is to prevent render-clients (like
> OpenGL clients) to perform mode-setting, which should be restricted to
> the compositor/...
>
> In your scenario, you should share a single open-file between the
> processes by passing the FDs to each. Or do all of that in a single
> process. There is no way to split CRTCs/connectors between different
> nodes or have multiple DRM-Masters on a single node at once. (There is
> work going on to allow this, but it will take a while...)
>

If running a custom-patched kernel is acceptable (i.e. custom-built, 
embedded system or the like), then a set of patches that I sent about a 
year ago [1] will probably do the job. The problem is that these patches 
are apparently not going upstream because there was little interest and 
there were a couple of arguments against them [2]. Originally, it's the 
work that Dave Airlie started but abandoned. I finished it off and tried 
to have it included upstream but it didn't happen.

I have an application that is similar to what is described here and I am 
using these patches to make it work. Essentially, what you do is call a 
small userspace utility (also included with the patches for libdrm) and 
specify which CRTCs/encoders/connectors/planes do you want included in the 
node and you get a new /dev/dri/render node that your application can 
use and be the master on these resources only. Then for the next node you 
call the utility again and specify a new set of display resources and then 
you run the other application on the top of that node.

The patches that are on the mailing list archive [1] are now a year old, 
but I have a rebased version for newer kernels, which I can send to 
whoever is interested in having them (I am just hesitating to pollute the 
mailing list with patches to which the maintainers have already said 
"no").

[1] http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html
[2] http://lists.freedesktop.org/archives/dri-devel/2012-September/028348.html

-- Ilija

abuse of dumb ioctls in exynos

[Dave Airlie]

It appears exynos is passing the generic flags from the dumb ioctls
straight into the the GEM creation code.

The dumb flags are NOT driver specific, and are NOT to be used in this
fashion. Please remove this use of the flags from your driver.

I was going to add one new flag to the interface for SCANOUT vs CURSOR
for some drivers.

Dave.

[PATCH 1/6] mm: use vma_pages() to replace (vm_end - vm_start) >> PAGE_SHIFT

[Michel Lespinasse]

On Mon, Apr 15, 2013 at 5:48 AM, Libin  wrote:
> (*->vm_end - *->vm_start) >> PAGE_SHIFT operation is implemented
> as a inline funcion vma_pages() in linux/mm.h, so using it.
>
> Signed-off-by: Libin 

Looks good to me.

Reviewed-by: Michel Lespinasse 

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

[Bug 63532] Heroes of Newerth Water renders Black instead of transparent with reflections on Ultra [r600g]

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

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

--- Comment #15 from Vadim Girlin  ---
(In reply to comment #14)
> > #2  0x7f4485b7a63e in glBindTexture (target=0, texture=2079)
> 
> That's definitely no good.  0 isn't a valid target, and 2079 (0x081F) isn't
> either.  Weird.

I tested it with catalyst 13.1, there is the same rendering issue (water is
black with some video settings), and similar BindTexture calls with target 0,
so I think it's not a mesa/r600g's issues.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130418/cbc062ed/attachment.html>

gma500: Other things that I could work on

[Patrik Jakobsson]

On Wed, Apr 17, 2013 at 7:57 PM, Kero  wrote:
>> > 4) when using modules, initialization from hibernation is not good enough:
>> >my screen stays black; without using modules, the kernel boots 
>> > normally, and everything is fine.
>> > 5) initialization from suspend is not good enough: my Asus stays in
>> >some text mode (80x25?), but shows garbage (possibly data from the 
>> > desired console or
>> >graphics mode, since sometimes there are reactions correlated to 
>> > actions)
>> >Switching tty or using `chvt` do not improve anything.
>> >NB: hibernating and booting solves this.
>>
>> I may have fixed some of your issues, could you please try the latest
>> gma500-next and report back.
>>
>> https://github.com/patjak/drm-gma500.git gma500-next
>
> Like I said, I am on vacation.
> So it took a while before I had some time to spend on this experiment.
> The good news, both problems seem to be solved on my hardware.

Vacation is vacation... you're excused ;)

Thanks for testing, seems the biggest bumps for cdv suspend/hibernation are
gone. Feel free to look at the other issues if you have some spare time on your
hands.

-Patrik

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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

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

--- Comment #33 from Benjamin Lee  ---
Sorry, my previous patch was bogus -- TURKS mobility actually needs
POWER_STATE_TYPE_PERFORMANCE.  radeon_pm_get_type_index() currently fails to
find the requested state (POWER_STATE_TYPE_BATTERY).

Here is a trivial patch against linux-3.8.8:

diff -ruN linux-3.8.8.orig/drivers/gpu/drm/radeon/evergreen.c
linux-3.8.8/drivers/gpu/drm/radeon/evergreen.c
--- linux-3.8.8.orig/drivers/gpu/drm/radeon/evergreen.c 2013-04-16
22:11:28.0 -0700
+++ linux-3.8.8/drivers/gpu/drm/radeon/evergreen.c  2013-04-17
16:51:04.858752564 -0700
@@ -343,7 +343,7 @@
 * MH and SH.  Difference is that we always use the high clock index
for
 * mclk.
 */
-   if (rdev->flags & RADEON_IS_MOBILITY)
+   if ((rdev->flags & RADEON_IS_MOBILITY) && (rdev->family != CHIP_TURKS))
idx = radeon_pm_get_type_index(rdev, POWER_STATE_TYPE_BATTERY,
0);
else
idx = radeon_pm_get_type_index(rdev,
POWER_STATE_TYPE_PERFORMANCE, 0);

Running with the patch in multi-head shows reduced engine clock and voltage,
but high memory clock as expected:

blee at supra ~ $ cat /sys/class/drm/card0/device/power_method
profile
blee at supra ~ $ cat /sys/class/drm/card0/device/power_profile
low
blee at supra ~ $ sudo cat /sys/kernel/debug/dri/0/radeon_pm_info
default engine clock: 60 kHz
current engine clock: 0 kHz
default memory clock: 793750 kHz
current memory clock: 793750 kHz
voltage: 900 mV

-- 
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/20130418/35189a55/attachment.html>

Re: abuse of dumb ioctls in exynos

[Inki Dae]

Hi, Dave


2013/4/18 Dave Airlie airl...@gmail.com

 It appears exynos is passing the generic flags from the dumb ioctls
 straight into the the GEM creation code.

 The dumb flags are NOT driver specific, and are NOT to be used in this
 fashion. Please remove this use of the flags from your driver.



Got it. I will post one patch to it soon.

Thanks for your pointing out.
Inki Dae



 I was going to add one new flag to the interface for SCANOUT vs CURSOR
 for some drivers.

 Dave.
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: do not use generic flags to dumb

[Inki Dae]

This patch removes the use of dumb flags from driver.

As Dave pointed out, the dumb flags are not driver specific
so this should be removed from driver.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 0e6fe00..cf4543f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -682,7 +682,8 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv,
args-pitch = args-width * ((args-bpp + 7) / 8);
args-size = args-pitch * args-height;
 
-   exynos_gem_obj = exynos_drm_gem_create(dev, args-flags, args-size);
+   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
+   EXYNOS_BO_WC, args-size);
if (IS_ERR(exynos_gem_obj))
return PTR_ERR(exynos_gem_obj);
 
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: cleanup UVD address checks

[Christian König]

From: Christian König christian.koe...@amd.com

Message and feedback buffers must be at start of
VRAM, not at start of address space.

Signed-off-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/radeon_uvd.c |   26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 30a9460..2fb4d6c 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -415,24 +415,26 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser *p,
return -EINVAL;
}
 
-   if (cmd == 0) {
-   if (end  0xF000) {
-   DRM_ERROR(msg buffer %LX-%LX out of 256MB segment!\n,
- start, end);
-   return -EINVAL;
-   }
-
-   r = radeon_uvd_cs_msg(p, reloc-robj, offset, buf_sizes);
-   if (r)
-   return r;
+   if ((start  28) != (end  28)) {
+   DRM_ERROR(reloc %LX-%LX crossing 256MB boundary!\n,
+ start, end);
+   return -EINVAL;
}
 
-   if ((start  0xF000) != (end  0xF000)) {
-   DRM_ERROR(reloc %LX-%LX crossing 256MB boundary!\n,
+   /* TODO: is this still necessary on NI+ ? */
+   if ((cmd == 0 || cmd == 0x3) 
+   (start  28) != (p-rdev-uvd.gpu_addr  28)) {
+   DRM_ERROR(msg/fb buffer %LX-%LX out of 256MB segment!\n,
  start, end);
return -EINVAL;
}
 
+   if (cmd == 0) {
+   r = radeon_uvd_cs_msg(p, reloc-robj, offset, buf_sizes);
+   if (r)
+   return r;
+   }
+
return 0;
 }
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon: fix alignment of UVD fence

[Christian König]

From: Christian König christian.koe...@amd.com

Signed-off-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/radeon_fence.c |7 +++
 drivers/gpu/drm/radeon/radeon_uvd.c   |2 +-
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index 82fe183..1a699ce 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -776,10 +776,9 @@ int radeon_fence_driver_start_ring(struct radeon_device 
*rdev, int ring)
 
} else {
/* put fence directly behind firmware */
-   rdev-fence_drv[ring].cpu_addr = rdev-uvd.cpu_addr +
-rdev-uvd_fw-size;
-   rdev-fence_drv[ring].gpu_addr = rdev-uvd.gpu_addr +
-rdev-uvd_fw-size;
+   index = ALIGN(rdev-uvd_fw-size, 8);
+   rdev-fence_drv[ring].cpu_addr = rdev-uvd.cpu_addr + 
index;
+   rdev-fence_drv[ring].gpu_addr = rdev-uvd.gpu_addr + 
index;
}
 
} else {
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 2fb4d6c..15580fb 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -107,7 +107,7 @@ int radeon_uvd_init(struct radeon_device *rdev)
 
platform_device_unregister(pdev);
 
-   bo_size = RADEON_GPU_PAGE_ALIGN(rdev-uvd_fw-size + 4) +
+   bo_size = RADEON_GPU_PAGE_ALIGN(rdev-uvd_fw-size + 8) +
  RADEON_UVD_STACK_SIZE + RADEON_UVD_HEAP_SIZE;
r = radeon_bo_create(rdev, bo_size, PAGE_SIZE, true,
 RADEON_GEM_DOMAIN_VRAM, NULL, rdev-uvd.vcpu_bo);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 00/10] Versatile Express CLCD DVI output support

[Pawel Moll]

Hello All,

This series implements support for the Versatile Express
video output pipeline, which is not the simplest one available...

It is meant as a RFC only and I'm hoping to attract all possible
feedback (*including* naming ;-).

The VE's MultiMedia Bus [1] comprises three video signal sources
(motherboard's CLCD cell and a implementation-specific driver
on each of the daugtherboards) and a FPGA multiplexer routing
data from one of the sources to DVI/HDMI formatter chip (Sii9022).

+-+
| DB1 |--+ DVI connector
+-+   |   +--+   +--+
  +--|  |   |oo|
+-+   | mux  |+-+|oo|
| DB2 |-|  |--| sii9022 |--|oo|
+-+   | FPGA |+-+|oo|
  +--|  |   |oo|
+-+   |   +--+   +--+
| MB  |--+
+-+

The series is based on Laurent Pinchart's Common Display Framework
patch (not in mainline yet, v2 discussed here: [2]) and extends it
by adding DT bindings and basic support for TFT panels.

The CLCD driver has been adapted to work with the framework and
the Device Tree information.

Also a set of drivers for the VE-specific components is included
(note that the sii9022 is now driven via the moterboard firmware;
this is intended to be replaced by a proper I2C driver for the
chip).

It is worth mentioning that the CDF caters for both fbdev and DRM
so the solution should be suitable for all potential DRM-driven
display controllers.

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.dui0447h/CHDEHEAA.html#CACGIGGC
[2] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/57298


Laurent Pinchart (1):
  video: Add generic display entity core

Pawel Moll (9):
  video: display: Update the display with the video mode data
  video: display: Add Device Tree bindings
  video: display: Add generic TFT display type
  fbmon: Add extra video helper
  video: ARM CLCD: Add DT  CDF support
  mfd: vexpress: Allow external drivers to parse site ids
  video: Versatile Express MUXFPGA driver
  video: Versatile Express DVI mode driver
  ARM: vexpress: Add CLCD Device Tree properties

 .../testing/sysfs-driver-video-vexpress-muxfpga|5 +
 .../devicetree/bindings/video/arm,pl11x.txt|   35 ++
 .../devicetree/bindings/video/display-bindings.txt |   75 
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi|   17 +-
 arch/arm/boot/dts/vexpress-v2m.dtsi|   17 +-
 arch/arm/boot/dts/vexpress-v2p-ca9.dts |5 +
 drivers/mfd/vexpress-sysreg.c  |5 +
 drivers/video/Kconfig  |2 +
 drivers/video/Makefile |5 +
 drivers/video/amba-clcd.c  |  244 +++
 drivers/video/display/Kconfig  |4 +
 drivers/video/display/Makefile |1 +
 drivers/video/display/display-core.c   |  447 
 drivers/video/fbmon.c  |   29 ++
 drivers/video/vexpress-dvimode.c   |  158 +++
 drivers/video/vexpress-muxfpga.c   |  228 ++
 include/linux/amba/clcd.h  |2 +
 include/linux/fb.h |3 +
 include/linux/vexpress.h   |2 +
 include/video/display.h|  172 
 20 files changed, 1448 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
 create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt
 create mode 100644 Documentation/devicetree/bindings/video/display-bindings.txt
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 drivers/video/vexpress-dvimode.c
 create mode 100644 drivers/video/vexpress-muxfpga.c
 create mode 100644 include/video/display.h

-- 
1.7.10.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 09/10] video: Versatile Express DVI mode driver

[Pawel Moll]

Versatile Express DVI output is driven by a Sii9022 chip. It can be
controller to a limited extend by the Motherboard Config Controller,
and that's what the driver is doing now. It is a temporary measure
till there's a full I2C driver for the chip.

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 drivers/video/Makefile   |1 +
 drivers/video/vexpress-dvimode.c |  158 ++
 2 files changed, 159 insertions(+)
 create mode 100644 drivers/video/vexpress-dvimode.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 84c6083..9347e00 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -179,3 +179,4 @@ obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
 
 # platform specific output drivers
 obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-muxfpga.o
+obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-dvimode.o
diff --git a/drivers/video/vexpress-dvimode.c b/drivers/video/vexpress-dvimode.c
new file mode 100644
index 000..85d5608
--- /dev/null
+++ b/drivers/video/vexpress-dvimode.c
@@ -0,0 +1,158 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * Copyright (C) 2013 ARM Limited
+ */
+
+#define pr_fmt(fmt) vexpress-dvimode:  fmt
+
+#include linux/fb.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/vexpress.h
+#include video/display.h
+#include video/videomode.h
+
+
+static struct vexpress_config_func *vexpress_dvimode_func;
+
+
+static int vexpress_dvimode_display_update(struct display_entity *display,
+   const struct videomode *mode)
+{
+   static const struct {
+   u32 hactive, vactive, dvimode;
+   } dvimodes[] = {
+   { 640, 480, 0 }, /* VGA */
+   { 800, 600, 1 }, /* SVGA */
+   { 1024, 768, 2 }, /* XGA */
+   { 1280, 1024, 3 }, /* SXGA */
+   { 1600, 1200, 4 }, /* UXGA */
+   { 1920, 1080, 5 }, /* HD1080 */
+   };
+   int err = -ENOENT;
+   int i;
+
+   for (i = 0; i  ARRAY_SIZE(dvimodes); i++) {
+   if (dvimodes[i].hactive == mode-hactive 
+   dvimodes[i].vactive == mode-vactive) {
+   pr_debug(mode: %ux%u = %d\n, mode-hactive,
+   mode-vactive, dvimodes[i].dvimode);
+   err = vexpress_config_write(vexpress_dvimode_func, 0,
+   dvimodes[i].dvimode);
+   break;
+   }
+   }
+
+   if (err)
+   pr_warn(Failed to set %ux%u mode! (%d)\n, mode-hactive,
+   mode-vactive, err);
+
+   return err;
+}
+
+static int vexpress_dvimode_display_get_modes(struct display_entity *display,
+   const struct videomode **modes)
+{
+   static const struct videomode m[] = {
+   {
+   /* VGA */
+   .pixelclock = 25175000,
+   .hactive= 640,
+   .hback_porch= 40,
+   .hfront_porch   = 24,
+   .vfront_porch   = 11,
+   .hsync_len  = 96,
+   .vactive= 480,
+   .vback_porch= 32,
+   .vsync_len  = 2,
+   }, {
+   /* XGA */
+   .pixelclock = 63500127,
+   .hactive= 1024,
+   .hback_porch= 152,
+   .hfront_porch   = 48,
+   .hsync_len  = 104,
+   .vactive= 768,
+   .vback_porch= 23,
+   .vfront_porch   = 3,
+   .vsync_len  = 4,
+   }, {
+   /* SXGA */
+   .pixelclock = 10800,
+   .hactive= 1280,
+   .hback_porch= 248,
+   .hfront_porch   = 48,
+   .hsync_len  = 112,
+   .vactive= 1024,
+   .vback_porch= 38,
+   .vfront_porch   = 1,
+   .vsync_len  = 3,
+   },
+   };
+
+   *modes = m;
+
+   return ARRAY_SIZE(m);
+}
+
+static int vexpress_dvimode_display_get_params(struct display_entity *display,
+   struct display_entity_interface_params *params)
+{
+   params-type = DISPLAY_ENTITY_INTERFACE_TFT_PARALLEL;
+   

[RFC 03/10] video: display: Add Device Tree bindings

[Pawel Moll]

Modelled after the common clock solution, the bindings
are based on the idea of display entity providers and
consumers.

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 .../devicetree/bindings/video/display-bindings.txt |   75 +
 drivers/video/display/display-core.c   |   84 
 include/video/display.h|   11 +++
 3 files changed, 170 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/display-bindings.txt

diff --git a/Documentation/devicetree/bindings/video/display-bindings.txt 
b/Documentation/devicetree/bindings/video/display-bindings.txt
new file mode 100644
index 000..6d8b888
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/display-bindings.txt
@@ -0,0 +1,75 @@
+[this is an RFC]
+
+Common Display Framework define a display entity (eg. LCD panel),
+being a sink for video data generated by a video signal generator
+(eg.  LCD controller/driver).
+
+This set of bindings allow to represent connections between them
+in the Device Tree.
+
+Devices nodes representing display sinks are called display
+providers and nodes representing display sources are called
+display consumers.
+
+Notice that in both cases a device represented by a node can
+provide or consume more than one display entity. For example
+a LCD controller can be able to driver more than one LCD
+panel at the same time, while a panel (or a special signal
+multiplexer) may have more than one input (sink) and switch
+between them.
+
+== Display provider ==
+
+Required properties:
+
+* #clock-cells:Number of cells in the display specifier. Typically
+   0 for nodes providing single display entity and 1
+   for nodes providing multiple displays.
+
+Example:
+   dvi-output: dvi-output@0 {
+   #display-cells = 0;
+   };
+
+== Display consumer ==
+
+Required properties:
+
+* display: List of phandle and clock specifier pairs, one pair
+   for each display (sink). Note: if the display provider
+   specifies '0' for #display-cells, then only the phandle
+   portion of the pair will appear.
+
+Example:
+
+   display-driver {
+   display = dvi-output;
+   };
+
+== Larger example ==
+
+   clcd@1002 {
+   compatible = arm,pl111, arm,primecell;
+   reg = 0x1002 0x1000;
+   interrupts = 0 44 4;
+   clocks = oscclk1, oscclk2;
+   clock-names = clcdclk, apb_pclk;
+   label = V2P-CA9 CLCD;
+   display = v2m_muxfpga 0xf;
+   max-hactive = 1024;
+   max-vactive = 768;
+   max-bpp = 16;
+   };
+
+   v2m_muxfpga: muxfpga@0 {
+   compatible = arm,vexpress-muxfpga;
+   arm,vexpress-sysreg,func = 7 0;
+   #display-cells = 1;
+   display = v2m_dvimode;
+   };
+
+   v2m_dvimode: dvimode@0 {
+   compatible = arm,vexpress-dvimode;
+   arm,vexpress-sysreg,func = 11 0;
+   #display-cells = 0;
+   };
diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
index 4b8e45a..9827a5d 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -15,6 +15,7 @@
 #include linux/list.h
 #include linux/module.h
 #include linux/mutex.h
+#include linux/slab.h
 
 #include video/display.h
 #include video/videomode.h
@@ -230,6 +231,89 @@ void display_entity_put(struct display_entity *entity)
 }
 EXPORT_SYMBOL_GPL(display_entity_put);
 
+#if defined(CONFIG_OF)
+struct of_display_entity_provider {
+   struct list_head list;
+   struct device_node *node;
+   struct display_entity *(*get)(struct of_phandle_args *spec, void *data);
+   void *data;
+};
+
+static LIST_HEAD(of_display_entity_providers);
+static DEFINE_MUTEX(of_display_entity_providers_lock);
+
+int of_display_entity_add_provider(struct device_node *node,
+   struct display_entity *(*get)(struct of_phandle_args *spec,
+   void *data), void *data)
+{
+   struct of_display_entity_provider *provider =
+   kzalloc(sizeof(*provider), GFP_KERNEL);
+
+   if (!provider)
+   return -ENOMEM;
+
+   provider-node = of_node_get(node);
+   provider-get = get;
+   provider-data = data;
+
+   mutex_lock(of_display_entity_providers_lock);
+   list_add(provider-list, 

[RFC 05/10] fbmon: Add extra video helper

[Pawel Moll]

This function converts the fb_var_screeninfo to the videomode
structure, to be used in fbdev drivers working with the
Common Display Framework.

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 drivers/video/fbmon.c |   29 +
 include/linux/fb.h|3 +++
 2 files changed, 32 insertions(+)

diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 7f67099..f0ff2bf 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1424,6 +1424,35 @@ int fb_videomode_from_videomode(const struct videomode 
*vm,
return 0;
 }
 EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+
+void videomode_from_fb_var_screeninfo(const struct fb_var_screeninfo *var,
+ struct videomode *vm)
+{
+   vm-pixelclock = PICOS2KHZ(var-pixclock) * 1000;
+
+   vm-hactive = var-xres;
+   vm-hfront_porch = var-right_margin;
+   vm-hback_porch = var-left_margin;
+   vm-hsync_len = var-hsync_len;
+
+   vm-vactive = var-yres;
+   vm-vfront_porch = var-lower_margin;
+   vm-vback_porch = var-upper_margin;
+   vm-vsync_len = var-vsync_len;
+
+   vm-dmt_flags = 0;
+   if (var-sync  FB_SYNC_HOR_HIGH_ACT)
+   vm-dmt_flags |= VESA_DMT_HSYNC_HIGH;
+   if (var-sync  FB_SYNC_VERT_HIGH_ACT)
+   vm-dmt_flags |= VESA_DMT_VSYNC_HIGH;
+
+   vm-data_flags = 0;
+   if (var-vmode  FB_VMODE_INTERLACED)
+   vm-data_flags |= DISPLAY_FLAGS_INTERLACED;
+   if (var-vmode  FB_VMODE_DOUBLE)
+   vm-data_flags |= DISPLAY_FLAGS_DOUBLESCAN;
+}
+EXPORT_SYMBOL_GPL(videomode_from_fb_var_screeninfo);
 #endif
 
 #if IS_ENABLED(CONFIG_OF_VIDEOMODE)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 58b9860..aae2ed3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -721,6 +721,9 @@ extern int of_get_fb_videomode(struct device_node *np,
   int index);
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);
+extern void videomode_from_fb_var_screeninfo(
+   const struct fb_var_screeninfo *var,
+   struct videomode *vm);
 
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 34
-- 
1.7.10.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 02/10] video: display: Update the display with the video mode data

[Pawel Moll]

The display entity (sink) may need to know about the mode being
changed, eg. to update timings.

Alternatively there could be a separate set_mode() operation...

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 drivers/video/display/display-core.c |5 +++--
 include/video/display.h  |6 --
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
index d2daa15..4b8e45a 100644
--- a/drivers/video/display/display-core.c
+++ b/drivers/video/display/display-core.c
@@ -69,12 +69,13 @@ EXPORT_SYMBOL_GPL(display_entity_set_state);
  *
  * Return 0 on success or a negative error code otherwise.
  */
-int display_entity_update(struct display_entity *entity)
+int display_entity_update(struct display_entity *entity,
+const struct videomode *mode)
 {
if (!entity-ops.ctrl || !entity-ops.ctrl-update)
return 0;
 
-   return entity-ops.ctrl-update(entity);
+   return entity-ops.ctrl-update(entity, mode);
 }
 EXPORT_SYMBOL_GPL(display_entity_update);
 
diff --git a/include/video/display.h b/include/video/display.h
index 90d18ca..64f84d5 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -77,7 +77,8 @@ struct display_entity_interface_params {
 struct display_entity_control_ops {
int (*set_state)(struct display_entity *ent,
 enum display_entity_state state);
-   int (*update)(struct display_entity *ent);
+   int (*update)(struct display_entity *ent,
+const struct videomode *mode);
int (*get_modes)(struct display_entity *ent,
 const struct videomode **modes);
int (*get_params)(struct display_entity *ent,
@@ -111,7 +112,8 @@ struct display_entity {
 
 int display_entity_set_state(struct display_entity *entity,
 enum display_entity_state state);
-int display_entity_update(struct display_entity *entity);
+int display_entity_update(struct display_entity *entity,
+const struct videomode *mode);
 int display_entity_get_modes(struct display_entity *entity,
 const struct videomode **modes);
 int display_entity_get_params(struct display_entity *entity,
-- 
1.7.10.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 04/10] video: display: Add generic TFT display type

[Pawel Moll]

TFT panels may be interfaced via a simple parallel interface
carrying RGB data, pixel clock and synchronisation signals.
From the video generator point of view the width of the data
channels (number of bits per R/G/B components) may be an
important factor in setting up the display model.

Above information is based on the presentations by Dave Anders
available here: http://elinux.org/Elc-lcd

This patch adds the parallel TFT display type and basic parameters
structure. Maybe it should be split into a separate header, eg.
include/video/tft.h? Or maybe it's just the INTERFACE_DPI I'm
talking about?

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 include/video/display.h |9 +
 1 file changed, 9 insertions(+)

diff --git a/include/video/display.h b/include/video/display.h
index 7fe8b2f..875e230 100644
--- a/include/video/display.h
+++ b/include/video/display.h
@@ -69,10 +69,19 @@ enum display_entity_stream_state {
 
 enum display_entity_interface_type {
DISPLAY_ENTITY_INTERFACE_DPI,
+   DISPLAY_ENTITY_INTERFACE_TFT_PARALLEL,
+};
+
+struct tft_parallel_interface_params {
+   int r_bits, g_bits, b_bits;
+   int r_b_swapped;
 };
 
 struct display_entity_interface_params {
enum display_entity_interface_type type;
+   union {
+   struct tft_parallel_interface_params tft_parallel;
+   } p;
 };
 
 struct display_entity_control_ops {
-- 
1.7.10.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 06/10] video: ARM CLCD: Add DT CDF support

[Pawel Moll]

This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them, together with the
Common Display Framework.

The DT provides information about the hardware configuration
and limitations (eg. the largest supported resolution)
but the video modes come exclusively from the Common
Display Framework drivers, referenced to by the standard CDF
binding.

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 .../devicetree/bindings/video/arm,pl11x.txt|   35 +++
 drivers/video/Kconfig  |1 +
 drivers/video/amba-clcd.c  |  244 
 include/linux/amba/clcd.h  |2 +
 4 files changed, 282 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt

diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt 
b/Documentation/devicetree/bindings/video/arm,pl11x.txt
new file mode 100644
index 000..ee9534a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -0,0 +1,35 @@
+* ARM PrimeCell Color LCD Controller (CLCD) PL110/PL111
+
+Required properties:
+
+- compatible : must be one of:
+   arm,pl110, arm,primecell
+   arm,pl111, arm,primecell
+- reg : base address and size of the control registers block
+- interrupts : the combined interrupt
+- clocks : phandles to the CLCD (pixel) clock and the APB clocks
+- clock-names : clcdclk, apb_pclk
+- display : phandle to the display entity connected to the controller
+
+Optional properties:
+
+- label : string describing the controller location and/or usage
+- video-ram : phandle to DT node of the specialized video RAM to be used
+- max-hactive : maximum frame buffer width in pixels
+- max-vactive : maximum frame buffer height in pixels
+- max-bpp : maximum number of bits per pixel
+- big-endian-pixels : defining this property makes the pixel bytes being
+   accessed in Big Endian organization
+
+Example:
+
+   clcd@1f {
+   compatible = arm,pl111, arm,primecell;
+   reg = 0x1f 0x1000;
+   interrupts = 14;
+   clocks = v2m_oscclk1, smbclk;
+   clock-names = clcdclk, apb_pclk;
+   label = IOFPGA CLCD;
+   video-ram = v2m_vram;
+   display = v2m_muxfpga;
+   };
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 281e548..bad8166 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -340,6 +340,7 @@ config FB_ARMCLCD
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+   select FB_MODE_HELPERS if OF
help
  This framebuffer device driver is for the ARM PrimeCell PL110
  Colour LCD controller.  ARM PrimeCells provide the building
diff --git a/drivers/video/amba-clcd.c b/drivers/video/amba-clcd.c
index 0a2cce7..778dc03 100644
--- a/drivers/video/amba-clcd.c
+++ b/drivers/video/amba-clcd.c
@@ -25,6 +25,11 @@
 #include linux/amba/clcd.h
 #include linux/clk.h
 #include linux/hardirq.h
+#include linux/dma-mapping.h
+#include linux/of.h
+#include linux/of_address.h
+#include video/display.h
+#include video/videomode.h
 
 #include asm/sizes.h
 
@@ -62,6 +67,10 @@ static void clcdfb_disable(struct clcd_fb *fb)
 {
u32 val;
 
+   if (fb-panel-display)
+   display_entity_set_state(fb-panel-display,
+   DISPLAY_ENTITY_STATE_OFF);
+
if (fb-board-disable)
fb-board-disable(fb);
 
@@ -115,6 +124,11 @@ static void clcdfb_enable(struct clcd_fb *fb, u32 cntl)
 */
if (fb-board-enable)
fb-board-enable(fb);
+
+   if (fb-panel-display)
+   display_entity_set_state(fb-panel-display,
+   DISPLAY_ENTITY_STATE_ON);
+
 }
 
 static int
@@ -304,6 +318,13 @@ static int clcdfb_set_par(struct fb_info *info)
 
clcdfb_enable(fb, regs.cntl);
 
+   if (fb-panel-display) {
+   struct videomode mode;
+
+   videomode_from_fb_var_screeninfo(fb-fb.var, mode);
+   display_entity_update(fb-panel-display, mode);
+   }
+
 #ifdef DEBUG
printk(KERN_INFO
   CLCD: Registers set to\n
@@ -542,6 +563,226 @@ static int clcdfb_register(struct clcd_fb *fb)
return ret;
 }
 
+#if defined(CONFIG_OF)
+static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
+   struct display_entity_interface_params *params)
+{
+   int r = params-p.tft_parallel.r_bits;
+   int g = params-p.tft_parallel.g_bits;
+   int b = params-p.tft_parallel.b_bits;
+
+   /* Bypass pixel clock divider, data output on the falling edge */
+   panel-tim2 = TIM2_BCD | TIM2_IPC;
+
+   /* 

[RFC 10/10] ARM: vexpress: Add CLCD Device Tree properties

[Pawel Moll]

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 arch/arm/boot/dts/vexpress-v2m-rs1.dtsi |   17 +
 arch/arm/boot/dts/vexpress-v2m.dtsi |   17 +
 arch/arm/boot/dts/vexpress-v2p-ca9.dts  |5 +
 3 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi 
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index ac870fb..aac9459 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -41,7 +41,7 @@
bank-width = 4;
};
 
-   vram@2, {
+   v2m_vram: vram@2, {
compatible = arm,vexpress-vram;
reg = 2 0x 0x0080;
};
@@ -233,6 +233,12 @@
interrupts = 14;
clocks = v2m_oscclk1, smbclk;
clock-names = clcdclk, apb_pclk;
+   label = IOFPGA CLCD;
+   video-ram = v2m_vram;
+   display = v2m_muxfpga 0;
+   max-hactive = 640;
+   max-vactive = 480;
+   max-bpp = 16;
};
};
 
@@ -282,7 +288,7 @@
/* CLCD clock */
compatible = arm,vexpress-osc;
arm,vexpress-sysreg,func = 1 1;
-   freq-range = 2375 6350;
+   freq-range = 2375 6500;
#clock-cells = 0;
clock-output-names = v2m:oscclk1;
};
@@ -317,9 +323,11 @@
arm,vexpress-sysreg,func = 5 0;
};
 
-   muxfpga@0 {
+   v2m_muxfpga: muxfpga@0 {
compatible = arm,vexpress-muxfpga;
arm,vexpress-sysreg,func = 7 0;
+   #display-cells = 1;
+   display = v2m_dvimode;
};
 
shutdown@0 {
@@ -332,9 +340,10 @@
arm,vexpress-sysreg,func = 9 0;
};
 
-   dvimode@0 {
+   v2m_dvimode: dvimode@0 {
compatible = arm,vexpress-dvimode;
arm,vexpress-sysreg,func = 11 0;
+   #display-cells = 0;
};
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi 
b/arch/arm/boot/dts/vexpress-v2m.dtsi
index f142036..4d080d0 100644
--- a/arch/arm/boot/dts/vexpress-v2m.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m.dtsi
@@ -40,7 +40,7 @@
bank-width = 4;
};
 
-   vram@3, {
+   v2m_vram: vram@3, {
compatible = arm,vexpress-vram;
reg = 3 0x 0x0080;
};
@@ -232,6 +232,12 @@
interrupts = 14;
clocks = v2m_oscclk1, smbclk;
clock-names = clcdclk, apb_pclk;
+   label = IOFPGA CLCD;
+   video-ram = v2m_vram;
+   display = v2m_muxfpga 0;
+   max-hactive = 640;
+   max-vactive = 480;
+   max-bpp = 16;
};
};
 
@@ -281,7 +287,7 @@
/* CLCD clock */
compatible = arm,vexpress-osc;
arm,vexpress-sysreg,func = 1 1;
-   freq-range = 2375 6350;
+   freq-range = 2375 6500;
#clock-cells = 0;
clock-output-names = v2m:oscclk1;
};
@@ -316,9 +322,11 @@
arm,vexpress-sysreg,func = 5 0;
};
 
-   muxfpga@0 {
+   v2m_muxfpga: muxfpga@0 {
compatible = arm,vexpress-muxfpga;
arm,vexpress-sysreg,func = 7 0;
+   #display-cells = 1;
+   display = v2m_dvimode;
};
 
shutdown@0 {
@@ -331,9 +339,10 @@
arm,vexpress-sysreg,func = 9 0;
};
 
-   dvimode@0 {
+   v2m_dvimode: dvimode@0 {
 

[RFC 01/10] video: Add generic display entity core

[Pawel Moll]

From: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/video/Kconfig|1 +
 drivers/video/Makefile   |1 +
 drivers/video/display/Kconfig|4 +
 drivers/video/display/Makefile   |1 +
 drivers/video/display/display-core.c |  362 ++
 include/video/display.h  |  150 ++
 6 files changed, 519 insertions(+)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 include/video/display.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 4c1546f..281e548 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2456,6 +2456,7 @@ source drivers/video/omap2/Kconfig
 source drivers/video/exynos/Kconfig
 source drivers/video/mmp/Kconfig
 source drivers/video/backlight/Kconfig
+source drivers/video/display/Kconfig
 
 if VT
source drivers/video/console/Kconfig
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9df3873..b989e8e 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -15,6 +15,7 @@ fb-objs   := $(fb-y)
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-y+= backlight/
+obj-y+= display/
 
 obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
 
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
new file mode 100644
index 000..1d533e7
--- /dev/null
+++ b/drivers/video/display/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_CORE
+   tristate Display Core
+   ---help---
+ Support common display framework for graphics devices.
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
new file mode 100644
index 000..bd93496
--- /dev/null
+++ b/drivers/video/display/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_CORE) += display-core.o
diff --git a/drivers/video/display/display-core.c 
b/drivers/video/display/display-core.c
new file mode 100644
index 000..d2daa15
--- /dev/null
+++ b/drivers/video/display/display-core.c
@@ -0,0 +1,362 @@
+/*
+ * Display Core
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+
+#include video/display.h
+#include video/videomode.h
+
+static LIST_HEAD(display_entity_list);
+static LIST_HEAD(display_entity_notifiers);
+static DEFINE_MUTEX(display_entity_mutex);
+
+/* 
-
+ * Control operations
+ */
+
+/**
+ * display_entity_set_state - Set the display entity operation state
+ * @entity: The display entity
+ * @state: Display entity operation state
+ *
+ * See enum display_entity_state for information regarding the entity states.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_set_state(struct display_entity *entity,
+enum display_entity_state state)
+{
+   int ret;
+
+   if (entity-state == state)
+   return 0;
+
+   if (!entity-ops.ctrl || !entity-ops.ctrl-set_state)
+   return 0;
+
+   ret = entity-ops.ctrl-set_state(entity, state);
+   if (ret  0)
+   return ret;
+
+   entity-state = state;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(display_entity_set_state);
+
+/**
+ * display_entity_update - Update the display
+ * @entity: The display entity
+ *
+ * Make the display entity ready to receive pixel data and start frame 
transfer.
+ * This operation can only be called if the display entity is in STANDBY or ON
+ * state.
+ *
+ * The display entity will call the upstream entity in the video chain to start
+ * the video stream.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int display_entity_update(struct display_entity *entity)
+{
+   if (!entity-ops.ctrl || !entity-ops.ctrl-update)
+   return 0;
+
+   return entity-ops.ctrl-update(entity);
+}
+EXPORT_SYMBOL_GPL(display_entity_update);
+
+/**
+ * display_entity_get_modes - Get video modes supported by the display entity
+ * @entity The display entity
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the display entity.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int 

[RFC 07/10] mfd: vexpress: Allow external drivers to parse site ids

[Pawel Moll]

... by providing a function translating the MASTER
value into the currently valid site number and
a _LAST constant providing all possible site id values.

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 drivers/mfd/vexpress-sysreg.c |5 +
 include/linux/vexpress.h  |2 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index bf75e96..4158e26 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -81,6 +81,11 @@ void vexpress_flags_set(u32 data)
writel(data, vexpress_sysreg_base + SYS_FLAGSSET);
 }
 
+u32 vexpress_get_site(int site)
+{
+   return site == VEXPRESS_SITE_MASTER ? vexpress_master_site : site;
+}
+
 u32 vexpress_get_procid(int site)
 {
if (site == VEXPRESS_SITE_MASTER)
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index 7581874..1ebbcf5 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -19,6 +19,7 @@
 #define VEXPRESS_SITE_MB   0
 #define VEXPRESS_SITE_DB1  1
 #define VEXPRESS_SITE_DB2  2
+#define __VEXPRESS_SITE_LAST   3
 #define VEXPRESS_SITE_MASTER   0xf
 
 #define VEXPRESS_CONFIG_STATUS_DONE0
@@ -103,6 +104,7 @@ int vexpress_config_write(struct vexpress_config_func 
*func, int offset,
 
 /* Platform control */
 
+u32 vexpress_get_site(int site);
 u32 vexpress_get_procid(int site);
 u32 vexpress_get_hbi(int site);
 void *vexpress_get_24mhz_clock_base(void);
-- 
1.7.10.4


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 08/10] video: Versatile Express MUXFPGA driver

[Pawel Moll]

Versatile Express' DVI video output can be connected to one the three
sources - motherboard's CLCD controller or a video signal generated
by one of the daughterboards.

This driver provides a Common Display Framework driver for the
muxer FPGA, which acts as a switch selecting one of the video data
sources. The default source is selected basing on the priority
list (which itself can be modified via module paramter), but
the user can make his own decision about it using the device's
sysfs source attribute.

Signed-off-by: Pawel Moll pawel.m...@arm.com
---
 .../testing/sysfs-driver-video-vexpress-muxfpga|5 +
 drivers/video/Makefile |3 +
 drivers/video/vexpress-muxfpga.c   |  228 
 3 files changed, 236 insertions(+)
 create mode 100644 
Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
 create mode 100644 drivers/video/vexpress-muxfpga.c

diff --git a/Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga 
b/Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
new file mode 100644
index 000..bfd568d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-video-vexpress-muxfpga
@@ -0,0 +1,5 @@
+What:  /sys/bus/platform/drivers/vexpress-muxfpga/muxfpga 
device/source
+Date:  April 2013
+Contant:   Pawel Moll pawel.m...@arm.com
+Description:   This file stores the id of the video signal source
+   supposed to be routed to the board's DVI output.
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index b989e8e..84c6083 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -176,3 +176,6 @@ obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
 obj-$(CONFIG_OF_DISPLAY_TIMING) += of_display_timing.o
 obj-$(CONFIG_VIDEOMODE) += videomode.o
 obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
+
+# platform specific output drivers
+obj-$(CONFIG_VEXPRESS_CONFIG)+= vexpress-muxfpga.o
diff --git a/drivers/video/vexpress-muxfpga.c b/drivers/video/vexpress-muxfpga.c
new file mode 100644
index 000..1731ad0
--- /dev/null
+++ b/drivers/video/vexpress-muxfpga.c
@@ -0,0 +1,228 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * Copyright (C) 2013 ARM Limited
+ */
+
+#define pr_fmt(fmt) vexpress-muxfpga:  fmt
+
+#include linux/fb.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/vexpress.h
+#include video/display.h
+#include video/videomode.h
+
+
+static struct vexpress_config_func *vexpress_muxfpga_func;
+static struct display_entity *vexpress_muxfpga_output;
+
+
+static struct vexpress_muxfpga_source {
+   struct display_entity display;
+   struct videomode mode;
+   bool updated;
+} vexpress_muxfpga_sources[__VEXPRESS_SITE_LAST];
+static u32 vexpress_muxfpga_source_site = VEXPRESS_SITE_MB;
+static bool vexpress_muxfpga_source_stored;
+
+
+static int vexpress_muxfpga_set_site(u32 site)
+{
+   int err;
+
+   if (site = ARRAY_SIZE(vexpress_muxfpga_sources))
+   return -EINVAL;
+
+   err = vexpress_config_write(vexpress_muxfpga_func, 0, site);
+   if (!err) {
+   pr_debug(Selected site %d as source\n, site);
+   vexpress_muxfpga_source_site = site;
+   } else {
+   pr_warn(Failed to select site %d as source! (%d)\n,
+   site, err);
+   }
+
+   return err;
+}
+
+static unsigned int vexpress_muxfpga_preferred_sites[] = {
+   VEXPRESS_SITE_MASTER,
+   VEXPRESS_SITE_DB1,
+   VEXPRESS_SITE_DB2,
+   VEXPRESS_SITE_MB,
+};
+static unsigned int vexpress_muxfpga_preferred_sites_num =
+   ARRAY_SIZE(vexpress_muxfpga_preferred_sites);
+module_param_array_named(preferred_sites, vexpress_muxfpga_preferred_sites,
+   uint, vexpress_muxfpga_preferred_sites_num, S_IRUGO);
+MODULE_PARM_DESC(preferred_sites, Preferred order of MUXFPGA (DVI output) 
+   sources; values can be a daughterboard site ID (1-2), the 
+   motherboard ID (0) or a value describing the master site 
+   (0xf).);
+
+static int vexpress_muxfpga_get_priority(u32 site)
+{
+   int i;
+
+   for (i = 0; i  vexpress_muxfpga_preferred_sites_num; i++) {
+   u32 preference = vexpress_muxfpga_preferred_sites[i];
+
+   if (site == vexpress_get_site(preference))
+   return i;
+   }
+
+   return INT_MAX;
+}
+
+static void vexpress_muxfpga_set_preffered_site(u32 site)
+{
+   int current_priority = vexpress_muxfpga_get_priority(
+   

Re: gma500: Other things that I could work on

[Kero]

  4) when using modules, initialization from hibernation is not good enough:
 my screen stays black; without using modules, the kernel boots normally, 
  and everything is fine.
  5) initialization from suspend is not good enough: my Asus stays in
 some text mode (80x25?), but shows garbage (possibly data from the 
  desired console or
 graphics mode, since sometimes there are reactions correlated to actions)
 Switching tty or using `chvt` do not improve anything.
 NB: hibernating and booting solves this.
 
 I may have fixed some of your issues, could you please try the latest
 gma500-next and report back.
 
 https://github.com/patjak/drm-gma500.git gma500-next

Like I said, I am on vacation.
So it took a while before I had some time to spend on this experiment.
The good news, both problems seem to be solved on my hardware.

Bye,
Kero.

-- 
Are you master of your time here?
Are you master of your own fate?
   -- Deep Inside -- Exile -- To-Mera
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Standalone DRM application

[Byron Stanoszek]

David,

I'm developing a small application that uses libdrm (DRM ioctls) to change the
resolution of a single graphics display and show a framebuffer. I've run into
two problems with this implementation that I'm hoping you can address.


1. Each application is its own process, which is designed to control 1 graphics
display. This is unlike X, for instance, which could be configured to grab all
of the displays in the system at once.

Depending on our stackup, there can be as many as 4 displays connected to a
single graphics card. One process could open /dev/dri/card0 and call
drmModeSetCrtc() to initialize one of its displays to the requested resolution.
However, whenever a second process calls drmModeSetCrtc() to control a second
display on the same card, it gets -EPERM back from the ioctl.

I've traced this down to the following line in linux/drivers/gpu/drm/drm_drv.c:

DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),

If I remove the DRM_MASTER flag, then my application behaves correctly, and 4
separate processes can then control each individual display on the card without
issue.

My question is, is there any real benefit to restricting drm_mode_setcrtc()
with DRM_MASTER, or can we lose this flag in order to support one-process-per-
display programs like the above?


2. My application has the design requirement that screen 1 always refers to
the card that was initialized by the PC BIOS for bootup. This is the same card
that the Linux Console framebuffer will come up on by default, and therefore
extra processing is required to handle VT switches (e.g. pause the display,
restore original CRTC mode, etc.)

Depending on the Boot Display First [Onboard] or [PCI Slot] option in the
BIOS, this might mean either /dev/dri/card0 or /dev/dri/card1 becomes the
default VGA card, as set by the vga_set_default_device() call in
arch/x86/pci/fixup.c.

Is there a way in userspace to identify which card# is the default card? Or
alternatively, is there some way to get the underlying PCI bus/slot ID from a
/dev/dri/card# device.

Thanks,
 -Byron

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: mmotm 2013-04-17-16-02 uploaded (gpu/drm/qxl)

[Randy Dunlap]

On 04/17/13 16:03, a...@linux-foundation.org wrote:
 The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to
 
http://www.ozlabs.org/~akpm/mmotm/
 


I saw this in linux-next a few days ago and forgot to post it.

When CONFIG_DEBUG_FS is not enabled:


drivers/gpu/drm/qxl/qxl_ttm.c:568:33: error: 'qxl_mm_dump_table' undeclared 
(first use in this function)
drivers/gpu/drm/qxl/qxl_debugfs.c:76:2: error: implicit declaration of function 
'drm_debugfs_create_files' [-Werror=implicit-function-declaration]
drivers/gpu/drm/qxl/qxl_debugfs.c:84:2: error: implicit declaration of function 
'drm_debugfs_remove_files' [-Werror=implicit-function-declaration]


-- 
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/6] mm: use vma_pages() to replace (vm_end - vm_start) PAGE_SHIFT

[Michel Lespinasse]

On Mon, Apr 15, 2013 at 5:48 AM, Libin huawei.li...@huawei.com wrote:
 (*-vm_end - *-vm_start)  PAGE_SHIFT operation is implemented
 as a inline funcion vma_pages() in linux/mm.h, so using it.

 Signed-off-by: Libin huawei.li...@huawei.com

Looks good to me.

Reviewed-by: Michel Lespinasse wal...@google.com

-- 
Michel Walken Lespinasse
A program is never fully debugged until the last user dies.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] OMAPDSS: DPI: add dependency to DSI

[Christoph Fritz]

Hi Tomi

On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
 Tomi Valkeinen (38):
   OMAPDSS: add fields to panels' platform data
   OMAPDSS: DSI: remove DSI  DISPC clk divisors from dssdev
   OMAPDSS: HDMI: remove HDMI clk divisors from dssdev
   OMAPDSS: DPI: remove omap_dss_device uses
   OMAPDSS: DSI: remove omap_dss_device uses
   OMAPDSS: Taal: remove multi-panel support
   OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync
   OMAPDSS: add missing export for omap_dss_get_output()
   OMAPDSS: HDMI: init output earlier
   OMAPDSS: add output-name
   OMAPDSS: add output-dispc_channel
   OMAPDSS: DSI: delay dispc initialization
   OMAPDSS: DSI: fix DSI channel source initialization
   OMAPDSS: Taal: remove rotate  mirror support
   OMAPDSS: DPI: fix dpi_get_dsidev() for omap5
   OMAPDSS: DISPC: store core clk rate
   OMAPDSS: DSI: fix wrong unsigned long long use
   OMAPDSS: DSI: simplify dsi configuration
   OMAPDSS: DSI: get line buffer size at probe
   OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode
   OMAPDSS: DSI remove unneeded clk source setup code
   OMAPDSS: DISPC: add new clock calculation code
   OMAPDSS: DSS: add new clock calculation code
   OMAPDSS: DSI: add new clock calculation code
   OMAPDSS: SDI: use new clock calculation code
   OMAPDSS: DPI: use new clock calculation code

With linux-next this patch breaks compiling here because DPI now depends
on DSI - but my omap3 board here doesn't use DSI at all:

drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
‘dsi_hsdiv_calc’
drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’:
drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
‘dsi_get_pll_clkin’
drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
‘dsi_pll_calc’

Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want 
to merge it?

From: Christoph Fritz chf.fr...@googlemail.com
Date: Thu, 18 Apr 2013 10:26:54 +0200
Subject: [PATCH] OMAPDSS: DPI: add dependency to DSI

A dependency from DPI to DSI is introduced by commit 100c82623
OMAPDSS: DPI: use new clock calculation code.
This patch adds the dependency also on Kconfig-Level.

Signed-off-by: Christoph Fritz chf.fr...@googlemail.com
---
 drivers/video/omap2/dss/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index cb0f145..b4211c5 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -36,6 +36,7 @@ config OMAP2_DSS_COLLECT_IRQ_STATS
 config OMAP2_DSS_DPI
bool DPI support
default y
+   select OMAP2_DSS_DSI
help
  DPI Interface. This is the Parallel Display Interface.
 
-- 
1.7.10.4



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] OMAPDSS: DPI: add dependency to DSI

[Tomi Valkeinen]

On 2013-04-18 11:37, Christoph Fritz wrote:
 Hi Tomi
 
 On Mon, 2013-04-15 at 13:57 +0300, Tomi Valkeinen wrote:
 Tomi Valkeinen (38):
   OMAPDSS: add fields to panels' platform data
   OMAPDSS: DSI: remove DSI  DISPC clk divisors from dssdev
   OMAPDSS: HDMI: remove HDMI clk divisors from dssdev
   OMAPDSS: DPI: remove omap_dss_device uses
   OMAPDSS: DSI: remove omap_dss_device uses
   OMAPDSS: Taal: remove multi-panel support
   OMAPDSS: APPLY: remove dssdev from dss_mgr_wait_for_vsync
   OMAPDSS: add missing export for omap_dss_get_output()
   OMAPDSS: HDMI: init output earlier
   OMAPDSS: add output-name
   OMAPDSS: add output-dispc_channel
   OMAPDSS: DSI: delay dispc initialization
   OMAPDSS: DSI: fix DSI channel source initialization
   OMAPDSS: Taal: remove rotate  mirror support
   OMAPDSS: DPI: fix dpi_get_dsidev() for omap5
   OMAPDSS: DISPC: store core clk rate
   OMAPDSS: DSI: fix wrong unsigned long long use
   OMAPDSS: DSI: simplify dsi configuration
   OMAPDSS: DSI: get line buffer size at probe
   OMAPDSS: DSI: add enum omap_dss_dsi_trans_mode
   OMAPDSS: DSI remove unneeded clk source setup code
   OMAPDSS: DISPC: add new clock calculation code
   OMAPDSS: DSS: add new clock calculation code
   OMAPDSS: DSI: add new clock calculation code
   OMAPDSS: SDI: use new clock calculation code
   OMAPDSS: DPI: use new clock calculation code
 
 With linux-next this patch breaks compiling here because DPI now depends
 on DSI - but my omap3 board here doesn't use DSI at all:
 
 drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
 drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
 ‘dsi_hsdiv_calc’
 drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’:
 drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
 ‘dsi_get_pll_clkin’
 drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
 ‘dsi_pll_calc’
 
 Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be want 
 to merge it?

Thanks for reporting this. We shouldn't make DPI depend on DSI. We
should make dummy functions for the above when DSI is not enabled so
that DPI compiles. I'll make a fix.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] OMAPDSS: DPI: add dependency to DSI

[Tomi Valkeinen]

On 2013-04-18 12:09, Tomi Valkeinen wrote:
 On 2013-04-18 11:37, Christoph Fritz wrote:

 With linux-next this patch breaks compiling here because DPI now depends
 on DSI - but my omap3 board here doesn't use DSI at all:

 drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
 drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
 ‘dsi_hsdiv_calc’
 drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’:
 drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
 ‘dsi_get_pll_clkin’
 drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
 ‘dsi_pll_calc’

 Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be 
 want to merge it?
 
 Thanks for reporting this. We shouldn't make DPI depend on DSI. We
 should make dummy functions for the above when DSI is not enabled so
 that DPI compiles. I'll make a fix.

Patch below. Can you try it out? It works for me on Panda.

 Tomi

From d91bf4127056c68e423109e7c9b46bd0f0b1673a Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu, 18 Apr 2013 12:16:39 +0300
Subject: [PATCH] OMAPDSS: DPI: fix compilation if DSI not compiled in

Commit 100c826235793345efe06b3558cc9d36166b1e26 (OMAPDSS: DPI: use new
clock calculation code) breaks dpi.c compilation if DSI is not enabled
in the kernel configuration.

Fix compilation by adding dummy inline functions for the ones that dpi.c
references. The functions will never be called, as dpi.c knows that
there is no DSI device available.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dss.h |   31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index faaf358..8475893 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -277,6 +277,12 @@ int sdi_init_platform_driver(void) __init;
 void sdi_uninit_platform_driver(void) __exit;
 
 /* DSI */
+
+typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
+   unsigned long pll, void *data);
+typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
+   void *data);
+
 #ifdef CONFIG_OMAP2_DSS_DSI
 
 struct dentry;
@@ -295,10 +301,6 @@ u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
 
 unsigned long dsi_get_pll_clkin(struct platform_device *dsidev);
 
-typedef bool (*dsi_pll_calc_func)(int regn, int regm, unsigned long fint,
-   unsigned long pll, void *data);
-typedef bool (*dsi_hsdiv_calc_func)(int regm_dispc, unsigned long dispc,
-   void *data);
 bool dsi_hsdiv_calc(struct platform_device *dsidev, unsigned long pll,
unsigned long out_min, dsi_hsdiv_calc_func func, void *data);
 bool dsi_pll_calc(struct platform_device *dsidev, unsigned long clkin,
@@ -358,6 +360,27 @@ static inline struct platform_device 
*dsi_get_dsidev_from_id(int module)
 {
return NULL;
 }
+
+static inline unsigned long dsi_get_pll_clkin(struct platform_device *dsidev)
+{
+   return 0;
+}
+
+static inline bool dsi_hsdiv_calc(struct platform_device *dsidev,
+   unsigned long pll, unsigned long out_min,
+   dsi_hsdiv_calc_func func, void *data)
+{
+   return false;
+}
+
+static inline bool dsi_pll_calc(struct platform_device *dsidev,
+   unsigned long clkin,
+   unsigned long pll_min, unsigned long pll_max,
+   dsi_pll_calc_func func, void *data)
+{
+   return false;
+}
+
 #endif
 
 /* DPI */
-- 
1.7.10.4





signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] OMAPDSS: DPI: add dependency to DSI

[Christoph Fritz]

On Thu, 2013-04-18 at 12:21 +0300, Tomi Valkeinen wrote:
 On 2013-04-18 12:09, Tomi Valkeinen wrote:
  On 2013-04-18 11:37, Christoph Fritz wrote:
 
  With linux-next this patch breaks compiling here because DPI now depends
  on DSI - but my omap3 board here doesn't use DSI at all:
 
  drivers/video/omap2/dss/dpi.c: In function ‘dpi_calc_pll_cb’:
  drivers/video/omap2/dss/dpi.c:181: error: implicit declaration of function 
  ‘dsi_hsdiv_calc’
  drivers/video/omap2/dss/dpi.c: In function ‘dpi_dsi_clk_calc’:
  drivers/video/omap2/dss/dpi.c:201: error: implicit declaration of function 
  ‘dsi_get_pll_clkin’
  drivers/video/omap2/dss/dpi.c:212: error: implicit declaration of function 
  ‘dsi_pll_calc’
 
  Enabling OMAP2_DSS_DSI fixes this. This is my proposed patch. You may be 
  want to merge it?
  
  Thanks for reporting this. We shouldn't make DPI depend on DSI. We
  should make dummy functions for the above when DSI is not enabled so
  that DPI compiles. I'll make a fix.
 
 Patch below. Can you try it out? It works for me on Panda.

Thanks, it compiles here fine too.

and while booting I'm now getting as with 3.9-rc:
[0.409729] OMAP DSS rev 2.0
[0.410980] omapdss DPI error: can't get VDDS_DSI regulator
[0.410980] omapdss DPI error: device ips-056t init failed: -517

But here with linux-next (in contrast to 3.9-rc) removing all regulator
dependencies from drivers/video/omap2/dss/dpi.c does not make the trick.
The display stays dark :-( ...

 Thanks
  -- Christoph

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 06/10] video: ARM CLCD: Add DT CDF support

[Russell King - ARM Linux]

On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
 +#if defined(CONFIG_OF)
 +static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
 + struct display_entity_interface_params *params)
 +{
 + int r = params-p.tft_parallel.r_bits;
 + int g = params-p.tft_parallel.g_bits;
 + int b = params-p.tft_parallel.b_bits;
 +
 + /* Bypass pixel clock divider, data output on the falling edge */
 + panel-tim2 = TIM2_BCD | TIM2_IPC;
 +
 + /* TFT display, vert. comp. interrupt at the start of the back porch */
 + panel-cntl |= CNTL_LCDTFT | CNTL_LCDVCOMP(1);
 +
 + if (params-p.tft_parallel.r_b_swapped)
 + panel-cntl |= CNTL_BGR;

NAK.  Do not set this explicitly.  Note the driver talks about this being
the old way - this should not be used with the panel capabilities - and
in fact it will be overwritten.

Instead, you need to encode this into the capabilities by masking the
below with CLCD_CAP_RGB or CLCD_CAP_BGR depending on the ordering.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Standalone DRM application

[David Herrmann]

Hi

On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek gand...@winds.org wrote:
 David,

 I'm developing a small application that uses libdrm (DRM ioctls) to change
 the
 resolution of a single graphics display and show a framebuffer. I've run
 into
 two problems with this implementation that I'm hoping you can address.


 1. Each application is its own process, which is designed to control 1
 graphics
 display. This is unlike X, for instance, which could be configured to grab
 all
 of the displays in the system at once.

 Depending on our stackup, there can be as many as 4 displays connected to a
 single graphics card. One process could open /dev/dri/card0 and call
 drmModeSetCrtc() to initialize one of its displays to the requested
 resolution.
 However, whenever a second process calls drmModeSetCrtc() to control a
 second
 display on the same card, it gets -EPERM back from the ioctl.

 I've traced this down to the following line in
 linux/drivers/gpu/drm/drm_drv.c:

 DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
 DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),

 If I remove the DRM_MASTER flag, then my application behaves correctly, and
 4
 separate processes can then control each individual display on the card
 without
 issue.

 My question is, is there any real benefit to restricting drm_mode_setcrtc()
 with DRM_MASTER, or can we lose this flag in order to support
 one-process-per-
 display programs like the above?

Only one open-file can be DRM-Master. And only DRM-Master is allowed
to perform mode-setting. This is to prevent render-clients (like
OpenGL clients) to perform mode-setting, which should be restricted to
the compositor/...

In your scenario, you should share a single open-file between the
processes by passing the FDs to each. Or do all of that in a single
process. There is no way to split CRTCs/connectors between different
nodes or have multiple DRM-Masters on a single node at once. (There is
work going on to allow this, but it will take a while...)

You can acquire/drop DRM-Master via drmSetMaster/drmDropMaster.


 2. My application has the design requirement that screen 1 always refers
 to
 the card that was initialized by the PC BIOS for bootup. This is the same
 card
 that the Linux Console framebuffer will come up on by default, and therefore
 extra processing is required to handle VT switches (e.g. pause the display,
 restore original CRTC mode, etc.)

 Depending on the Boot Display First [Onboard] or [PCI Slot] option in the
 BIOS, this might mean either /dev/dri/card0 or /dev/dri/card1 becomes the
 default VGA card, as set by the vga_set_default_device() call in
 arch/x86/pci/fixup.c.

 Is there a way in userspace to identify which card# is the default card? Or
 alternatively, is there some way to get the underlying PCI bus/slot ID from
 a
 /dev/dri/card# device.

If your DRM card is a PCI device, you can use the sysfs boot_vga
attribute of the parent PCI device.
(/sys/class/drm/card0/device/boot_vga)

Regards
David
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/radeon: raise UVD clocks only on demand

[Christian König]

From: Christian König christian.koe...@amd.com

That not only saves some power, but also solves problems with
older chips where an idle UVD block on higher clocks can
cause problems.

Signed-off-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/radeon.h |2 ++
 drivers/gpu/drm/radeon/radeon_cs.c  |4 
 drivers/gpu/drm/radeon/radeon_uvd.c |   30 --
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 18904fb..deafb54 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1143,6 +1143,7 @@ struct radeon_uvd {
uint64_tgpu_addr;
atomic_thandles[RADEON_MAX_UVD_HANDLES];
struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
+   struct delayed_work idle_work;
 };
 
 int radeon_uvd_init(struct radeon_device *rdev);
@@ -1157,6 +1158,7 @@ void radeon_uvd_force_into_uvd_segment(struct radeon_bo 
*rbo);
 void radeon_uvd_free_handles(struct radeon_device *rdev,
 struct drm_file *filp);
 int radeon_uvd_cs_parse(struct radeon_cs_parser *parser);
+void radeon_uvd_note_usage(struct radeon_device *rdev);
 
 struct r600_audio {
int channels;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index c740707..7e265a5 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -549,6 +549,10 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
r = radeon_cs_handle_lockup(rdev, r);
return r;
}
+
+   if (parser.ring == R600_RING_TYPE_UVD_INDEX)
+   radeon_uvd_note_usage(rdev);
+
r = radeon_cs_ib_chunk(rdev, parser);
if (r) {
goto out;
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index 15580fb..0312a7f 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -36,6 +36,9 @@
 #include radeon.h
 #include r600d.h
 
+/* 1 second timeout */
+#define UVD_IDLE_TIMEOUT_MS1000
+
 /* Firmware Names */
 #define FIRMWARE_RV710 radeon/RV710_uvd.bin
 #define FIRMWARE_CYPRESS   radeon/CYPRESS_uvd.bin
@@ -47,6 +50,8 @@ MODULE_FIRMWARE(FIRMWARE_CYPRESS);
 MODULE_FIRMWARE(FIRMWARE_SUMO);
 MODULE_FIRMWARE(FIRMWARE_TAHITI);
 
+static void radeon_uvd_idle_work_handler(struct work_struct *work);
+
 int radeon_uvd_init(struct radeon_device *rdev)
 {
struct platform_device *pdev;
@@ -54,6 +59,8 @@ int radeon_uvd_init(struct radeon_device *rdev)
const char *fw_name;
int i, r;
 
+   INIT_DELAYED_WORK(rdev-uvd.idle_work, radeon_uvd_idle_work_handler);
+
pdev = platform_device_register_simple(radeon_uvd, 0, NULL, 0);
r = IS_ERR(pdev);
if (r) {
@@ -188,8 +195,6 @@ int radeon_uvd_resume(struct radeon_device *rdev)
 
radeon_bo_unreserve(rdev-uvd.vcpu_bo);
 
-   radeon_set_uvd_clocks(rdev, 53300, 4);
-
return 0;
 }
 
@@ -666,3 +671,24 @@ int radeon_uvd_get_destroy_msg(struct radeon_device *rdev, 
int ring,
 
return radeon_uvd_send_msg(rdev, ring, bo, fence);
 }
+
+static void radeon_uvd_idle_work_handler(struct work_struct *work)
+{
+   struct radeon_device *rdev =
+   container_of(work, struct radeon_device, uvd.idle_work.work);
+
+   if (radeon_fence_count_emitted(rdev, R600_RING_TYPE_UVD_INDEX) == 0)
+   radeon_set_uvd_clocks(rdev, 0, 0);
+   else
+   schedule_delayed_work(rdev-uvd.idle_work,
+ msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS));
+}
+
+void radeon_uvd_note_usage(struct radeon_device *rdev)
+{
+   bool set_clocks = !cancel_delayed_work_sync(rdev-uvd.idle_work);
+   set_clocks = schedule_delayed_work(rdev-uvd.idle_work,
+   
msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS));
+   if (set_clocks)
+   radeon_set_uvd_clocks(rdev, 53300, 4);
+}
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/radeon: put UVD PLLs in bypass mode

[Christian König]

From: Christian König christian.koe...@amd.com

Just power down the PLL when we get a VCLK or DCLK of zero.
Enabling the bypass mode early should also allow us to
switch UVD clocks on the fly.

Signed-off-by: Christian König christian.koe...@amd.com
---
 drivers/gpu/drm/radeon/evergreen.c |   22 ++
 drivers/gpu/drm/radeon/rv770.c |   20 +---
 drivers/gpu/drm/radeon/si.c|   22 ++
 3 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 124c193..facfa84 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -189,6 +189,20 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
u32 vclk, u32 dclk)
unsigned vco_freq;
int r;
 
+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   /* put PLL in bypass mode */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
+
+   if (!vclk || !dclk) {
+   /* keep the Bypass mode, put PLL to sleep */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   return 0;
+   }
+
/* loop through vco from low to high */
for (vco_freq = 125000; vco_freq = 25; vco_freq += 100) {
unsigned fb_div = vco_freq / rdev-clock.spll.reference_freq * 
16384;
@@ -236,14 +250,6 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
u32 vclk, u32 dclk)
 
mdelay(1);
 
-   /* bypass vclk and dclk with bclk */
-   WREG32_P(CG_UPLL_FUNC_CNTL_2,
-   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
-   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
-
-   /* put PLL in bypass mode */
-   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
-
r = evergreen_uvd_send_upll_ctlreq(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 777f537..59065ba 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -100,6 +100,17 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
if (rdev-family == CHIP_RV740)
return evergreen_set_uvd_clocks(rdev, vclk, dclk);
 
+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   if (!vclk || !dclk) {
+   /* keep the Bypass mode, put PLL to sleep */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   return 0;
+   }
+
/* loop through vco from low to high */
vco_min = max(max(vco_min, vclk), dclk);
for (vco_freq = vco_min; vco_freq = vco_max; vco_freq += 500) {
@@ -139,16 +150,11 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
}
}
 
-   /* bypass vclk and dclk with bclk */
-   WREG32_P(CG_UPLL_FUNC_CNTL_2,
-VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
-~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
-
/* set UPLL_FB_DIV to 0x5 */
WREG32_P(CG_UPLL_FUNC_CNTL_3, UPLL_FB_DIV(0x5), ~UPLL_FB_DIV_MASK);
 
-   /* deassert UPLL_RESET */
-   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_RESET_MASK);
+   /* deassert UPLL_RESET and UPLL_SLEEP */
+   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~(UPLL_RESET_MASK | UPLL_SLEEP_MASK));
 
/* assert BYPASS EN and FB_DIV[0] - ??? why? */
WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index aa2c555..b7d78f2 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4680,6 +4680,20 @@ int si_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
unsigned vco_freq;
int r;
 
+   /* bypass vclk and dclk with bclk */
+   WREG32_P(CG_UPLL_FUNC_CNTL_2,
+   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
+   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
+
+   /* put PLL in bypass mode */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, ~UPLL_BYPASS_EN_MASK);
+
+   if (!vclk || !dclk) {
+   /* keep the Bypass mode, put PLL to sleep */
+   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, ~UPLL_SLEEP_MASK);
+   return 0;
+   }
+
/* loop through vco from low to high */
for (vco_freq = 125000; vco_freq = 25; vco_freq += 100) {
unsigned fb_div = vco_freq / rdev-clock.spll.reference_freq * 
16384;
@@ -4730,14 +4744,6 @@ int si_set_uvd_clocks(struct radeon_device *rdev, u32 
vclk, u32 dclk)
 

Re: [PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Laurent Pinchart]

Hi Ville,

Thank you for the patch.

On Wednesday 17 April 2013 22:18:01 ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  tests/modetest/buffers.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)
 
 diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
 index 5086381..6b117b4 100644
 --- a/tests/modetest/buffers.c
 +++ b/tests/modetest/buffers.c
 @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
 *planes[3], unsigned int width, #define BLUE  0
 
  static void
 -make_pwetty(void *data, int width, int height, int stride)
 +make_pwetty(void *data, int width, int height, int stride, int rgb16)

What about passing the format 4cc instead ?

  {
  #ifdef HAVE_CAIRO
   cairo_surface_t *surface;
 @@ -609,7 +609,7 @@ make_pwetty(void *data, int width, int height, int
 stride) int x, y;
 
   surface = cairo_image_surface_create_for_data(data,
 -   CAIRO_FORMAT_ARGB32,
 +   rgb16 ? 
 CAIRO_FORMAT_RGB16_565 : 
CAIRO_FORMAT_ARGB32,
 width, height,
 stride);
   cr = cairo_create(surface);
 @@ -716,6 +716,7 @@ static void
  fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
unsigned int width, unsigned int height, unsigned int stride)
  {
 + unsigned char *mem_base = mem;
   unsigned int x, y;
 
   for (y = 0; y  height; ++y) {
 @@ -732,6 +733,8 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned
 char *mem, }
   mem += stride;
   }
 +
 + make_pwetty(mem_base, width, height, stride, 1);
  }
 
  static void
 @@ -777,7 +780,7 @@ fill_tiles_rgb32(const struct rgb_info *rgb, unsigned
 char *mem, mem += stride;
   }
 
 - make_pwetty(mem_base, width, height, stride);
 + make_pwetty(mem_base, width, height, stride, 0);
  }
 
  static void

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 2/5] modetest: Fix pitches, somewhat

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:02 ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 libkms only has the xrgb format, so we're overallocating the bo by
 quite a lot in some cases. But we still need to get the pitch from the
 libkms since it's the driver that decides how to align it.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  tests/modetest/buffers.c | 34 ++
  1 file changed, 10 insertions(+), 24 deletions(-)
 
 diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
 index 6b117b4..7f534a1 100644
 --- a/tests/modetest/buffers.c
 +++ b/tests/modetest/buffers.c
 @@ -948,9 +948,9 @@ create_test_buffer(struct kms_driver *kms, unsigned int
 format, case DRM_FORMAT_VYUY:
   case DRM_FORMAT_YUYV:
   case DRM_FORMAT_YVYU:
 - pitches[0] = width * 2;
   offsets[0] = 0;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
 + kms_bo_get_prop(bo, KMS_PITCH, pitches[0]);
 
   planes[0] = virtual;
   break;
 @@ -959,11 +959,11 @@ create_test_buffer(struct kms_driver *kms, unsigned
 int format, case DRM_FORMAT_NV21:
   case DRM_FORMAT_NV16:
   case DRM_FORMAT_NV61:
 - pitches[0] = width;
   offsets[0] = 0;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
 - pitches[1] = width;
 - offsets[1] = width * height;
 + kms_bo_get_prop(bo, KMS_PITCH, pitches[0]);
 + pitches[1] = pitches[0];
 + offsets[1] = pitches[0] * height;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[1]);
 
   planes[0] = virtual;
 @@ -971,14 +971,14 @@ create_test_buffer(struct kms_driver *kms, unsigned
 int format, break;
 
   case DRM_FORMAT_YVU420:
 - pitches[0] = width;
   offsets[0] = 0;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
 - pitches[1] = width / 2;
 - offsets[1] = width * height;
 + kms_bo_get_prop(bo, KMS_PITCH, pitches[0]);
 + pitches[1] = pitches[0] / 2;
 + offsets[1] = pitches[0] * height;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[1]);
 - pitches[2] = width / 2;
 - offsets[2] = offsets[1] + (width * height) / 4;
 + pitches[2] = pitches[1];
 + offsets[2] = offsets[1] + pitches[1] * height / 2;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[2]);
 
   planes[0] = virtual;
 @@ -989,29 +989,15 @@ create_test_buffer(struct kms_driver *kms, unsigned
 int format, case DRM_FORMAT_RGB565:
   case DRM_FORMAT_ARGB1555:
   case DRM_FORMAT_XRGB1555:
 - pitches[0] = width * 2;
 - offsets[0] = 0;
 - kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
 -
 - planes[0] = virtual;
 - break;
 -
   case DRM_FORMAT_BGR888:
   case DRM_FORMAT_RGB888:
 - pitches[0] = width * 3;
 - offsets[0] = 0;
 - kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
 -
 - planes[0] = virtual;
 - break;
 -
   case DRM_FORMAT_ARGB:
   case DRM_FORMAT_BGRA:
   case DRM_FORMAT_XRGB:
   case DRM_FORMAT_BGRX:
 - pitches[0] = width * 4;
   offsets[0] = 0;
   kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
 + kms_bo_get_prop(bo, KMS_PITCH, pitches[0]);
 
   planes[0] = virtual;
   break;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm/radeon: minor HDMI improvements

[Alex Deucher]

On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
 I've managed to track fglrx operations on HDMI regs, so we can finally setup
 everything in (hopefully) the correct way and order.

 This changes HDMI setup on Evergreen to mostly match fglrx and was tested on:
 1) AMD Radeon HD 6320 (PALM == DCE41)
 2) AMD Radeon HD 6970M (BARTS == DCE5)
 No regressions noticed, I can still play audio, including LPCM, AC3 and DTS.

 Unfortunately I don't have any DCE4 hardware to test this, but that changes
 shouldn't cause any regressions. I hope that with such improvements we will
 finally able to enable audio by default.

I've applied patches 1, 4, 5, 6.  For patch 2, I'd prefer we just not
enable the interrupts rather than removing the code altogether at this
point.  See the attached patch.  For patch 3, none of the registers
mentioned are directly related to audio setup.

Alex


 Rafał Miłecki (6):
   drm/radeon: add helpers for masking and setting bits in regs
   drm/radeon: remove HDMI interrupts on Evergreen
   drm/radeon: add some HDMI comments
   drm/radeon/evergreen: setup HDMI before enabling it
   drm/radeon/evergreen: reorder HDMI setup
   drm/radeon/evergreen: write default channel numbers

  drivers/gpu/drm/radeon/evergreen.c  |  127 
 +--
  drivers/gpu/drm/radeon/evergreen_hdmi.c |   77 +++
  drivers/gpu/drm/radeon/evergreend.h |1 +
  drivers/gpu/drm/radeon/r600_hdmi.c  |   16 ++--
  drivers/gpu/drm/radeon/radeon.h |2 +
  drivers/gpu/drm/radeon/radeon_display.c |5 ++
  6 files changed, 76 insertions(+), 152 deletions(-)

 --
 1.7.10.4

From 2a011eb7d763257e75b08c98adfb70a8d35ec6ae Mon Sep 17 00:00:00 2001
From: Alex Deucher alexander.deuc...@amd.com
Date: Thu, 18 Apr 2013 09:42:13 -0400
Subject: [PATCH] drm/radeon: disable audio format interrupts on Evergreen

The audio format change interrupts are an aid in debugging,
but not required for operation.

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
---
 drivers/gpu/drm/radeon/r600_hdmi.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c
index e419b98..95397b2 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -461,7 +461,9 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
 
 	if (rdev-irq.installed) {
 		/* if irq is available use it */
-		radeon_irq_kms_enable_afmt(rdev, dig-afmt-id);
+		/* XXX: shouldn't need this on any asics.  Double check DCE2/3 */
+		if (!ASIC_IS_DCE4(rdev))
+			radeon_irq_kms_enable_afmt(rdev, dig-afmt-id);
 	}
 
 	dig-afmt-enabled = true;
-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 5/5] modetest: Reduce the length of the connector type string

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:05 ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Spelling out eDP or DP make for a ridicilously long string which plays
 havoc with formatting. Just say eDP or DP.
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  tests/modetest/modetest.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
 index 27cd2ce..8afd2b1 100644
 --- a/tests/modetest/modetest.c
 +++ b/tests/modetest/modetest.c
 @@ -106,11 +106,11 @@ struct type_name connector_type_names[] = {
   { DRM_MODE_CONNECTOR_LVDS, LVDS },
   { DRM_MODE_CONNECTOR_Component, component },
   { DRM_MODE_CONNECTOR_9PinDIN, 9-pin DIN },
 - { DRM_MODE_CONNECTOR_DisplayPort, displayport },
 + { DRM_MODE_CONNECTOR_DisplayPort, DP },
   { DRM_MODE_CONNECTOR_HDMIA, HDMI-A },
   { DRM_MODE_CONNECTOR_HDMIB, HDMI-B },
   { DRM_MODE_CONNECTOR_TV, TV },
 - { DRM_MODE_CONNECTOR_eDP, embedded displayport },
 + { DRM_MODE_CONNECTOR_eDP, eDP },
  };
 
  type_name_fn(connector_type)
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 4/5] modetest: Print possible_crtcs for planes

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:04 ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  tests/modetest/modetest.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
 index c91bb9d..27cd2ce 100644
 --- a/tests/modetest/modetest.c
 +++ b/tests/modetest/modetest.c
 @@ -429,7 +429,7 @@ static void dump_planes(void)
   }
 
   printf(Planes:\n);
 - printf(id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\n);
 + printf(id\tcrtc\tfb\tCRTC x,y\tx,y\tgamma size\tpossible crtcs\n);
   for (i = 0; i  plane_resources-count_planes; i++) {
   ovr = drmModeGetPlane(fd, plane_resources-planes[i]);
   if (!ovr) {
 @@ -438,10 +438,10 @@ static void dump_planes(void)
   continue;
   }
 
 - printf(%d\t%d\t%d\t%d,%d\t\t%d,%d\t%d\n,
 + printf(%d\t%d\t%d\t%d,%d\t\t%d,%d\t%-8d\t0x%08x\n,
  ovr-plane_id, ovr-crtc_id, ovr-fb_id,
  ovr-crtc_x, ovr-crtc_y, ovr-x, ovr-y,
 -ovr-gamma_size);
 +ovr-gamma_size, ovr-possible_crtcs);
 
   if (!ovr-count_formats)
   continue;
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/radeon: cleanup UVD address checks

[Alex Deucher]

On Thu, Apr 18, 2013 at 4:42 AM, Christian König
deathsim...@vodafone.de wrote:
 From: Christian König christian.koe...@amd.com

 Message and feedback buffers must be at start of
 VRAM, not at start of address space.

 Signed-off-by: Christian König christian.koe...@amd.com

Looks good.  Both applied.

Alex

 ---
  drivers/gpu/drm/radeon/radeon_uvd.c |   26 ++
  1 file changed, 14 insertions(+), 12 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
 b/drivers/gpu/drm/radeon/radeon_uvd.c
 index 30a9460..2fb4d6c 100644
 --- a/drivers/gpu/drm/radeon/radeon_uvd.c
 +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
 @@ -415,24 +415,26 @@ static int radeon_uvd_cs_reloc(struct radeon_cs_parser 
 *p,
 return -EINVAL;
 }

 -   if (cmd == 0) {
 -   if (end  0xF000) {
 -   DRM_ERROR(msg buffer %LX-%LX out of 256MB 
 segment!\n,
 - start, end);
 -   return -EINVAL;
 -   }
 -
 -   r = radeon_uvd_cs_msg(p, reloc-robj, offset, buf_sizes);
 -   if (r)
 -   return r;
 +   if ((start  28) != (end  28)) {
 +   DRM_ERROR(reloc %LX-%LX crossing 256MB boundary!\n,
 + start, end);
 +   return -EINVAL;
 }

 -   if ((start  0xF000) != (end  0xF000)) {
 -   DRM_ERROR(reloc %LX-%LX crossing 256MB boundary!\n,
 +   /* TODO: is this still necessary on NI+ ? */
 +   if ((cmd == 0 || cmd == 0x3) 
 +   (start  28) != (p-rdev-uvd.gpu_addr  28)) {
 +   DRM_ERROR(msg/fb buffer %LX-%LX out of 256MB segment!\n,
   start, end);
 return -EINVAL;
 }

 +   if (cmd == 0) {
 +   r = radeon_uvd_cs_msg(p, reloc-robj, offset, buf_sizes);
 +   if (r)
 +   return r;
 +   }
 +
 return 0;
  }

 --
 1.7.10.4

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/radeon: put UVD PLLs in bypass mode

[Alex Deucher]

On Thu, Apr 18, 2013 at 9:25 AM, Christian König
deathsim...@vodafone.de wrote:
 From: Christian König christian.koe...@amd.com

 Just power down the PLL when we get a VCLK or DCLK of zero.
 Enabling the bypass mode early should also allow us to
 switch UVD clocks on the fly.

 Signed-off-by: Christian König christian.koe...@amd.com

Looks good.  both applied.

Alex

 ---
  drivers/gpu/drm/radeon/evergreen.c |   22 ++
  drivers/gpu/drm/radeon/rv770.c |   20 +---
  drivers/gpu/drm/radeon/si.c|   22 ++
  3 files changed, 41 insertions(+), 23 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/evergreen.c 
 b/drivers/gpu/drm/radeon/evergreen.c
 index 124c193..facfa84 100644
 --- a/drivers/gpu/drm/radeon/evergreen.c
 +++ b/drivers/gpu/drm/radeon/evergreen.c
 @@ -189,6 +189,20 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
 u32 vclk, u32 dclk)
 unsigned vco_freq;
 int r;

 +   /* bypass vclk and dclk with bclk */
 +   WREG32_P(CG_UPLL_FUNC_CNTL_2,
 +   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
 +   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
 +
 +   /* put PLL in bypass mode */
 +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
 ~UPLL_BYPASS_EN_MASK);
 +
 +   if (!vclk || !dclk) {
 +   /* keep the Bypass mode, put PLL to sleep */
 +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, 
 ~UPLL_SLEEP_MASK);
 +   return 0;
 +   }
 +
 /* loop through vco from low to high */
 for (vco_freq = 125000; vco_freq = 25; vco_freq += 100) {
 unsigned fb_div = vco_freq / rdev-clock.spll.reference_freq 
 * 16384;
 @@ -236,14 +250,6 @@ int evergreen_set_uvd_clocks(struct radeon_device *rdev, 
 u32 vclk, u32 dclk)

 mdelay(1);

 -   /* bypass vclk and dclk with bclk */
 -   WREG32_P(CG_UPLL_FUNC_CNTL_2,
 -   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
 -   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
 -
 -   /* put PLL in bypass mode */
 -   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
 ~UPLL_BYPASS_EN_MASK);
 -
 r = evergreen_uvd_send_upll_ctlreq(rdev);
 if (r)
 return r;
 diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
 index 777f537..59065ba 100644
 --- a/drivers/gpu/drm/radeon/rv770.c
 +++ b/drivers/gpu/drm/radeon/rv770.c
 @@ -100,6 +100,17 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 
 vclk, u32 dclk)
 if (rdev-family == CHIP_RV740)
 return evergreen_set_uvd_clocks(rdev, vclk, dclk);

 +   /* bypass vclk and dclk with bclk */
 +   WREG32_P(CG_UPLL_FUNC_CNTL_2,
 +VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
 +~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
 +
 +   if (!vclk || !dclk) {
 +   /* keep the Bypass mode, put PLL to sleep */
 +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, 
 ~UPLL_SLEEP_MASK);
 +   return 0;
 +   }
 +
 /* loop through vco from low to high */
 vco_min = max(max(vco_min, vclk), dclk);
 for (vco_freq = vco_min; vco_freq = vco_max; vco_freq += 500) {
 @@ -139,16 +150,11 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, 
 u32 vclk, u32 dclk)
 }
 }

 -   /* bypass vclk and dclk with bclk */
 -   WREG32_P(CG_UPLL_FUNC_CNTL_2,
 -VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
 -~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
 -
 /* set UPLL_FB_DIV to 0x5 */
 WREG32_P(CG_UPLL_FUNC_CNTL_3, UPLL_FB_DIV(0x5), 
 ~UPLL_FB_DIV_MASK);

 -   /* deassert UPLL_RESET */
 -   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~UPLL_RESET_MASK);
 +   /* deassert UPLL_RESET and UPLL_SLEEP */
 +   WREG32_P(CG_UPLL_FUNC_CNTL, 0, ~(UPLL_RESET_MASK | UPLL_SLEEP_MASK));

 /* assert BYPASS EN and FB_DIV[0] - ??? why? */
 WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
 ~UPLL_BYPASS_EN_MASK);
 diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
 index aa2c555..b7d78f2 100644
 --- a/drivers/gpu/drm/radeon/si.c
 +++ b/drivers/gpu/drm/radeon/si.c
 @@ -4680,6 +4680,20 @@ int si_set_uvd_clocks(struct radeon_device *rdev, u32 
 vclk, u32 dclk)
 unsigned vco_freq;
 int r;

 +   /* bypass vclk and dclk with bclk */
 +   WREG32_P(CG_UPLL_FUNC_CNTL_2,
 +   VCLK_SRC_SEL(1) | DCLK_SRC_SEL(1),
 +   ~(VCLK_SRC_SEL_MASK | DCLK_SRC_SEL_MASK));
 +
 +   /* put PLL in bypass mode */
 +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_BYPASS_EN_MASK, 
 ~UPLL_BYPASS_EN_MASK);
 +
 +   if (!vclk || !dclk) {
 +   /* keep the Bypass mode, put PLL to sleep */
 +   WREG32_P(CG_UPLL_FUNC_CNTL, UPLL_SLEEP_MASK, 
 ~UPLL_SLEEP_MASK);
 +   return 0;
 +   }
 +
 /* loop through vco from low to high */
 for (vco_freq = 

Re: [PATCH libdrm 3/5] modetest: Add support for all 16/32 bpp RGB formats

[Laurent Pinchart]

On Wednesday 17 April 2013 22:18:03 ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

 ---
  tests/modetest/buffers.c | 120 ++--
  1 file changed, 115 insertions(+), 5 deletions(-)
 
 diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
 index 7f534a1..3b1685c 100644
 --- a/tests/modetest/buffers.c
 +++ b/tests/modetest/buffers.c
 @@ -102,17 +102,44 @@ static const struct format_info format_info[] = {
   /* YUV planar */
   { DRM_FORMAT_YVU420, YV12, MAKE_YUV_INFO(YUV_YCrCb, 2, 2, 1) },
   /* RGB16 */
 + { DRM_FORMAT_ARGB, AR12, MAKE_RGB_INFO(4, 8, 4, 4, 4, 0, 4, 12) },
 + { DRM_FORMAT_XRGB, XR12, MAKE_RGB_INFO(4, 8, 4, 4, 4, 0, 0, 0) },
 + { DRM_FORMAT_ABGR, AB12, MAKE_RGB_INFO(4, 0, 4, 4, 4, 8, 4, 12) },
 + { DRM_FORMAT_XBGR, XB12, MAKE_RGB_INFO(4, 0, 4, 4, 4, 8, 0, 0) },
 + { DRM_FORMAT_RGBA, RA12, MAKE_RGB_INFO(4, 12, 4, 8, 4, 4, 4, 0) },
 + { DRM_FORMAT_RGBX, RX12, MAKE_RGB_INFO(4, 12, 4, 8, 4, 4, 0, 0) },
 + { DRM_FORMAT_BGRA, BA12, MAKE_RGB_INFO(4, 4, 4, 8, 4, 12, 4, 0) },
 + { DRM_FORMAT_BGRX, BX12, MAKE_RGB_INFO(4, 4, 4, 8, 4, 12, 0, 0) },
   { DRM_FORMAT_ARGB1555, AR15, MAKE_RGB_INFO(5, 10, 5, 5, 5, 0, 1, 15) 
 },
   { DRM_FORMAT_XRGB1555, XR15, MAKE_RGB_INFO(5, 10, 5, 5, 5, 0, 0, 0) },
 + { DRM_FORMAT_ABGR1555, AB15, MAKE_RGB_INFO(5, 0, 5, 5, 5, 10, 1, 15) 
 },
 + { DRM_FORMAT_XBGR1555, XB15, MAKE_RGB_INFO(5, 0, 5, 5, 5, 10, 0, 0) },
 + { DRM_FORMAT_RGBA5551, RA15, MAKE_RGB_INFO(5, 11, 5, 6, 5, 1, 1, 0) },
 + { DRM_FORMAT_RGBX5551, RX15, MAKE_RGB_INFO(5, 11, 5, 6, 5, 1, 0, 0) },
 + { DRM_FORMAT_BGRA5551, BA15, MAKE_RGB_INFO(5, 1, 5, 6, 5, 11, 1, 0) },
 + { DRM_FORMAT_BGRX5551, BX15, MAKE_RGB_INFO(5, 1, 5, 6, 5, 11, 0, 0) },
   { DRM_FORMAT_RGB565, RG16, MAKE_RGB_INFO(5, 11, 6, 5, 5, 0, 0, 0) },
 + { DRM_FORMAT_BGR565, BG16, MAKE_RGB_INFO(5, 0, 6, 5, 5, 11, 0, 0) },
   /* RGB24 */
   { DRM_FORMAT_BGR888, BG24, MAKE_RGB_INFO(8, 0, 8, 8, 8, 16, 0, 0) },
   { DRM_FORMAT_RGB888, RG24, MAKE_RGB_INFO(8, 16, 8, 8, 8, 0, 0, 0) },
   /* RGB32 */
   { DRM_FORMAT_ARGB, AR24, MAKE_RGB_INFO(8, 16, 8, 8, 8, 0, 8, 24) 
 },
 - { DRM_FORMAT_BGRA, BA24, MAKE_RGB_INFO(8, 8, 8, 16, 8, 24, 8, 0) 
 },
   { DRM_FORMAT_XRGB, XR24, MAKE_RGB_INFO(8, 16, 8, 8, 8, 0, 0, 0) },
 + { DRM_FORMAT_ABGR, AB24, MAKE_RGB_INFO(8, 0, 8, 8, 8, 16, 8, 24) 
 },
 + { DRM_FORMAT_XBGR, XB24, MAKE_RGB_INFO(8, 0, 8, 8, 8, 16, 0, 0) },
 + { DRM_FORMAT_RGBA, RA24, MAKE_RGB_INFO(8, 24, 8, 16, 8, 8, 8, 0) 
 },
 + { DRM_FORMAT_RGBX, RX24, MAKE_RGB_INFO(8, 24, 8, 16, 8, 8, 0, 0) 
 },
 + { DRM_FORMAT_BGRA, BA24, MAKE_RGB_INFO(8, 8, 8, 16, 8, 24, 8, 0) 
 },
   { DRM_FORMAT_BGRX, BX24, MAKE_RGB_INFO(8, 8, 8, 16, 8, 24, 0, 0) 
 },
 + { DRM_FORMAT_ARGB2101010, AR30, MAKE_RGB_INFO(10, 20, 10, 10, 10, 0, 
 2,
 30) }, +  { DRM_FORMAT_XRGB2101010, XR30, MAKE_RGB_INFO(10, 20, 10, 10,
 10, 0, 0, 0) }, + { DRM_FORMAT_ABGR2101010, AB30, MAKE_RGB_INFO(10, 0,
 10, 10, 10, 20, 2, 30) }, +   { DRM_FORMAT_XBGR2101010, XB30,
 MAKE_RGB_INFO(10, 0, 10, 10, 10, 20, 0, 0) }, +   { 
 DRM_FORMAT_RGBA1010102,
 RA30, MAKE_RGB_INFO(10, 22, 10, 12, 10, 2, 2, 0) }, +   {
 DRM_FORMAT_RGBX1010102, RX30, MAKE_RGB_INFO(10, 22, 10, 12, 10, 2, 0, 0)
 }, +  { DRM_FORMAT_BGRA1010102, BA30, MAKE_RGB_INFO(10, 2, 10, 12, 10, 
22,
 2, 0) }, +{ DRM_FORMAT_BGRX1010102, BX30, MAKE_RGB_INFO(10, 2, 10, 12,
 10, 22, 0, 0) }, };
 
  unsigned int format_fourcc(const char *name)
 @@ -577,19 +604,47 @@ fill_smpte(const struct format_info *info, void
 *planes[3], unsigned int width, return fill_smpte_yuv_planar(info-yuv,
 planes[0], planes[1],
planes[2], width, height, stride);
 
 + case DRM_FORMAT_ARGB:
 + case DRM_FORMAT_XRGB:
 + case DRM_FORMAT_ABGR:
 + case DRM_FORMAT_XBGR:
 + case DRM_FORMAT_RGBA:
 + case DRM_FORMAT_RGBX:
 + case DRM_FORMAT_BGRA:
 + case DRM_FORMAT_BGRX:
   case DRM_FORMAT_RGB565:
 + case DRM_FORMAT_BGR565:
   case DRM_FORMAT_ARGB1555:
   case DRM_FORMAT_XRGB1555:
 + case DRM_FORMAT_ABGR1555:
 + case DRM_FORMAT_XBGR1555:
 + case DRM_FORMAT_RGBA5551:
 + case DRM_FORMAT_RGBX5551:
 + case DRM_FORMAT_BGRA5551:
 + case DRM_FORMAT_BGRX5551:
   return fill_smpte_rgb16(info-rgb, planes[0],
   width, height, stride);
 +
   case DRM_FORMAT_BGR888:
   case DRM_FORMAT_RGB888:
   return fill_smpte_rgb24(info-rgb, planes[0],
   width, height, stride);
   case DRM_FORMAT_ARGB:
 - case 

Re: [PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Ville Syrjälä]

On Thu, Apr 18, 2013 at 03:43:23PM +0200, Laurent Pinchart wrote:
 Hi Ville,
 
 Thank you for the patch.
 
 On Wednesday 17 April 2013 22:18:01 ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   tests/modetest/buffers.c | 9 ++---
   1 file changed, 6 insertions(+), 3 deletions(-)
  
  diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
  index 5086381..6b117b4 100644
  --- a/tests/modetest/buffers.c
  +++ b/tests/modetest/buffers.c
  @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
  *planes[3], unsigned int width, #define BLUE  0
  
   static void
  -make_pwetty(void *data, int width, int height, int stride)
  +make_pwetty(void *data, int width, int height, int stride, int rgb16)
 
 What about passing the format 4cc instead ?

It's a bit more work since I need to pass the whole format_info
down from fill_tiles(). But I can make a v2 with that change.

   {
   #ifdef HAVE_CAIRO
  cairo_surface_t *surface;
  @@ -609,7 +609,7 @@ make_pwetty(void *data, int width, int height, int
  stride) int x, y;
  
  surface = cairo_image_surface_create_for_data(data,
  - CAIRO_FORMAT_ARGB32,
  + rgb16 ? 
  CAIRO_FORMAT_RGB16_565 : 
 CAIRO_FORMAT_ARGB32,
width, height,
stride);
  cr = cairo_create(surface);
  @@ -716,6 +716,7 @@ static void
   fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
   unsigned int width, unsigned int height, unsigned int stride)
   {
  +   unsigned char *mem_base = mem;
  unsigned int x, y;
  
  for (y = 0; y  height; ++y) {
  @@ -732,6 +733,8 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned
  char *mem, }
  mem += stride;
  }
  +
  +   make_pwetty(mem_base, width, height, stride, 1);
   }
  
   static void
  @@ -777,7 +780,7 @@ fill_tiles_rgb32(const struct rgb_info *rgb, unsigned
  char *mem, mem += stride;
  }
  
  -   make_pwetty(mem_base, width, height, stride);
  +   make_pwetty(mem_base, width, height, stride, 0);
   }
  
   static void
 
 -- 
 Regards,
 
 Laurent Pinchart

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: libdrm release next week ?

[Jerome Glisse]

On Fri, Apr 12, 2013 at 10:06 AM, Laurent Pinchart 
laurent.pinch...@ideasonboard.com wrote:

 Hi Jerome,

 On Friday 12 April 2013 09:51:04 Jerome Glisse wrote:
  Hi,
 
  I would like to make a libdrm release sometime next week, does anybody
 have
  anything they want to include ?

 kms: Return a negative error code in kms_bo_create()
 kms: Make libkms.h usable in C++

 would be nice.

 --
 Regards,

 Laurent Pinchart


If no objection i gonna make a release latter today. Above patch are
included.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] drm/radeon: minor HDMI improvements

[Rafał Miłecki]

2013/4/18 Alex Deucher alexdeuc...@gmail.com:
 On Sat, Apr 13, 2013 at 7:26 PM, Rafał Miłecki zaj...@gmail.com wrote:
 I've managed to track fglrx operations on HDMI regs, so we can finally setup
 everything in (hopefully) the correct way and order.

 This changes HDMI setup on Evergreen to mostly match fglrx and was tested on:
 1) AMD Radeon HD 6320 (PALM == DCE41)
 2) AMD Radeon HD 6970M (BARTS == DCE5)
 No regressions noticed, I can still play audio, including LPCM, AC3 and DTS.

 Unfortunately I don't have any DCE4 hardware to test this, but that changes
 shouldn't cause any regressions. I hope that with such improvements we will
 finally able to enable audio by default.

 I've applied patches 1, 4, 5, 6.  For patch 2, I'd prefer we just not
 enable the interrupts rather than removing the code altogether at this
 point.  See the attached patch.  For patch 3, none of the registers
 mentioned are directly related to audio setup.

I agree with that, thanks a lot for handling this patchset!

Your change from r600_hdmi.c should be probably also made in
r600_audio_chipset_supported.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Laurent Pinchart]

On Thursday 18 April 2013 17:06:57 Ville Syrjälä wrote:
 On Thu, Apr 18, 2013 at 03:43:23PM +0200, Laurent Pinchart wrote:
  On Wednesday 17 April 2013 22:18:01 ville.syrj...@linux.intel.com wrote:
   From: Ville Syrjälä ville.syrj...@linux.intel.com
   
   Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
   ---
   
tests/modetest/buffers.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
   
   diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
   index 5086381..6b117b4 100644
   --- a/tests/modetest/buffers.c
   +++ b/tests/modetest/buffers.c
   @@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
   *planes[3], unsigned int width, #define BLUE  0
   
static void
   
   -make_pwetty(void *data, int width, int height, int stride)
   +make_pwetty(void *data, int width, int height, int stride, int rgb16)
  
  What about passing the format 4cc instead ?
 
 It's a bit more work since I need to pass the whole format_info
 down from fill_tiles(). But I can make a v2 with that change.

It was just an idea to make the code more future-proof, in case we decide to 
make 24-bit formats pwetty at some point. Maybe a bpp value would be a good 
compromise ?


-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 1/5] modetest: Make RGB565 pwetty too

[Ville Syrjälä]

On Thu, Apr 18, 2013 at 04:19:30PM +0200, Laurent Pinchart wrote:
 On Thursday 18 April 2013 17:06:57 Ville Syrjälä wrote:
  On Thu, Apr 18, 2013 at 03:43:23PM +0200, Laurent Pinchart wrote:
   On Wednesday 17 April 2013 22:18:01 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---

 tests/modetest/buffers.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 5086381..6b117b4 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -601,7 +601,7 @@ fill_smpte(const struct format_info *info, void
*planes[3], unsigned int width, #define BLUE  0

 static void

-make_pwetty(void *data, int width, int height, int stride)
+make_pwetty(void *data, int width, int height, int stride, int rgb16)
   
   What about passing the format 4cc instead ?
  
  It's a bit more work since I need to pass the whole format_info
  down from fill_tiles(). But I can make a v2 with that change.
 
 It was just an idea to make the code more future-proof, in case we decide to 
 make 24-bit formats pwetty at some point. Maybe a bpp value would be a good 
 compromise ?

I already implemented your original idea. Just doing a quick test now.

It's a better idea anyway since we can then check that the color
channels match what we're rendering. My original code just assumed
that it can render RGB565 into an XRGB1555 buffer for example. That
produces some rather ugly results in reality, so it's better to
limit it to the formats where the size/location of RGB channels match.
The order or RGB channels doesn't actually matter since the source
color is always white or black.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Standalone DRM application

[Ilija Hadzic]

On Thu, 18 Apr 2013, David Herrmann wrote:


Hi

On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek gand...@winds.org wrote:

David,

I'm developing a small application that uses libdrm (DRM ioctls) to change
the
resolution of a single graphics display and show a framebuffer. I've run
into
two problems with this implementation that I'm hoping you can address.


1. Each application is its own process, which is designed to control 1
graphics
display. This is unlike X, for instance, which could be configured to grab
all
of the displays in the system at once.

Depending on our stackup, there can be as many as 4 displays connected to a
single graphics card. One process could open /dev/dri/card0 and call
drmModeSetCrtc() to initialize one of its displays to the requested
resolution.
However, whenever a second process calls drmModeSetCrtc() to control a
second
display on the same card, it gets -EPERM back from the ioctl.

I've traced this down to the following line in
linux/drivers/gpu/drm/drm_drv.c:

DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),

If I remove the DRM_MASTER flag, then my application behaves correctly, and
4
separate processes can then control each individual display on the card
without
issue.

My question is, is there any real benefit to restricting drm_mode_setcrtc()
with DRM_MASTER, or can we lose this flag in order to support
one-process-per-
display programs like the above?


Only one open-file can be DRM-Master. And only DRM-Master is allowed
to perform mode-setting. This is to prevent render-clients (like
OpenGL clients) to perform mode-setting, which should be restricted to
the compositor/...

In your scenario, you should share a single open-file between the
processes by passing the FDs to each. Or do all of that in a single
process. There is no way to split CRTCs/connectors between different
nodes or have multiple DRM-Masters on a single node at once. (There is
work going on to allow this, but it will take a while...)



If running a custom-patched kernel is acceptable (i.e. custom-built, 
embedded system or the like), then a set of patches that I sent about a 
year ago [1] will probably do the job. The problem is that these patches 
are apparently not going upstream because there was little interest and 
there were a couple of arguments against them [2]. Originally, it's the 
work that Dave Airlie started but abandoned. I finished it off and tried 
to have it included upstream but it didn't happen.


I have an application that is similar to what is described here and I am 
using these patches to make it work. Essentially, what you do is call a 
small userspace utility (also included with the patches for libdrm) and 
specify which CRTCs/encoders/connectors/planes do you want included in the 
node and you get a new /dev/dri/renderN node that your application can 
use and be the master on these resources only. Then for the next node you 
call the utility again and specify a new set of display resources and then 
you run the other application on the top of that node.


The patches that are on the mailing list archive [1] are now a year old, 
but I have a rebased version for newer kernels, which I can send to 
whoever is interested in having them (I am just hesitating to pollute the 
mailing list with patches to which the maintainers have already said 
no).


[1] http://lists.freedesktop.org/archives/dri-devel/2012-April/021326.html
[2] http://lists.freedesktop.org/archives/dri-devel/2012-September/028348.html

-- Ilija
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] drm/tegra: Changes for v3.10-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit e1adc78caf440d3f6be81a947c2b913e73514a68:

  drm/qxl: fix build with debugfs turned off. (2013-04-18 11:47:40 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux.git tags/drm/tegra/for-3.10

for you to fetch changes up to 2bae088dbb2c3bbd44b58fc0cc4bb3b5d1c00dc7:

  drm/tegra: don't depend on OF (2013-04-18 08:59:44 +0200)

Thierry


drm/tegra: Changes for v3.10-rc1

The bulk of this pull-request is the host1x series that has been in the
works for a few months. The current implementation looks good and has
been tested by several independent parties. So far no issues have been
found. To be on the safe side, the new Tegra-specific DRM IOCTLs depend
on staging in order to give some amount of flexibility to change them
just in case. The plan is to remove that dependency once more userspace
exists to verify the adequacy of the IOCTLs.

Currently only the 2D engine is supported, but patches are in the works
to enable 3D support on top of this framework as well. Various bits of
open-source userspace exist to test the 2D and 3D support[0]. This is
still a bit immature but it allows to verify that the kernel interfaces
work properly.

To round things off there are two smaller cleanup patches, one of them
adding a new pixel format and the other removing a redundent Kconfig
dependency.

[0]: https://github.com/grate-driver


Arto Merilainen (2):
  gpu: host1x: drm: Rename host1x to host1x_drm
  gpu: host1x: drm: Add memory manager and fb

Stephen Warren (1):
  drm/tegra: don't depend on OF

Terje Bergstrom (7):
  gpu: host1x: Add host1x driver
  gpu: host1x: Add syncpoint wait and interrupts
  gpu: host1x: Add channel support
  gpu: host1x: Add debug support
  drm/tegra: Move drm to live under host1x
  gpu: host1x: Remove second host1x driver
  drm/tegra: Add gr2d device

Thierry Reding (1):
  drm/tegra: Support the XBGR pixelformat

 drivers/gpu/Makefile   |   1 +
 drivers/gpu/drm/Kconfig|   2 -
 drivers/gpu/drm/Makefile   |   1 -
 drivers/gpu/drm/tegra/Makefile |   7 -
 drivers/gpu/drm/tegra/drm.c| 217 -
 drivers/gpu/drm/tegra/fb.c |  52 --
 drivers/gpu/drm/tegra/host1x.c | 327 -
 drivers/gpu/host1x/Kconfig |  23 +
 drivers/gpu/host1x/Makefile|  20 +
 drivers/gpu/host1x/cdma.c  | 491 +++
 drivers/gpu/host1x/cdma.h  | 100 
 drivers/gpu/host1x/channel.c   | 126 +
 drivers/gpu/host1x/channel.h   |  52 ++
 drivers/gpu/host1x/debug.c | 210 
 drivers/gpu/host1x/debug.h |  51 ++
 drivers/gpu/host1x/dev.c   | 246 ++
 drivers/gpu/host1x/dev.h   | 308 
 drivers/gpu/{drm/tegra = host1x/drm}/Kconfig  |  20 +-
 drivers/gpu/{drm/tegra = host1x/drm}/dc.c |  31 +-
 drivers/gpu/{drm/tegra = host1x/drm}/dc.h |   0
 drivers/gpu/host1x/drm/drm.c   | 640 +
 drivers/gpu/{drm/tegra = host1x/drm}/drm.h|  68 ++-
 drivers/gpu/host1x/drm/fb.c| 374 +++
 drivers/gpu/host1x/drm/gem.c   | 270 +++
 drivers/gpu/host1x/drm/gem.h   |  59 +++
 drivers/gpu/host1x/drm/gr2d.c  | 339 +
 drivers/gpu/{drm/tegra = host1x/drm}/hdmi.c   |   5 +-
 drivers/gpu/{drm/tegra = host1x/drm}/hdmi.h   |   0
 drivers/gpu/{drm/tegra = host1x/drm}/output.c |   0
 drivers/gpu/{drm/tegra = host1x/drm}/rgb.c|   0
 drivers/gpu/host1x/host1x.h|  30 ++
 drivers/gpu/host1x/host1x_bo.h |  87 
 drivers/gpu/host1x/host1x_client.h |  35 ++
 drivers/gpu/host1x/hw/Makefile |   6 +
 drivers/gpu/host1x/hw/cdma_hw.c| 326 +
 drivers/gpu/host1x/hw/channel_hw.c | 168 +++
 drivers/gpu/host1x/hw/debug_hw.c   | 322 +
 drivers/gpu/host1x/hw/host1x01.c   |  42 ++
 drivers/gpu/host1x/hw/host1x01.h   |  25 +
 drivers/gpu/host1x/hw/host1x01_hardware.h  | 143 ++
 drivers/gpu/host1x/hw/hw_host1x01_channel.h| 120 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h   | 243 ++
 drivers/gpu/host1x/hw/hw_host1x01_uclass.h | 174 +++
 drivers/gpu/host1x/hw/intr_hw.c| 143 ++
 drivers/gpu/host1x/hw/syncpt_hw.c  | 114 +
 drivers/gpu/host1x/intr.c  | 354 ++
 drivers/gpu/host1x/intr.h  | 102 
 drivers/gpu/host1x/job.c  

[PATCH libdrm 1/3] modetest: Pass format_info to fill_tiles functions

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

The fourcc is inside the format_info structure, so if we want to use
it inside the various fill_tiles functions, we need to pass down the
whole format_info, not just the rgb/yuv infos.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tests/modetest/buffers.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index b249f1f..2f3adf8 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -702,11 +702,12 @@ make_pwetty(void *data, int width, int height, int stride)
 }
 
 static void
-fill_tiles_yuv_planar(const struct yuv_info *yuv,
+fill_tiles_yuv_planar(const struct format_info *info,
  unsigned char *y_mem, unsigned char *u_mem,
  unsigned char *v_mem, unsigned int width,
  unsigned int height, unsigned int stride)
 {
+   const struct yuv_info *yuv = info-yuv;
unsigned int cs = yuv-chroma_stride;
unsigned int xsub = yuv-xsub;
unsigned int ysub = yuv-ysub;
@@ -736,10 +737,11 @@ fill_tiles_yuv_planar(const struct yuv_info *yuv,
 }
 
 static void
-fill_tiles_yuv_packed(const struct yuv_info *yuv, unsigned char *mem,
+fill_tiles_yuv_packed(const struct format_info *info, unsigned char *mem,
  unsigned int width, unsigned int height,
  unsigned int stride)
 {
+   const struct yuv_info *yuv = info-yuv;
unsigned char *y_mem = (yuv-order  YUV_YC) ? mem : mem + 1;
unsigned char *c_mem = (yuv-order  YUV_CY) ? mem : mem + 1;
unsigned int u = (yuv-order  YUV_YCrCb) ? 2 : 0;
@@ -768,9 +770,10 @@ fill_tiles_yuv_packed(const struct yuv_info *yuv, unsigned 
char *mem,
 }
 
 static void
-fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char *mem,
+fill_tiles_rgb16(const struct format_info *info, unsigned char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
+   const struct rgb_info *rgb = info-rgb;
unsigned int x, y;
 
for (y = 0; y  height; ++y) {
@@ -790,9 +793,10 @@ fill_tiles_rgb16(const struct rgb_info *rgb, unsigned char 
*mem,
 }
 
 static void
-fill_tiles_rgb24(const struct rgb_info *rgb, unsigned char *mem,
+fill_tiles_rgb24(const struct format_info *info, unsigned char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
+   const struct rgb_info *rgb = info-rgb;
unsigned int x, y;
 
for (y = 0; y  height; ++y) {
@@ -811,9 +815,10 @@ fill_tiles_rgb24(const struct rgb_info *rgb, unsigned char 
*mem,
 }
 
 static void
-fill_tiles_rgb32(const struct rgb_info *rgb, unsigned char *mem,
+fill_tiles_rgb32(const struct format_info *info, unsigned char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
+   const struct rgb_info *rgb = info-rgb;
unsigned char *mem_base = mem;
unsigned int x, y;
 
@@ -846,7 +851,7 @@ fill_tiles(const struct format_info *info, void *planes[3], 
unsigned int width,
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
-   return fill_tiles_yuv_packed(info-yuv, planes[0],
+   return fill_tiles_yuv_packed(info, planes[0],
 width, height, stride);
 
case DRM_FORMAT_NV12:
@@ -855,11 +860,11 @@ fill_tiles(const struct format_info *info, void 
*planes[3], unsigned int width,
case DRM_FORMAT_NV61:
u = info-yuv.order  YUV_YCbCr ? planes[1] : planes[1] + 1;
v = info-yuv.order  YUV_YCrCb ? planes[1] : planes[1] + 1;
-   return fill_tiles_yuv_planar(info-yuv, planes[0], u, v,
+   return fill_tiles_yuv_planar(info, planes[0], u, v,
 width, height, stride);
 
case DRM_FORMAT_YVU420:
-   return fill_tiles_yuv_planar(info-yuv, planes[0], planes[1],
+   return fill_tiles_yuv_planar(info, planes[0], planes[1],
 planes[2], width, height, stride);
 
case DRM_FORMAT_ARGB:
@@ -880,12 +885,12 @@ fill_tiles(const struct format_info *info, void 
*planes[3], unsigned int width,
case DRM_FORMAT_RGBX5551:
case DRM_FORMAT_BGRA5551:
case DRM_FORMAT_BGRX5551:
-   return fill_tiles_rgb16(info-rgb, planes[0],
+   return fill_tiles_rgb16(info, planes[0],
width, height, stride);
 
case DRM_FORMAT_BGR888:
case DRM_FORMAT_RGB888:
-   return fill_tiles_rgb24(info-rgb, planes[0],
+   return fill_tiles_rgb24(info, planes[0],
width, height, stride);
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
@@ -903,7 +908,7 @@ fill_tiles(const struct 

[PATCH v2 libdrm 2/3] modetest: Make RGB565 pwetty too

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

Render the crosshairs for 565 and x888/a888 formats.

v2: Use the drm format to determine cairo format

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 tests/modetest/buffers.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 2f3adf8..abacea5 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -656,15 +656,32 @@ fill_smpte(const struct format_info *info, void 
*planes[3], unsigned int width,
 #define BLUE  0
 
 static void
-make_pwetty(void *data, int width, int height, int stride)
+make_pwetty(void *data, int width, int height, int stride, uint32_t format)
 {
 #ifdef HAVE_CAIRO
cairo_surface_t *surface;
cairo_t *cr;
int x, y;
+   cairo_format_t cairo_format;
+
+   /* we can ignore the order of R,G,B channels */
+   switch (format) {
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   cairo_format = CAIRO_FORMAT_ARGB32;
+   break;
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_BGR565:
+   cairo_format = CAIRO_FORMAT_RGB16_565;
+   break;
+   default:
+   return;
+   }
 
surface = cairo_image_surface_create_for_data(data,
- CAIRO_FORMAT_ARGB32,
+ cairo_format,
  width, height,
  stride);
cr = cairo_create(surface);
@@ -774,6 +791,7 @@ fill_tiles_rgb16(const struct format_info *info, unsigned 
char *mem,
 unsigned int width, unsigned int height, unsigned int stride)
 {
const struct rgb_info *rgb = info-rgb;
+   unsigned char *mem_base = mem;
unsigned int x, y;
 
for (y = 0; y  height; ++y) {
@@ -790,6 +808,8 @@ fill_tiles_rgb16(const struct format_info *info, unsigned 
char *mem,
}
mem += stride;
}
+
+   make_pwetty(mem_base, width, height, stride, info-format);
 }
 
 static void
@@ -837,7 +857,7 @@ fill_tiles_rgb32(const struct format_info *info, unsigned 
char *mem,
mem += stride;
}
 
-   make_pwetty(mem_base, width, height, stride);
+   make_pwetty(mem_base, width, height, stride, info-format);
 }
 
 static void
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm 3/3] modetest: Add YUV420 support and fix YVU420 Cb/Cr ordering

[ville . syrjala]

From: Ville Syrjälä ville.syrj...@linux.intel.com

YUV420 support is trivial to add since the code already supports
YVU420.

But it looks like the YVU420 support is a bit broken. The chroma
planes are passed in the wrong order to the fill functions, so
fix that while were at it.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Note: I determined the the Cb/Cr ordering issue based on a very cursory
glance at the code, I didn't really read through the rendering code to make
sure I got it right. Also I couldn't test this since I don't have
hardware/driver support for planar formats currently.

 tests/modetest/buffers.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index abacea5..b75cca7 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -100,6 +100,7 @@ static const struct format_info format_info[] = {
{ DRM_FORMAT_NV16, NV16, MAKE_YUV_INFO(YUV_YCbCr, 2, 1, 2) },
{ DRM_FORMAT_NV61, NV61, MAKE_YUV_INFO(YUV_YCrCb, 2, 1, 2) },
/* YUV planar */
+   { DRM_FORMAT_YUV420, YU12, MAKE_YUV_INFO(YUV_YCbCr, 2, 2, 1) },
{ DRM_FORMAT_YVU420, YV12, MAKE_YUV_INFO(YUV_YCrCb, 2, 2, 1) },
/* RGB16 */
{ DRM_FORMAT_ARGB, AR12, MAKE_RGB_INFO(4, 8, 4, 4, 4, 0, 4, 12) },
@@ -600,10 +601,14 @@ fill_smpte(const struct format_info *info, void 
*planes[3], unsigned int width,
return fill_smpte_yuv_planar(info-yuv, planes[0], u, v,
 width, height, stride);
 
-   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV420:
return fill_smpte_yuv_planar(info-yuv, planes[0], planes[1],
 planes[2], width, height, stride);
 
+   case DRM_FORMAT_YVU420:
+   return fill_smpte_yuv_planar(info-yuv, planes[0], planes[2],
+planes[1], width, height, stride);
+
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ABGR:
@@ -883,10 +888,14 @@ fill_tiles(const struct format_info *info, void 
*planes[3], unsigned int width,
return fill_tiles_yuv_planar(info, planes[0], u, v,
 width, height, stride);
 
-   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV420:
return fill_tiles_yuv_planar(info, planes[0], planes[1],
 planes[2], width, height, stride);
 
+   case DRM_FORMAT_YVU420:
+   return fill_tiles_yuv_planar(info, planes[0], planes[2],
+planes[1], width, height, stride);
+
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ABGR:
@@ -1075,6 +1084,7 @@ create_test_buffer(struct kms_driver *kms, unsigned int 
format,
planes[1] = virtual + offsets[1];
break;
 
+   case DRM_FORMAT_YUV420:
case DRM_FORMAT_YVU420:
offsets[0] = 0;
kms_bo_get_prop(bo, KMS_HANDLE, handles[0]);
-- 
1.8.1.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel