date:20130518

Re: Introduce a new helper framework for buffer synchronization

2013-05-18 Thread Inki Dae

Hi Daniel,

2013/5/17 Daniel Vetter 

> On Wed, May 15, 2013 at 4:06 PM, Rob Clark  wrote:
> > So while it seems nice and orthogonal/clean to couple cache and
> > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > same generic way, but I think in practice we have to make things more
> > complex than they otherwise need to be to do this.  Otherwise I think
> > we'll be having problems with badly behaved or crashing userspace.
>
> I haven't read through the entire thread careful but imo this is very
> important. If we add a fence interface which allows userspace to block
> dma this is a no-go. The only thing we need is to sync up with all
> outstanding dma operations and flush caches for cpu access. If broken
> userspace starts to issue new dma (or multiple thread stomp onto each
> another) that's not a problem dma fences/syncpoints should try to
> solve.

I'm not sure that I understood your concerns but it seems that you say we
have to prohibit userspace from blocking dma. Could you please give me more
detail for it? Without critical problem by userspace, this appoach is a
better way against the traditional at least for ARM based embedded system.
For this, I had already mentioned before like below,
   http://www.spinics.net/lists/dri-devel/msg38359.html

If you agree to my opinion, I'd like to say we could try to solve this
problem in the long term. If we prohibit such interfaces from be used
without sure reason, I carefully think we might to be just going thourgh
the motions: we have to use traditional way NECESSARILY. As previously
stated, could please tell me about that there are sure reasons we have to
prohibit the such user interfaces from being used necessarily and
there is really no any way we have to solve that? Basically, I have
designed and implemented that all resources to user fence are freed once
timed out so that the user cannot affect the other anymore. However, I'm
sure that there are things I didn't cach up. As I already mentioned, the
purpose of this post is to collect other opinions and advices for better
something else. Of course, we have to concentrate on solving the
device-to-device sync issues first.

Thanks,
Inki Dae

> This way we can concentrate on solving the (already
> challenging) device-to-device sync issues without additional
> complexities which cpu->cpu sync would impose.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64738] New: graphics corruption with glamor

2013-05-18 Thread bugzilla-daemon

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

  Priority: medium
Bug ID: 64738
  Assignee: dri-devel@lists.freedesktop.org
   Summary: graphics corruption with glamor
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: alexan...@tsoy.me
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

I have these problems with Cape Verde Pro (HD 7750) card:
1. Graphics corruption when scrolling in gtk2/gtk3 apps (screenshot [1])
2. Graphics corruption when moving windows in wm whithout compositing. Both gtk
and qt apps are affected. No such artifacts when compositing enabled, e.g. in
gnome 3. (screenshot [2])
3. Missing notification icons of gtk2 apps in awesome wm.

All of this things works great whithout glamor. Also no such problems with HD
6450 card with both EXA and glamor acceleration.

Software:
- mesa-9.2 from git
- llvm-3.{3,4} from git
- xorg-server-1.13.4, also tried 1.12*
- xf86-video-ati-7.1.0
- glamor-0.5
- linux kernel 3.8* including latest 3.8.13

Also note, that with mesa-9.0* and mesa-9.1* Xorg segfaults at startup on this
system when glamor enabled, but this is a subject for another bug report.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-daemon

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

--- Comment #1 from Alexander Tsoy  ---
Created attachment 79494
  --> https://bugs.freedesktop.org/attachment.cgi?id=79494&action=edit
screenshot [1]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-daemon

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

--- Comment #2 from Alexander Tsoy  ---
Created attachment 79495
  --> https://bugs.freedesktop.org/attachment.cgi?id=79495&action=edit
screenshot [2]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-daemon

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

--- Comment #3 from Alexander Tsoy  ---
Created attachment 79496
  --> https://bugs.freedesktop.org/attachment.cgi?id=79496&action=edit
Xorg log

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-daemon

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

--- Comment #4 from Alexander Tsoy  ---
This graphics artifacts are persist until the window is redrawn.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-18 Thread bugzilla-daemon

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

--- Comment #10 from Mike Lothian  ---
I've now recompiled everything from upstream - kwin now renders however it has
a pinkish hugh to the bottom right - this didn't happen when I tested the
patches separately

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63579] Savage 2 Edges render white [r600g]

2013-05-18 Thread bugzilla-daemon

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

--- Comment #20 from Alex Deucher  ---
yes:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f732036f12d67a96f546c11236fa635b3eda6e9c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-daemon

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

--- Comment #5 from Alexander Tsoy  ---
Created attachment 79497
  --> https://bugs.freedesktop.org/attachment.cgi?id=79497&action=edit
Screenshot of notification area

No claws-mail and gajim icons here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Rob Clark

On Sat, May 18, 2013 at 1:46 PM, Jean-Francois Moine  wrote:
> On Sat, 18 May 2013 19:12:19 +0200
> Sebastian Hesselbarth  wrote:
>
>> The RFC sent by Russell King was missing an include for tda998x. This
>> is just a compatible clone to remember Russell to add that later.
>>
>> Signed-off-by: Sebastian Hesselbarth 
>> ---
>> Cc: Russell King 
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: Jason Cooper 
>> Cc: Jean-Francois Moine 
>> ---
>>  include/drm/i2c/tda998x.h |   23 +++
>>  1 file changed, 23 insertions(+)
>>  create mode 100644 include/drm/i2c/tda998x.h
>>
>> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
>> new file mode 100644
>> index 000..41f799f
>> --- /dev/null
>> +++ b/include/drm/i2c/tda998x.h
>> @@ -0,0 +1,23 @@
>> +#ifndef __TDA998X_H__
>> +#define __TDA998X_H__
>> +
>> +enum tda998x_audio_format {
>> + AFMT_I2S,
>> + AFMT_SPDIF,
>> +};
>> +
>> +struct tda998x_encoder_params {
>> + int audio_cfg;
>> + int audio_clk_cfg;
>> + enum tda998x_audio_format audio_format;
>> + int audio_sample_rate;
>> + char audio_frame[6];
>> + int swap_a, mirr_a;
>> + int swap_b, mirr_b;
>> + int swap_c, mirr_c;
>> + int swap_d, mirr_d;
>> + int swap_e, mirr_e;
>> + int swap_f, mirr_f;
>> +};
>> +
>> +#endif
>
> These parameters should not be there. It seems to me that the DT is the
> right place.

You might not want to directly have a hard DT dependency in tda998x,
as the encoder could be used on non-DT platforms.  Although a DT to
encoder-params helper might be a nice idea for platforms which do have
DT.

BR,
-R

> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef |   http://moinejf.free.fr/
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Rob Clark

On Sat, May 18, 2013 at 2:58 PM, Jean-Francois Moine  wrote:
> On Sat, 18 May 2013 14:23:19 -0400
> Rob Clark  wrote:
>
>> > These parameters should not be there. It seems to me that the DT is the
>> > right place.
>>
>> You might not want to directly have a hard DT dependency in tda998x,
>> as the encoder could be used on non-DT platforms.  Although a DT to
>> encoder-params helper might be a nice idea for platforms which do have
>> DT.
>
> If I correctly understand:
>
> - Russell does not use any DT, so his drm driver should be declared in
>   some cubox-setup code in mach-dove/
>
> - this code should also declare the tda998x
>
> - the drm driver contains/passes parameters to the tda998x
>
> As the connection Dove LCD <-> tda998x is Cubox specific, the question
> is: why are'nt the tda998x parameters in the cubox-setup code?

ok, maybe I am misunderstanding you.  I think the parameters should be
filled in by the board file on a non-DT setup.  But the part in
drivers/gpu/drm/i2c should not pull them directly out of DT, or should
have an arrangement like

 #ifdef CONFIG_OF
 .. pull params out of DT ..
#else
 .. use params passed in from via params struct, which is populated in
board file ..
#endif

to accommodate non-DT builds.  (Although I think just having a helper
to populate 'struct tda998x_encoder_params' from DT seems cleaner.)

BR,
-R

> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

2013-05-18 Thread bugzilla-daemon

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

--- Comment #32 from Hristo Venev  ---
Created attachment 79504
  --> https://bugs.freedesktop.org/attachment.cgi?id=79504&action=edit
Results of OpenCL test

BREAKTHROUGH!

OpenCL works. Kinda. Tried the following kernel:
__kernel void add(__global const uint *a,  __global const uint *b, __global
uint *c){
c[0]=1;
}
Complicated operations such as addition, memory loads, getting global ID, etc.
fail with Cannot select errors.
I have no idea if this has worked with earlier LLVM/mesa.

After the kernel is run, the 0-th element of c is equal to 1. I've attached
full source code and outputs for various kernels.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/8] rmk's Dove DRM/TDA19988 Cubox driver

2013-05-18 Thread Jean-Francois Moine

On Fri, 17 May 2013 19:00:29 +0100
Russell King - ARM Linux  wrote:

> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> > case. And, yes, I better like a hardware cursor: it asks for less
> > computation, and I get it immediately at graphic starting time!  
> 
> Interesting.  Where did you find the documentation for the transparency?
> The FS lists HWC32_TRANS_CNTL but omits to specify where that gets used.

Simply in the ¶ 11.3.2.1. The HWC32_TRANS_CNTL SRAM is loaded like the
HWC 2bpp, but with 00 transparent / 01 RGB.

> > The first step is "DT or not DT"? For me, the DT is more flexible
> > (one or two LCDs, smart panel definition, display controller or not..)
> > and permits easy inclusion of out of tree drivers as the private VPU
> > and GPU ones.  
> 
> I'd argue supporting both. :)

Not easy!

If you have not yet looked at our driver, here is how it starts:

- in '/', the DT contains

video {
compatible = "marvell,dove-video";
};

  which loads the dove-drm module.

- its module init function registers the lcd driver, the dcon driver
  and the drm driver.

- the lcd probe function tries to get all the resources for the
  specific LCD from the DT, including the clocks and the HDMI
  transmitter.
  If some resource is lacking, it deferes.
  When all resources are there, it says "present" to the drm driver (see
  below).

  The resources of a LCD are declared in the DT by something like:

  &lcd0 {   /* the iomem and irq are 
declared
 * in the Dove global DT */
status = "okay";/* this LCD is present and 
usable */
clocks = <&core_clk 3>, <0>, <&lcdclk>, <&si5351 0>;
/* 3 usable clocks */
marvell,port-type = <11>;   /* HDMIA */
marvell,external-encoder = <&tda998x>;  /* HDMI slave encoder */
  };

- the dcon probe function gets its resources and says "present" to the
  drm driver.
  Its DT declaration is just:

  &dcon { status = "okay"; };   /* iomem and irq in the Dove DT 
*/

- the drm probe function scans all the DT, counting its usuable devices,
  (i.e. the LCDs and the dcon), and decrement the "present" variable
  accordingly.

- when the "present" variable is null, the active devices have all
  their resources, and, then, the drm driver is activated by a call to
  drm_platform_init().

I don't see clearly how to do that with a static initialization, and I
don't want to write a "cubox-setup.c". A kernel CONFIG_CUBOX ?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/8] drm/i2c: nxp-tda998x: ensure VIP output mux is properly set

2013-05-18 Thread Jean-Francois Moine

On Thu, 16 May 2013 20:26:18 +0100
Russell King  wrote:

> When switching between various drivers for this device, it's possible
> that some critical registers are left containing values which affect
> the device operation.  One such case encountered is the VIP output
> mux register.  This defaults to 0x24 on powerup, but other drivers may
> set this to 0x12.  This results in incorrect colours.
> 
> Fix this by ensuring that the register is always set to the power on
> default setting.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index d71c408..4b4db95 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -110,6 +110,7 @@ struct tda998x_priv {
>  #define REG_VIP_CNTRL_5   REG(0x00, 0x25) /* write */
>  # define VIP_CNTRL_5_CKCASE   (1 << 0)
>  # define VIP_CNTRL_5_SP_CNT(x)(((x) & 3) << 1)
> +#define REG_MUX_VP_VIP_OUTREG(0x00, 0x27) /* read/write */
>  #define REG_MAT_CONTRLREG(0x00, 0x80) /* write */
>  # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
>  # define MAT_CONTRL_MAT_BP(1 << 2)
> @@ -438,6 +439,8 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int 
> mode)
>  
>   switch (mode) {
>   case DRM_MODE_DPMS_ON:
> + /* Write the default value MUX register */
> + reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
>   /* enable audio and video ports */
>   reg_write(encoder, REG_ENA_AP, 0xff);
>   reg_write(encoder, REG_ENA_VP_0, 0xff);

This register is never touched. Should not this setting better go at
reset time (in tda998x_reset)?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC 2/4] ARM: dove: add video card node for SolidRun CuBox

2013-05-18 Thread Sebastian Hesselbarth

This adds a video card node required for rmk's dove_drm driver. Reg
property matches reserved memory region (currently 16M at top of memory),
clocks property should carry extclk0 for now.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 arch/arm/boot/dts/dove-cubox.dts |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index ed2b7b2..f26d0d2 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -8,7 +8,7 @@
 
memory {
device_type = "memory";
-   reg = <0x 0x4000>;
+   reg = <0x 0x3f00>;
};
 
chosen {
@@ -52,10 +52,24 @@
#clock-cells = <0>;
};
};
+
+   video {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   vcard: video-card {
+   compatible = "marvell,dove-video-card";
+   reg = <0x3f00 0x100>;
+   clocks = <&si5351 0>, <&si5351 0>;
+   };
+   };
 };
 
 &uart0 { status = "okay"; };
 &sata0 { status = "okay"; };
+&lcd0 { status = "okay"; };
 
 &i2c0 {
status = "okay";
-- 
1.7.10.4

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

[RFC 1/4] ARM: dove: add lcd controller DT nodes

2013-05-18 Thread Sebastian Hesselbarth

This adds device tree nodes for the lcd controllers found on Marvell
Dove SoCs. For now, there is no DT documentation and clocks property
should refer to clock connected to extclk0 pin.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 arch/arm/boot/dts/dove.dtsi |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..2053e86 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -258,5 +258,21 @@
dmacap,xor;
};
};
+
+   lcd0: lcd-controller@82 {
+   compatible = "marvell,dove-lcd";
+   reg = <0x82 0x200>;
+   interrupts = <47>;
+   clocks = <0>;
+   status = "disabled";
+   };
+
+   lcd1: lcd-controller@81 {
+   compatible = "marvell,dove-lcd";
+   reg = <0x81 0x200>;
+   interrupts = <46>;
+   clocks = <0>;
+   status = "disabled";
+   };
};
 };
-- 
1.7.10.4

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

[RFC 0/4] Add DT support to rmk's Dove DRM driver

2013-05-18 Thread Sebastian Hesselbarth

This RFC adds DT support to the DRM driver for Marvell Dove SoCs
posted by Russell King recently. For those booting DT with appended
ATAGs, remember to reduce probed memory by passing mem=1008M as
kernel parameter.

There was an include missing in Russell's RFC that is also added.

Sebastian Hesselbarth (4):
  ARM: dove: add lcd controller DT nodes
  ARM: dove: add video card node for SolidRun CuBox
  DRM: add OF support for Dove DRM driver
  DRM: tda998x: add missing include

 arch/arm/boot/dts/dove-cubox.dts |   16 +-
 arch/arm/boot/dts/dove.dtsi  |   16 ++
 drivers/gpu/drm/dove/Kconfig |4 ++
 drivers/gpu/drm/dove/Makefile|1 +
 drivers/gpu/drm/dove/dove_card.c |  110 ++
 include/drm/i2c/tda998x.h|   23 
 6 files changed, 169 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/dove/dove_card.c
 create mode 100644 include/drm/i2c/tda998x.h
---
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
-- 
1.7.10.4

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

[RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Sebastian Hesselbarth

This adds OF support for the Dove DRM driver recently posted as RFC by
Russell King.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 drivers/gpu/drm/dove/Kconfig |4 ++
 drivers/gpu/drm/dove/Makefile|1 +
 drivers/gpu/drm/dove/dove_card.c |  110 ++
 3 files changed, 115 insertions(+)
 create mode 100644 drivers/gpu/drm/dove/dove_card.c

diff --git a/drivers/gpu/drm/dove/Kconfig b/drivers/gpu/drm/dove/Kconfig
index 718d3c5..a943ea5 100644
--- a/drivers/gpu/drm/dove/Kconfig
+++ b/drivers/gpu/drm/dove/Kconfig
@@ -28,4 +28,8 @@ config DRM_DOVE_TDA1998X
 config DRM_DOVE_CURSOR
bool "Enable Dove DRM hardware cursor support"
 
+config DRM_DOVE_OF
+   bool "Enable Dove DRM OF video card"
+   depends on OF
+
 endif
diff --git a/drivers/gpu/drm/dove/Makefile b/drivers/gpu/drm/dove/Makefile
index 65c701e..f0b6eed 100644
--- a/drivers/gpu/drm/dove/Makefile
+++ b/drivers/gpu/drm/dove/Makefile
@@ -5,5 +5,6 @@ dove-y  := dove_crtc.o dove_drv.o dove_fb.o 
dove_fbdev.o \
 dove-$(CONFIG_DEBUG_FS) += dove_debugfs.o
 
 dove-$(CONFIG_DRM_DOVE_TDA1998X) += dove_tda19988.o
+dove-$(CONFIG_DRM_DOVE_OF) += dove_card.o
 
 obj-$(CONFIG_DRM_DOVE) := dove.o
diff --git a/drivers/gpu/drm/dove/dove_card.c b/drivers/gpu/drm/dove/dove_card.c
new file mode 100644
index 000..e4bcb5b
--- /dev/null
+++ b/drivers/gpu/drm/dove/dove_card.c
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2013
+ *   Sebastian Hesselbarth 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DOVE_LCD0_BASE 0x2
+#define DOVE_LCD1_BASE 0x1
+
+static struct resource dove_drm_resources[5];
+static struct platform_device dove_drm_platform_device = {
+   .name = "dove-drm",
+   .id = 0,
+   .dev = { .coherent_dma_mask = ~0, },
+   .resource = dove_drm_resources,
+};
+
+static int dove_card_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *lcdnp;
+   struct resource *res = dove_drm_resources;
+   int ret, n = 0, crtcs = 0;
+
+   /* get video memory resource */
+   if (of_address_to_resource(np, 0, &res[n++])) {
+   dev_err(&pdev->dev, "invalid or missing video memory\n");
+   return -EINVAL;
+   }
+
+   /* get reg and irq resource from each enabled lcdc */
+   for_each_compatible_node(lcdnp, NULL, "marvell,dove-lcd") {
+   struct clk_lookup *cl;
+   struct clk *clk;
+   int lcd;
+
+   if (!of_device_is_available(lcdnp))
+   continue;
+
+   ret = of_address_to_resource(lcdnp, 0, &res[n]);
+   if (ret)
+   return ret;
+   lcd = ((res[n].start & 0xf) == DOVE_LCD1_BASE);
+   n++;
+
+   ret = of_irq_to_resource(lcdnp, 0, &res[n]);
+   if (ret < 0)
+   return ret;
+   n++;
+
+   crtcs++;
+
+   clk = clk_get(&pdev->dev, NULL);
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   if (ret == -ENOENT)
+   return -EPROBE_DEFER;
+   return ret;
+   }
+
+   /* add clock alias for dovefb.0 */
+   cl = clkdev_alloc(clk, "extclk", "dovefb.0");
+   if (cl)
+   clkdev_add(cl);
+   clk_put(clk);
+   }
+
+   if (!crtcs)
+   return -ENODEV;
+
+   dove_drm_platform_device.num_resources = n;
+   ret = platform_device_register(&dove_drm_platform_device);
+   if (ret) {
+   dev_err(&pdev->dev, "unable to register drm device\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct of_device_id dove_card_of_ids[] = {
+   { .compatible = "marvell,dove-video-card", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, dove_card_of_ids);
+
+static struct platform_driver dove_card_driver = {
+   .probe  = dove_card_probe,
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = "dove-drm-card",
+   .of_match_table = of_match_ptr(dove_card_of_ids),
+   },
+};
+module_platform_driver(dove_card_driver);
+
+MODULE_AUTHOR("Sebastian Hesselbarth ");
+MODULE_DESCRIPTION("Dove DRM Graphics Card");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4

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

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth

The RFC sent by Russell King was missing an include for tda998x. This
is just a compatible clone to remember Russell to add that later.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: dri-devel@lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 include/drm/i2c/tda998x.h |   23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/drm/i2c/tda998x.h

diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
new file mode 100644
index 000..41f799f
--- /dev/null
+++ b/include/drm/i2c/tda998x.h
@@ -0,0 +1,23 @@
+#ifndef __TDA998X_H__
+#define __TDA998X_H__
+
+enum tda998x_audio_format {
+   AFMT_I2S,
+   AFMT_SPDIF,
+};
+
+struct tda998x_encoder_params {
+   int audio_cfg;
+   int audio_clk_cfg;
+   enum tda998x_audio_format audio_format;
+   int audio_sample_rate;
+   char audio_frame[6];
+   int swap_a, mirr_a;
+   int swap_b, mirr_b;
+   int swap_c, mirr_c;
+   int swap_d, mirr_d;
+   int swap_e, mirr_e;
+   int swap_f, mirr_f;
+};
+
+#endif
-- 
1.7.10.4

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

Re: [RFC 2/4] ARM: dove: add video card node for SolidRun CuBox

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 19:12:17 +0200
Sebastian Hesselbarth  wrote:

> This adds a video card node required for rmk's dove_drm driver. Reg
> property matches reserved memory region (currently 16M at top of memory),
> clocks property should carry extclk0 for now.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jason Cooper 
> Cc: Jean-Francois Moine 
> ---
>  arch/arm/boot/dts/dove-cubox.dts |   16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/dove-cubox.dts 
> b/arch/arm/boot/dts/dove-cubox.dts
> index ed2b7b2..f26d0d2 100644
> --- a/arch/arm/boot/dts/dove-cubox.dts
> +++ b/arch/arm/boot/dts/dove-cubox.dts
> @@ -8,7 +8,7 @@
>  
>   memory {
>   device_type = "memory";
> - reg = <0x 0x4000>;
> + reg = <0x 0x3f00>;
>   };
>  
>   chosen {
> @@ -52,10 +52,24 @@
>   #clock-cells = <0>;
>   };
>   };
> +
> + video {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + vcard: video-card {
> + compatible = "marvell,dove-video-card";
> + reg = <0x3f00 0x100>;
> + clocks = <&si5351 0>, <&si5351 0>;
> + };
> + };
>  };
>  
>  &uart0 { status = "okay"; };
>  &sata0 { status = "okay"; };
> +&lcd0 { status = "okay"; };
>  
>  &i2c0 {
>   status = "okay";

May you explain a bit more this strange hack?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 19:12:18 +0200
Sebastian Hesselbarth  wrote:

> This adds OF support for the Dove DRM driver recently posted as RFC by
> Russell King.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jason Cooper 
> Cc: Jean-Francois Moine 
> ---
>  drivers/gpu/drm/dove/Kconfig |4 ++
>  drivers/gpu/drm/dove/Makefile|1 +
>  drivers/gpu/drm/dove/dove_card.c |  110 
> ++
>  3 files changed, 115 insertions(+)
>  create mode 100644 drivers/gpu/drm/dove/dove_card.c
> 
> diff --git a/drivers/gpu/drm/dove/Kconfig b/drivers/gpu/drm/dove/Kconfig
> index 718d3c5..a943ea5 100644
> --- a/drivers/gpu/drm/dove/Kconfig
> +++ b/drivers/gpu/drm/dove/Kconfig
> @@ -28,4 +28,8 @@ config DRM_DOVE_TDA1998X
>  config DRM_DOVE_CURSOR
>   bool "Enable Dove DRM hardware cursor support"
>  
> +config DRM_DOVE_OF
> + bool "Enable Dove DRM OF video card"
> + depends on OF
> +
>  endif
> diff --git a/drivers/gpu/drm/dove/Makefile b/drivers/gpu/drm/dove/Makefile
> index 65c701e..f0b6eed 100644
> --- a/drivers/gpu/drm/dove/Makefile
> +++ b/drivers/gpu/drm/dove/Makefile
> @@ -5,5 +5,6 @@ dove-y:= dove_crtc.o dove_drv.o 
> dove_fb.o dove_fbdev.o \
>  dove-$(CONFIG_DEBUG_FS) += dove_debugfs.o
>  
>  dove-$(CONFIG_DRM_DOVE_TDA1998X) += dove_tda19988.o
> +dove-$(CONFIG_DRM_DOVE_OF) += dove_card.o
>  
>  obj-$(CONFIG_DRM_DOVE) := dove.o
> diff --git a/drivers/gpu/drm/dove/dove_card.c 
> b/drivers/gpu/drm/dove/dove_card.c
> new file mode 100644
> index 000..e4bcb5b
> --- /dev/null
> +++ b/drivers/gpu/drm/dove/dove_card.c
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2013
> + *   Sebastian Hesselbarth 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DOVE_LCD0_BASE   0x2
> +#define DOVE_LCD1_BASE   0x1
> +
> +static struct resource dove_drm_resources[5];
> +static struct platform_device dove_drm_platform_device = {
> + .name = "dove-drm",
> + .id = 0,
> + .dev = { .coherent_dma_mask = ~0, },
> + .resource = dove_drm_resources,
> +};
> +
> +static int dove_card_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *lcdnp;
> + struct resource *res = dove_drm_resources;
> + int ret, n = 0, crtcs = 0;
> +
> + /* get video memory resource */
> + if (of_address_to_resource(np, 0, &res[n++])) {
> + dev_err(&pdev->dev, "invalid or missing video memory\n");
> + return -EINVAL;
> + }
> +
> + /* get reg and irq resource from each enabled lcdc */
> + for_each_compatible_node(lcdnp, NULL, "marvell,dove-lcd") {
> + struct clk_lookup *cl;
> + struct clk *clk;
> + int lcd;
> +
> + if (!of_device_is_available(lcdnp))
> + continue;
> +
> + ret = of_address_to_resource(lcdnp, 0, &res[n]);
> + if (ret)
> + return ret;
> + lcd = ((res[n].start & 0xf) == DOVE_LCD1_BASE);
> + n++;
> +
> + ret = of_irq_to_resource(lcdnp, 0, &res[n]);
> + if (ret < 0)
> + return ret;
> + n++;
> +
> + crtcs++;
> +
> + clk = clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + if (ret == -ENOENT)
> + return -EPROBE_DEFER;
> + return ret;
> + }
> +
> + /* add clock alias for dovefb.0 */
> + cl = clkdev_alloc(clk, "extclk", "dovefb.0");
> + if (cl)
> + clkdev_add(cl);
> + clk_put(clk);
> + }
> +
> + if (!crtcs)
> + return -ENODEV;
> +
> + dove_drm_platform_device.num_resources = n;
> + ret = platform_device_register(&dove_drm_platform_device);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to register drm device\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id dove_card_of_ids[] = {
> + { .compatible = "marvell,dove-video-card", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, dove_card_of_ids);
> +
> +static struct platform_driver dove_card_driver = {
> + .probe  = dove_card_probe,
> + .driver = {
> + .owner  = THIS_MODULE,
> + .name   = "dove-drm-card",
> + .of_match_table = of_match_ptr(dove_card_of_ids),
> + },
> +};
> +module_platform_driver(dove_card_driver);
> +
> +MODULE_AUTHOR("Sebastian Hesse

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 19:12:19 +0200
Sebastian Hesselbarth  wrote:

> The RFC sent by Russell King was missing an include for tda998x. This
> is just a compatible clone to remember Russell to add that later.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jason Cooper 
> Cc: Jean-Francois Moine 
> ---
>  include/drm/i2c/tda998x.h |   23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 include/drm/i2c/tda998x.h
> 
> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
> new file mode 100644
> index 000..41f799f
> --- /dev/null
> +++ b/include/drm/i2c/tda998x.h
> @@ -0,0 +1,23 @@
> +#ifndef __TDA998X_H__
> +#define __TDA998X_H__
> +
> +enum tda998x_audio_format {
> + AFMT_I2S,
> + AFMT_SPDIF,
> +};
> +
> +struct tda998x_encoder_params {
> + int audio_cfg;
> + int audio_clk_cfg;
> + enum tda998x_audio_format audio_format;
> + int audio_sample_rate;
> + char audio_frame[6];
> + int swap_a, mirr_a;
> + int swap_b, mirr_b;
> + int swap_c, mirr_c;
> + int swap_d, mirr_d;
> + int swap_e, mirr_e;
> + int swap_f, mirr_f;
> +};
> +
> +#endif

These parameters should not be there. It seems to me that the DT is the
right place.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Sebastian Hesselbarth


On 05/18/2013 07:45 PM, Jean-Francois Moine wrote:

On Sat, 18 May 2013 19:12:18 +0200
Sebastian Hesselbarth  wrote:

This adds OF support for the Dove DRM driver recently posted as RFC by
Russell King.


...

Jean-Francois,

one thing first: It is an RFC! It is to allow you to _test_ rmk's driver
on DT. Nothing more, nothing less.

I will comment on your questions but that all can change for a full
patch set of rmk, you, or me.

The "video-card" node combines all devices that will be available and
active on a specific Dove board. As you may have noticed about rmk's
driver, it is registering crtcs from IORESOURCE_MEM passed with the
platform_device.

To match with this approach we _have to_ recreate that platform_device
from what we see on DT. On DT each bus node gets registered as its own
platform_device. So in the video-card driver we look for node we know
of and put together a platform_device for rmk's driver. We cannot hook
DT upon either an lcd node nor dcon node as they might be disabled and
the driver will get called multiple times.


It seems we are moving backwards:
- what about the display controller?


That would be part of probing DT nodes above. I did not take care of
that because rmk doesn't support dcon for now.


- how do you clone the lcd 0 output to the port B?


Pass properties on video-card node or even better let dcon driver
take care of it when it sees a video-card with more than one crtc.


- what occurs when the si5351 and the tda998x are modules?


Touche, forgot that part. Feel free to add module support to the
RFC.


My driver had the same layout as Russell's when I proposed it to you
and when you insisted to handle the 2 LCDs and the 2 ports as one card.


I still insist to handle 2 LCDs and DCON.


I spent 2 months to have a nice design and you put it to garbage!
I am not happy...


I put nothing to garbage. _You_ also agreed to merge with rmk's driver!
We can now put in all features we implemented differently
_step-by-step_.

Merging the drivers starts with adding support for DT - that is what
I provided. You know the HW better than me, why don't you start picking
features from your driver and add them in rmk's driver?

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

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth


On 05/18/2013 07:46 PM, Jean-Francois Moine wrote:

On Sat, 18 May 2013 19:12:19 +0200
Sebastian Hesselbarth  wrote:


The RFC sent by Russell King was missing an include for tda998x. This
is just a compatible clone to remember Russell to add that later.

Signed-off-by: Sebastian Hesselbarth

...

These parameters should not be there. It seems to me that the DT is the
right place.


True, but if you just read the description above:
"RFC sent by Russell King was missing an include for tda998x".

You want to test the RFC, you need that include.

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

Re: [RFC 2/4] ARM: dove: add video card node for SolidRun CuBox

2013-05-18 Thread Sebastian Hesselbarth


On 05/18/2013 07:33 PM, Jean-Francois Moine wrote:

On Sat, 18 May 2013 19:12:17 +0200
Sebastian Hesselbarth  wrote:

This adds a video card node required for rmk's dove_drm driver. Reg
property matches reserved memory region (currently 16M at top of memory),
clocks property should carry extclk0 for now.

Signed-off-by: Sebastian Hesselbarth
---

...

+   vcard: video-card {
+   compatible = "marvell,dove-video-card";
+   reg =<0x3f00 0x100>;
+   clocks =<&si5351 0>,<&si5351 0>;
+   };
+   };

...

+&lcd0 { status = "okay"; };


May you explain a bit more this strange hack?


This "hack" adds the video-card device node that describes the board
dependent part of Dove SoC video. Remember, it is a device tree node
to match Russel's driver!

You have the video memory passed, the clocks property will vanish
later. And you enable lcd0 as you may have noticed that there is
nothing connected on lcd1 on the _CuBox_.

But there is on the D2Plug, and that DT description _will_ enable
lcd0, lcd1 and dcon.

Maybe, there is a misunderstanding in in the concept of DT here.
DT does _not_ describe the driver layout but the HW. And for Linux
this basically means, you replace board/SoC dependent init code
that register some platform_device with a description in DT.

The actual driver does _not_ need to know about non-DT or DT except
that somebody has to parse it and create a platform_device for it.
If you only have standard properties like reg and irq, it all gets
parsed automagically by DT bus probing. But as you already pointed
out, a video card on Dove is a little bit more complex as reg and
irq - so I provided a DT parser for rmk's *RFC* driver as *RFC*!

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

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 14:23:19 -0400
Rob Clark  wrote:

> > These parameters should not be there. It seems to me that the DT is the
> > right place.  
> 
> You might not want to directly have a hard DT dependency in tda998x,
> as the encoder could be used on non-DT platforms.  Although a DT to
> encoder-params helper might be a nice idea for platforms which do have
> DT.

If I correctly understand:

- Russell does not use any DT, so his drm driver should be declared in
  some cubox-setup code in mach-dove/

- this code should also declare the tda998x

- the drm driver contains/passes parameters to the tda998x

As the connection Dove LCD <-> tda998x is Cubox specific, the question
is: why are'nt the tda998x parameters in the cubox-setup code?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 20:20:00 +0200
Sebastian Hesselbarth  wrote:

> I put nothing to garbage. _You_ also agreed to merge with rmk's driver!
> We can now put in all features we implemented differently
> _step-by-step_.
> 
> Merging the drivers starts with adding support for DT - that is what
> I provided. You know the HW better than me, why don't you start picking
> features from your driver and add them in rmk's driver?

The general hardware code of both drivers is close enough for merging
may be done starting from anyone. But the general layout is not:

- my driver is DT driven and has one card with 2 CTRC's and 2 connectors.

- Russell's is non-DT, so, with some extra code I am not aware of, with
  any number of cards each one with one CRTC and one connector (no, I
  tried it, you cannot clone a connector of one card to the connector
  of another card).

So, for me, merging means enhance my code from Russell's, but I will
not go to a non-DT kernel.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

2013-05-18 Thread Niels Ole Salscheider

Add ULL prefix to avoid overflow.

Signed-off-by: Niels Ole Salscheider 
---
 drivers/gpu/drm/radeon/evergreen.c  | 4 ++--
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 drivers/gpu/drm/radeon/si.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 105bafb..06c261b 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3405,8 +3405,8 @@ int evergreen_mc_init(struct radeon_device *rdev)
rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
} else {
/* size in MB on evergreen/cayman/tn */
-   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
-   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
1024ULL;
+   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
1024ULL;
}
rdev->mc.visible_vram_size = rdev->mc.aper_size;
r700_vram_gtt_location(rdev, &rdev->mc);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 93f760e..6c0ce89 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -726,7 +726,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
return r;
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
-(unsigned)rdev->mc.real_vram_size / (1024 * 1024));
+(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
rdev->mc.gtt_size >> PAGE_SHIFT);
if (r) {
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f0b6c2f..113ed9f 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -3397,8 +3397,8 @@ static int si_mc_init(struct radeon_device *rdev)
rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
/* size in MB on si */
-   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
-   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
rdev->mc.visible_vram_size = rdev->mc.aper_size;
si_vram_gtt_location(rdev, &rdev->mc);
radeon_update_bandwidth_info(rdev);
-- 
1.8.2.3

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

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth


On 05/18/2013 08:58 PM, Jean-Francois Moine wrote:

On Sat, 18 May 2013 14:23:19 -0400
Rob Clark  wrote:


These parameters should not be there. It seems to me that the DT is the
right place.


You might not want to directly have a hard DT dependency in tda998x,
as the encoder could be used on non-DT platforms.  Although a DT to
encoder-params helper might be a nice idea for platforms which do have
DT.


If I correctly understand:

- Russell does not use any DT, so his drm driver should be declared in
   some cubox-setup code in mach-dove/


No. The _device_ is declared in some cubox-setup but the _driver_ goes
into drivers/gpu/drm. Reading vendor provided kernel code may be
misleading as they often just put all stuff in arch/arm/mach-something.


- this code should also declare the tda998x


The device for tda998x yes, but not the driver. Anyway, Russel decided
to have tda998x probed by his drm_driver.


- the drm driver contains/passes parameters to the tda998x

As the connection Dove LCD<->  tda998x is Cubox specific, the question
is: why are'nt the tda998x parameters in the cubox-setup code?


The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
as you can find the very same controller on other Marvell SoCs with
little differences.

So in the end, we will have a DT node for the HW controllers found
in Dove SoCs, a node for TDA998x, and a node for the video card, i.e.
_how_ lcd controllers, external encoders, clocks, maybe audio, ...
are hooked up on that specific board.

There is so much to take care of like pixel format on lcd pins driving
an external encoder (_not_ only tda998x), what gpio pin is connected to
TDA interrupt line, one or two lcds, ...

The corresponding drivers _will_ take care of it .. but in the future.
All I try to make sure is that driver architecture does not prevent us
from e.g. having two lcds plus dcon later on. Or allows to reuse
dove-drm on pxa where only one lcd but no dcon is available.

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

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Russell King - ARM Linux

On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
> The device for tda998x yes, but not the driver. Anyway, Russel decided
> to have tda998x probed by his drm_driver.

For the simple reason that _that_ is how DRM slave encoders work.
Sometimes, reading the code of the subsystem you're using is well
worth the effort.

If Jean-Francois would like to read drm_encoder_slave.c, then it will
be found that in order to use the TDA998x driver, which is itself a
DRM slave encoder, you must use drm_i2c_encoder_init().  In order to
use that, you must provide the I2C adapter structure, and a board
info structure.

If you don't want to do that, your options are:
(a) you don't use the existing TDA998x DRM slave encoder, and instead
write your own TDA998x driver, which will likely be justifyable
rejected, or
(b) you propose a new DRM interface to allow DRM components to be
registered independently, without reference to a core drm_device
structure.

> The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
> also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
> as you can find the very same controller on other Marvell SoCs with
> little differences.

Well, to spoil the argument a little, actually, the interconnection
between the two is in no way "standardized".  There's many different
ways to wire the two chips together and have it work - because the
TDA998x chips have a set of input muxes and swaps which allow you to
connect the red, green, blue high/low nibbles in various ways and
still have a correctly working system.  The TDA998x connectivity is
_highly_ configuable.

So, just because one board connects LCD_D0 (red bit 0) to a particular
pin on the TDA998x does not mean that another board does it that way
too.

So Jean-Francois is quite correct that this data needs to be provided
by the board in some manner.  The question is - how to do that sensibly.

One possible stop-gap solution is to provide a default set which just
happens to match the cubox, and allow OF to override it. :)

> There is so much to take care of like pixel format on lcd pins driving
> an external encoder (_not_ only tda998x), what gpio pin is connected to
> TDA interrupt line, one or two lcds, ...

Luckily, drivers/gpu/drm/i2c/tda998x.c does not make use of the IRQ
signal at present - it's fairly basic and it currently operates by
polling.  Eventually, this could change of course. :)

I think people need to keep a sense of perspective here: this is all
entirely "new" stuff which is still being actively developed.  It is
not fully polished.  We've not had a true open source TDA998x driver
before 3.9 (that's when it was introduced.)  It has teething problems
at the moment, but I'm working with the authors to resolve these issues.
I'm also still working on the DRM driver.

For example, I've been playing with the RGB888 cursor support today,
which seems to be suffering from a one pixel error in the hotspot
location.  I've not got to the bottom of it, but that kind of error
_is_ important to understand and resolve, because it means that
things like drawing programmes become unusable.

What I'm starting to suspect is a bug in the X server causing this
and not either my DRM driver or Xorg driver.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Russell King - ARM Linux

On Sat, May 18, 2013 at 07:45:02PM +0200, Jean-Francois Moine wrote:
> It seems we are moving backwards:
> - what about the display controller?
> - how do you clone the lcd 0 output to the port B?
> - what occurs when the si5351 and the tda998x are modules?

I've no idea why you keep bringing that last point up.  I've already
told you what happens when the SI5351 is a module.  It is already not
a problem as I have already evidenced by my boot log.  So please get
that and stop repeating this same point which I've already answered,
or I will start ranting at you and we will have a massive falling out.

As for cloning output to the VGA port, that's just a matter of dealing
with the display controller.  That's _not_ difficult.

> My driver had the same layout as Russell's when I proposed it to you
> and when you insisted to handle the 2 LCDs and the 2 ports as one card.

This seems to be a misrepresentation.  So what you're saying is that
your driver originally handled the two LCDs as two separate cards.

That is _not_ the same as my driver.  My driver handles the two LCDs
as two separate CRTs of the same DRM device.  This allows X to drive
the two CRTs together in any manner it desires depending on the
capabilities of the "connectors" associated with each CRTC and the
user preferences.

> I spent 2 months to have a nice design and you put it to garbage!
> I am not happy...

Stop that right now.  If you want to start whinging about the amount of
time you've spent on this, then I can tell you now that if you have only
spent two months on this, you are a total newbie to this and your effort
is utterly insignificant compared to mine.  And you *have* touched a
nerve here by making that statement.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth


On 05/18/2013 10:26 PM, Russell King - ARM Linux wrote:

On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:

The device for tda998x yes, but not the driver. Anyway, Russel decided
to have tda998x probed by his drm_driver.


For the simple reason that _that_ is how DRM slave encoders work.
Sometimes, reading the code of the subsystem you're using is well
worth the effort.


I agree and add that the probing itself doesn't prevent you from using
DT for tda driver at all. You can still have an marvell,external-slave
property pointing to the phandle of tda node. With that you get the
adapter and i2c slave address for what is currently called
dove_tda19989.c and may become e.g. dove_ext_i2c.c. In tda998x_drv you
find the node and get all properties for input config or interrupt
gpio.

I have done that in the drivers before, but DT node parsing here is
_added_ to the driver as it can be used on other non-DT platforms as
well.


The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
as you can find the very same controller on other Marvell SoCs with
little differences.


Well, to spoil the argument a little, actually, the interconnection
between the two is in no way "standardized".  There's many different
ways to wire the two chips together and have it work - because the
TDA998x chips have a set of input muxes and swaps which allow you to
connect the red, green, blue high/low nibbles in various ways and
still have a correctly working system.  The TDA998x connectivity is
_highly_ configuable.

So, just because one board connects LCD_D0 (red bit 0) to a particular
pin on the TDA998x does not mean that another board does it that way
too.

So Jean-Francois is quite correct that this data needs to be provided
by the board in some manner.  The question is - how to do that sensibly.

One possible stop-gap solution is to provide a default set which just
happens to match the cubox, and allow OF to override it. :)


While I agree, Rob may have a different view on that for tda998x ;)


There is so much to take care of like pixel format on lcd pins driving
an external encoder (_not_ only tda998x), what gpio pin is connected to
TDA interrupt line, one or two lcds, ...


Luckily, drivers/gpu/drm/i2c/tda998x.c does not make use of the IRQ
signal at present - it's fairly basic and it currently operates by
polling.  Eventually, this could change of course. :)


Again, that is in the driver Jean-Francois has available. Make sure irq
handler runs in a separate thread from get_edid and hpd and you will
be interrupted on hpd. Having said, that should finally lead to the
slave encoder setting .connector_type and .polled as this is where you
know it.

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

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

2013-05-18 Thread bugzilla-daemon

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

--- Comment #33 from Tom Stellard  ---
(In reply to comment #32)
> Created attachment 79504 [details]
> Results of OpenCL test
> 
> BREAKTHROUGH!
> 
> OpenCL works. Kinda. Tried the following kernel:
> __kernel void add(__global const uint *a,  __global const uint *b, __global
> uint *c){
> c[0]=1;
> }
> Complicated operations such as addition, memory loads, getting global ID,
> etc. fail with Cannot select errors.
> I have no idea if this has worked with earlier LLVM/mesa.
> 

All that is supported in the git tree is stores to global memory.  I have
global loads, work item functions, and a fair amount of arithmetic operations
working in a local branch, and I hope to get that pushed to mainline in the
next week or two.

> After the kernel is run, the 0-th element of c is equal to 1. I've attached
> full source code and outputs for various kernels.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-18 Thread bugzilla-daemon

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

--- Comment #11 from Tom Stellard  ---
(In reply to comment #10)
> I've now recompiled everything from upstream - kwin now renders however it
> has a pinkish hugh to the bottom right - this didn't happen when I tested
> the patches separately

It's possible that the recent scheduling changes have caused an unrelated
regression.  Does kwin render correctly if you use the LLVM 3.3 branch?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[i915] Backlight brighter since 3.9.0

2013-05-18 Thread Jan Hinnerk Stosch

Hallo,

I hope this is the right place to ask, because I actually don't know
whether it is a bug or a feature that I'm experiencing since linux 3.9:
When I boot my system the backlight gets extremely bright compared to older
kernel versions. It is most obvious when I leave X (more a yellow than a
black background), but I have the impression, that the colors in X are
brighter than usual, too.
I used my spare time this afternoon to do a kernel bisect and learned that
the first "bad" commit is 55bc60db5988c8366751d3d04dd690698a53412c. As I
don't have insight or understanding of the code: Is this behaviour intended
and how could I change it to the old state or is it a bug and should I
report it somewhere?
My system is as follows:
Intel i5-3570k with Intel HD 4000
my monitor is connected via HDMI.
If you need any more information just tell me.

Thanks in advance,

jhs
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130518/6a7d3096/attachment.html>

[Bug 64443] Oil Rush (Steam version) crashes

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from romulasry at gmail.com ---
(In reply to comment #3)
> But that's still several months out, and you probably don't want to wait
> that long.  In the meantime, you can do:
> export MESA_GL_VERSION_OVERRIDE=3.2
> export MESA_GLSL_VERSION_OVERRIDE=150
> 
> before launching OilRush...and it should work.  I haven't tested it
> specifically but that works for both Unigine Heaven and Unigine Valley.
> 
> It might be worth adding a driconf setting to overrides these in a 9.1.4
> release...not sure what people think about that.

That screws up steam though, I get a whole bunch of these:
/home/buildbot/buildslave_steam/steam_rel_client_ubuntu12_linux/build/src/vgui2/src/surface_opengl.cpp
(569) : Assertion Failed: glIsTexture( id )
/home/buildbot/buildslave_steam/steam_rel_client_ubuntu12_linux/build/src/vgui2/src/surface_opengl.cpp
(785) : Assertion Failed: glIsTexture( nTextureID ) == GL_TRUE

-- 
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/20130518/8f8dfdcc/attachment.html>

[Bug 64443] Oil Rush (Steam version) crashes

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from romulasry at gmail.com ---
(In reply to comment #3)
> But that's still several months out, and you probably don't want to wait
> that long.  In the meantime, you can do:
> export MESA_GL_VERSION_OVERRIDE=3.2
> export MESA_GLSL_VERSION_OVERRIDE=150
> 
> before launching OilRush...and it should work.  I haven't tested it
> specifically but that works for both Unigine Heaven and Unigine Valley.
> 
> It might be worth adding a driconf setting to overrides these in a 9.1.4
> release...not sure what people think about that.

I used that and I still the the exact same error when I click "run".

-- 
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/20130518/4a22dd23/attachment-0001.html>

[Bug 63579] Savage 2 Edges render white [r600g]

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #19 from romulasry at gmail.com ---
Is this patch upsteam in git?

-- 
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/20130518/fa202300/attachment.html>

Introduce a new helper framework for buffer synchronization

2013-05-18 Thread Inki Dae

 committing processing means that
> a
> > current thread possesses the shared buffer so any trying to access the
> > shared buffer by another thread makes the thread to be blocked. However,
> as
> > I already mentioned before, it seems that these user interfaces are so
> ugly
> > yet. So we need better way.
> >
> > Give me more comments if there is my missing point :)
> >
> > Thanks,
> > Inki Dae
> >
> >> BR,
> >> -R
> >>
> >>
> >> > 2) finish-access (dma_buf_end _cpu_access)
> >> > 3) dma access to buffer
> >> >
> >> > 1) and 2) are coupled with one function: we have implemented
> >> > fence_helper_commit_reserve() for it.
> >> >
> >> > Cache control(cache clean or cache invalidate) is performed properly
> >> > checking previous access type and current access type.
> >> > And the below is actual codes for it,
> >
> ___
> 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/20130518/414bedd9/attachment.html>

Introduce a new helper framework for buffer synchronization

2013-05-18 Thread Inki Dae

Hi Daniel,

2013/5/17 Daniel Vetter 

> On Wed, May 15, 2013 at 4:06 PM, Rob Clark  wrote:
> > So while it seems nice and orthogonal/clean to couple cache and
> > synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
> > same generic way, but I think in practice we have to make things more
> > complex than they otherwise need to be to do this.  Otherwise I think
> > we'll be having problems with badly behaved or crashing userspace.
>
> I haven't read through the entire thread careful but imo this is very
> important. If we add a fence interface which allows userspace to block
> dma this is a no-go. The only thing we need is to sync up with all
> outstanding dma operations and flush caches for cpu access. If broken
> userspace starts to issue new dma (or multiple thread stomp onto each
> another) that's not a problem dma fences/syncpoints should try to
> solve.

I'm not sure that I understood your concerns but it seems that you say we
have to prohibit userspace from blocking dma. Could you please give me more
detail for it? Without critical problem by userspace, this appoach is a
better way against the traditional at least for ARM based embedded system.
For this, I had already mentioned before like below,
   http://www.spinics.net/lists/dri-devel/msg38359.html

If you agree to my opinion, I'd like to say we could try to solve this
problem in the long term. If we prohibit such interfaces from be used
without sure reason, I carefully think we might to be just going thourgh
the motions: we have to use traditional way NECESSARILY. As previously
stated, could please tell me about that there are sure reasons we have to
prohibit the such user interfaces from being used necessarily and
there is really no any way we have to solve that? Basically, I have
designed and implemented that all resources to user fence are freed once
timed out so that the user cannot affect the other anymore. However, I'm
sure that there are things I didn't cach up. As I already mentioned, the
purpose of this post is to collect other opinions and advices for better
something else. Of course, we have to concentrate on solving the
device-to-device sync issues first.

Thanks,
Inki Dae

> This way we can concentrate on solving the (already
> challenging) device-to-device sync issues without additional
> complexities which cpu->cpu sync would impose.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> 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/20130518/60d33702/attachment-0001.html>

[Bug 64738] New: graphics corruption with glamor

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

  Priority: medium
Bug ID: 64738
  Assignee: dri-devel at lists.freedesktop.org
   Summary: graphics corruption with glamor
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: alexander at tsoy.me
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

I have these problems with Cape Verde Pro (HD 7750) card:
1. Graphics corruption when scrolling in gtk2/gtk3 apps (screenshot [1])
2. Graphics corruption when moving windows in wm whithout compositing. Both gtk
and qt apps are affected. No such artifacts when compositing enabled, e.g. in
gnome 3. (screenshot [2])
3. Missing notification icons of gtk2 apps in awesome wm.

All of this things works great whithout glamor. Also no such problems with HD
6450 card with both EXA and glamor acceleration.

Software:
- mesa-9.2 from git
- llvm-3.{3,4} from git
- xorg-server-1.13.4, also tried 1.12*
- xf86-video-ati-7.1.0
- glamor-0.5
- linux kernel 3.8* including latest 3.8.13

Also note, that with mesa-9.0* and mesa-9.1* Xorg segfaults at startup on this
system when glamor enabled, but this is a subject for another bug report.

-- 
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/20130518/322890cf/attachment.html>

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Alexander Tsoy  ---
Created attachment 79494
  --> https://bugs.freedesktop.org/attachment.cgi?id=79494&action=edit
screenshot [1]

-- 
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/20130518/a33be9c4/attachment.html>

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Alexander Tsoy  ---
Created attachment 79495
  --> https://bugs.freedesktop.org/attachment.cgi?id=79495&action=edit
screenshot [2]

-- 
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/20130518/fee187d9/attachment.html>

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Alexander Tsoy  ---
Created attachment 79496
  --> https://bugs.freedesktop.org/attachment.cgi?id=79496&action=edit
Xorg log

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

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Alexander Tsoy  ---
This graphics artifacts are persist until the window is redrawn.

-- 
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/20130518/216c4d3a/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #10 from Mike Lothian  ---
I've now recompiled everything from upstream - kwin now renders however it has
a pinkish hugh to the bottom right - this didn't happen when I tested the
patches separately

-- 
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/20130518/ee5e6339/attachment.html>

[Bug 63579] Savage 2 Edges render white [r600g]

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #20 from Alex Deucher  ---
yes:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=f732036f12d67a96f546c11236fa635b3eda6e9c

-- 
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/20130518/4a2e7077/attachment.html>

[Bug 64738] graphics corruption with glamor

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Alexander Tsoy  ---
Created attachment 79497
  --> https://bugs.freedesktop.org/attachment.cgi?id=79497&action=edit
Screenshot of notification area

No claws-mail and gajim icons here.

-- 
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/20130518/03933c73/attachment-0001.html>

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Rob Clark

On Sat, May 18, 2013 at 1:46 PM, Jean-Francois Moine  wrote:
> On Sat, 18 May 2013 19:12:19 +0200
> Sebastian Hesselbarth  wrote:
>
>> The RFC sent by Russell King was missing an include for tda998x. This
>> is just a compatible clone to remember Russell to add that later.
>>
>> Signed-off-by: Sebastian Hesselbarth 
>> ---
>> Cc: Russell King 
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: Jason Cooper 
>> Cc: Jean-Francois Moine 
>> ---
>>  include/drm/i2c/tda998x.h |   23 +++
>>  1 file changed, 23 insertions(+)
>>  create mode 100644 include/drm/i2c/tda998x.h
>>
>> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
>> new file mode 100644
>> index 000..41f799f
>> --- /dev/null
>> +++ b/include/drm/i2c/tda998x.h
>> @@ -0,0 +1,23 @@
>> +#ifndef __TDA998X_H__
>> +#define __TDA998X_H__
>> +
>> +enum tda998x_audio_format {
>> + AFMT_I2S,
>> + AFMT_SPDIF,
>> +};
>> +
>> +struct tda998x_encoder_params {
>> + int audio_cfg;
>> + int audio_clk_cfg;
>> + enum tda998x_audio_format audio_format;
>> + int audio_sample_rate;
>> + char audio_frame[6];
>> + int swap_a, mirr_a;
>> + int swap_b, mirr_b;
>> + int swap_c, mirr_c;
>> + int swap_d, mirr_d;
>> + int swap_e, mirr_e;
>> + int swap_f, mirr_f;
>> +};
>> +
>> +#endif
>
> These parameters should not be there. It seems to me that the DT is the
> right place.

You might not want to directly have a hard DT dependency in tda998x,
as the encoder could be used on non-DT platforms.  Although a DT to
encoder-params helper might be a nice idea for platforms which do have
DT.

BR,
-R

> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef |   http://moinejf.free.fr/
>
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Rob Clark

On Sat, May 18, 2013 at 2:58 PM, Jean-Francois Moine  wrote:
> On Sat, 18 May 2013 14:23:19 -0400
> Rob Clark  wrote:
>
>> > These parameters should not be there. It seems to me that the DT is the
>> > right place.
>>
>> You might not want to directly have a hard DT dependency in tda998x,
>> as the encoder could be used on non-DT platforms.  Although a DT to
>> encoder-params helper might be a nice idea for platforms which do have
>> DT.
>
> If I correctly understand:
>
> - Russell does not use any DT, so his drm driver should be declared in
>   some cubox-setup code in mach-dove/
>
> - this code should also declare the tda998x
>
> - the drm driver contains/passes parameters to the tda998x
>
> As the connection Dove LCD <-> tda998x is Cubox specific, the question
> is: why are'nt the tda998x parameters in the cubox-setup code?

ok, maybe I am misunderstanding you.  I think the parameters should be
filled in by the board file on a non-DT setup.  But the part in
drivers/gpu/drm/i2c should not pull them directly out of DT, or should
have an arrangement like

 #ifdef CONFIG_OF
 .. pull params out of DT ..
#else
 .. use params passed in from via params struct, which is populated in
board file ..
#endif

to accommodate non-DT builds.  (Although I think just having a helper
to populate 'struct tda998x_encoder_params' from DT seems cleaner.)

BR,
-R

> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef |   http://moinejf.free.fr/

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #32 from Hristo Venev  ---
Created attachment 79504
  --> https://bugs.freedesktop.org/attachment.cgi?id=79504&action=edit
Results of OpenCL test

BREAKTHROUGH!

OpenCL works. Kinda. Tried the following kernel:
__kernel void add(__global const uint *a,  __global const uint *b, __global
uint *c){
c[0]=1;
}
Complicated operations such as addition, memory loads, getting global ID, etc.
fail with Cannot select errors.
I have no idea if this has worked with earlier LLVM/mesa.

After the kernel is run, the 0-th element of c is equal to 1. I've attached
full source code and outputs for various kernels.

-- 
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/20130518/a5c2fd57/attachment.html>

[RFC 3/8] drm/i2c: nxp-tda998x: ensure VIP output mux is properly set

2013-05-18 Thread Jean-Francois Moine

On Thu, 16 May 2013 20:26:18 +0100
Russell King  wrote:

> When switching between various drivers for this device, it's possible
> that some critical registers are left containing values which affect
> the device operation.  One such case encountered is the VIP output
> mux register.  This defaults to 0x24 on powerup, but other drivers may
> set this to 0x12.  This results in incorrect colours.
> 
> Fix this by ensuring that the register is always set to the power on
> default setting.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/tda998x_drv.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index d71c408..4b4db95 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -110,6 +110,7 @@ struct tda998x_priv {
>  #define REG_VIP_CNTRL_5   REG(0x00, 0x25) /* write */
>  # define VIP_CNTRL_5_CKCASE   (1 << 0)
>  # define VIP_CNTRL_5_SP_CNT(x)(((x) & 3) << 1)
> +#define REG_MUX_VP_VIP_OUTREG(0x00, 0x27) /* read/write */
>  #define REG_MAT_CONTRLREG(0x00, 0x80) /* write */
>  # define MAT_CONTRL_MAT_SC(x) (((x) & 3) << 0)
>  # define MAT_CONTRL_MAT_BP(1 << 2)
> @@ -438,6 +439,8 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int 
> mode)
>  
>   switch (mode) {
>   case DRM_MODE_DPMS_ON:
> + /* Write the default value MUX register */
> + reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
>   /* enable audio and video ports */
>   reg_write(encoder, REG_ENA_AP, 0xff);
>   reg_write(encoder, REG_ENA_VP_0, 0xff);

This register is never touched. Should not this setting better go at
reset time (in tda998x_reset)?

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[RFC 2/4] ARM: dove: add video card node for SolidRun CuBox

2013-05-18 Thread Sebastian Hesselbarth

This adds a video card node required for rmk's dove_drm driver. Reg
property matches reserved memory region (currently 16M at top of memory),
clocks property should carry extclk0 for now.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 arch/arm/boot/dts/dove-cubox.dts |   16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index ed2b7b2..f26d0d2 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -8,7 +8,7 @@

memory {
device_type = "memory";
-   reg = <0x 0x4000>;
+   reg = <0x 0x3f00>;
};

chosen {
@@ -52,10 +52,24 @@
#clock-cells = <0>;
};
};
+
+   video {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   vcard: video-card {
+   compatible = "marvell,dove-video-card";
+   reg = <0x3f00 0x100>;
+   clocks = <&si5351 0>, <&si5351 0>;
+   };
+   };
 };

 &uart0 { status = "okay"; };
 &sata0 { status = "okay"; };
+&lcd0 { status = "okay"; };

 &i2c0 {
status = "okay";
-- 
1.7.10.4

[RFC 1/4] ARM: dove: add lcd controller DT nodes

2013-05-18 Thread Sebastian Hesselbarth

This adds device tree nodes for the lcd controllers found on Marvell
Dove SoCs. For now, there is no DT documentation and clocks property
should refer to clock connected to extclk0 pin.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 arch/arm/boot/dts/dove.dtsi |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..2053e86 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -258,5 +258,21 @@
dmacap,xor;
};
};
+
+   lcd0: lcd-controller at 82 {
+   compatible = "marvell,dove-lcd";
+   reg = <0x82 0x200>;
+   interrupts = <47>;
+   clocks = <0>;
+   status = "disabled";
+   };
+
+   lcd1: lcd-controller at 81 {
+   compatible = "marvell,dove-lcd";
+   reg = <0x81 0x200>;
+   interrupts = <46>;
+   clocks = <0>;
+   status = "disabled";
+   };
};
 };
-- 
1.7.10.4

[RFC 0/4] Add DT support to rmk's Dove DRM driver

2013-05-18 Thread Sebastian Hesselbarth

This RFC adds DT support to the DRM driver for Marvell Dove SoCs
posted by Russell King recently. For those booting DT with appended
ATAGs, remember to reduce probed memory by passing mem=1008M as
kernel parameter.

There was an include missing in Russell's RFC that is also added.

Sebastian Hesselbarth (4):
  ARM: dove: add lcd controller DT nodes
  ARM: dove: add video card node for SolidRun CuBox
  DRM: add OF support for Dove DRM driver
  DRM: tda998x: add missing include

 arch/arm/boot/dts/dove-cubox.dts |   16 +-
 arch/arm/boot/dts/dove.dtsi  |   16 ++
 drivers/gpu/drm/dove/Kconfig |4 ++
 drivers/gpu/drm/dove/Makefile|1 +
 drivers/gpu/drm/dove/dove_card.c |  110 ++
 include/drm/i2c/tda998x.h|   23 
 6 files changed, 169 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/dove/dove_card.c
 create mode 100644 include/drm/i2c/tda998x.h
---
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
-- 
1.7.10.4

[RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Sebastian Hesselbarth

This adds OF support for the Dove DRM driver recently posted as RFC by
Russell King.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 drivers/gpu/drm/dove/Kconfig |4 ++
 drivers/gpu/drm/dove/Makefile|1 +
 drivers/gpu/drm/dove/dove_card.c |  110 ++
 3 files changed, 115 insertions(+)
 create mode 100644 drivers/gpu/drm/dove/dove_card.c

diff --git a/drivers/gpu/drm/dove/Kconfig b/drivers/gpu/drm/dove/Kconfig
index 718d3c5..a943ea5 100644
--- a/drivers/gpu/drm/dove/Kconfig
+++ b/drivers/gpu/drm/dove/Kconfig
@@ -28,4 +28,8 @@ config DRM_DOVE_TDA1998X
 config DRM_DOVE_CURSOR
bool "Enable Dove DRM hardware cursor support"

+config DRM_DOVE_OF
+   bool "Enable Dove DRM OF video card"
+   depends on OF
+
 endif
diff --git a/drivers/gpu/drm/dove/Makefile b/drivers/gpu/drm/dove/Makefile
index 65c701e..f0b6eed 100644
--- a/drivers/gpu/drm/dove/Makefile
+++ b/drivers/gpu/drm/dove/Makefile
@@ -5,5 +5,6 @@ dove-y  := dove_crtc.o dove_drv.o dove_fb.o 
dove_fbdev.o \
 dove-$(CONFIG_DEBUG_FS) += dove_debugfs.o

 dove-$(CONFIG_DRM_DOVE_TDA1998X) += dove_tda19988.o
+dove-$(CONFIG_DRM_DOVE_OF) += dove_card.o

 obj-$(CONFIG_DRM_DOVE) := dove.o
diff --git a/drivers/gpu/drm/dove/dove_card.c b/drivers/gpu/drm/dove/dove_card.c
new file mode 100644
index 000..e4bcb5b
--- /dev/null
+++ b/drivers/gpu/drm/dove/dove_card.c
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2013
+ *   Sebastian Hesselbarth 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DOVE_LCD0_BASE 0x2
+#define DOVE_LCD1_BASE 0x1
+
+static struct resource dove_drm_resources[5];
+static struct platform_device dove_drm_platform_device = {
+   .name = "dove-drm",
+   .id = 0,
+   .dev = { .coherent_dma_mask = ~0, },
+   .resource = dove_drm_resources,
+};
+
+static int dove_card_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *lcdnp;
+   struct resource *res = dove_drm_resources;
+   int ret, n = 0, crtcs = 0;
+
+   /* get video memory resource */
+   if (of_address_to_resource(np, 0, &res[n++])) {
+   dev_err(&pdev->dev, "invalid or missing video memory\n");
+   return -EINVAL;
+   }
+
+   /* get reg and irq resource from each enabled lcdc */
+   for_each_compatible_node(lcdnp, NULL, "marvell,dove-lcd") {
+   struct clk_lookup *cl;
+   struct clk *clk;
+   int lcd;
+
+   if (!of_device_is_available(lcdnp))
+   continue;
+
+   ret = of_address_to_resource(lcdnp, 0, &res[n]);
+   if (ret)
+   return ret;
+   lcd = ((res[n].start & 0xf) == DOVE_LCD1_BASE);
+   n++;
+
+   ret = of_irq_to_resource(lcdnp, 0, &res[n]);
+   if (ret < 0)
+   return ret;
+   n++;
+
+   crtcs++;
+
+   clk = clk_get(&pdev->dev, NULL);
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   if (ret == -ENOENT)
+   return -EPROBE_DEFER;
+   return ret;
+   }
+
+   /* add clock alias for dovefb.0 */
+   cl = clkdev_alloc(clk, "extclk", "dovefb.0");
+   if (cl)
+   clkdev_add(cl);
+   clk_put(clk);
+   }
+
+   if (!crtcs)
+   return -ENODEV;
+
+   dove_drm_platform_device.num_resources = n;
+   ret = platform_device_register(&dove_drm_platform_device);
+   if (ret) {
+   dev_err(&pdev->dev, "unable to register drm device\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct of_device_id dove_card_of_ids[] = {
+   { .compatible = "marvell,dove-video-card", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, dove_card_of_ids);
+
+static struct platform_driver dove_card_driver = {
+   .probe  = dove_card_probe,
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = "dove-drm-card",
+   .of_match_table = of_match_ptr(dove_card_of_ids),
+   },
+};
+module_platform_driver(dove_card_driver);
+
+MODULE_AUTHOR("Sebastian Hesselbarth ");
+MODULE_DESCRIPTION("Dove DRM Graphics Card");
+MODULE_LICENSE("GPL");
-- 
1.7.10.4

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth

The RFC sent by Russell King was missing an include for tda998x. This
is just a compatible clone to remember Russell to add that later.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
Cc: Jason Cooper 
Cc: Jean-Francois Moine 
---
 include/drm/i2c/tda998x.h |   23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 include/drm/i2c/tda998x.h

diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
new file mode 100644
index 000..41f799f
--- /dev/null
+++ b/include/drm/i2c/tda998x.h
@@ -0,0 +1,23 @@
+#ifndef __TDA998X_H__
+#define __TDA998X_H__
+
+enum tda998x_audio_format {
+   AFMT_I2S,
+   AFMT_SPDIF,
+};
+
+struct tda998x_encoder_params {
+   int audio_cfg;
+   int audio_clk_cfg;
+   enum tda998x_audio_format audio_format;
+   int audio_sample_rate;
+   char audio_frame[6];
+   int swap_a, mirr_a;
+   int swap_b, mirr_b;
+   int swap_c, mirr_c;
+   int swap_d, mirr_d;
+   int swap_e, mirr_e;
+   int swap_f, mirr_f;
+};
+
+#endif
-- 
1.7.10.4

[RFC 2/4] ARM: dove: add video card node for SolidRun CuBox

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 19:12:17 +0200
Sebastian Hesselbarth  wrote:

> This adds a video card node required for rmk's dove_drm driver. Reg
> property matches reserved memory region (currently 16M at top of memory),
> clocks property should carry extclk0 for now.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jason Cooper 
> Cc: Jean-Francois Moine 
> ---
>  arch/arm/boot/dts/dove-cubox.dts |   16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/dove-cubox.dts 
> b/arch/arm/boot/dts/dove-cubox.dts
> index ed2b7b2..f26d0d2 100644
> --- a/arch/arm/boot/dts/dove-cubox.dts
> +++ b/arch/arm/boot/dts/dove-cubox.dts
> @@ -8,7 +8,7 @@
>  
>   memory {
>   device_type = "memory";
> - reg = <0x 0x4000>;
> + reg = <0x 0x3f00>;
>   };
>  
>   chosen {
> @@ -52,10 +52,24 @@
>   #clock-cells = <0>;
>   };
>   };
> +
> + video {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + vcard: video-card {
> + compatible = "marvell,dove-video-card";
> + reg = <0x3f00 0x100>;
> + clocks = <&si5351 0>, <&si5351 0>;
> + };
> + };
>  };
>  
>  &uart0 { status = "okay"; };
>  &sata0 { status = "okay"; };
> +&lcd0 { status = "okay"; };
>  
>  &i2c0 {
>   status = "okay";

May you explain a bit more this strange hack?

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 19:12:18 +0200
Sebastian Hesselbarth  wrote:

> This adds OF support for the Dove DRM driver recently posted as RFC by
> Russell King.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jason Cooper 
> Cc: Jean-Francois Moine 
> ---
>  drivers/gpu/drm/dove/Kconfig |4 ++
>  drivers/gpu/drm/dove/Makefile|1 +
>  drivers/gpu/drm/dove/dove_card.c |  110 
> ++
>  3 files changed, 115 insertions(+)
>  create mode 100644 drivers/gpu/drm/dove/dove_card.c
> 
> diff --git a/drivers/gpu/drm/dove/Kconfig b/drivers/gpu/drm/dove/Kconfig
> index 718d3c5..a943ea5 100644
> --- a/drivers/gpu/drm/dove/Kconfig
> +++ b/drivers/gpu/drm/dove/Kconfig
> @@ -28,4 +28,8 @@ config DRM_DOVE_TDA1998X
>  config DRM_DOVE_CURSOR
>   bool "Enable Dove DRM hardware cursor support"
>  
> +config DRM_DOVE_OF
> + bool "Enable Dove DRM OF video card"
> + depends on OF
> +
>  endif
> diff --git a/drivers/gpu/drm/dove/Makefile b/drivers/gpu/drm/dove/Makefile
> index 65c701e..f0b6eed 100644
> --- a/drivers/gpu/drm/dove/Makefile
> +++ b/drivers/gpu/drm/dove/Makefile
> @@ -5,5 +5,6 @@ dove-y:= dove_crtc.o dove_drv.o 
> dove_fb.o dove_fbdev.o \
>  dove-$(CONFIG_DEBUG_FS) += dove_debugfs.o
>  
>  dove-$(CONFIG_DRM_DOVE_TDA1998X) += dove_tda19988.o
> +dove-$(CONFIG_DRM_DOVE_OF) += dove_card.o
>  
>  obj-$(CONFIG_DRM_DOVE) := dove.o
> diff --git a/drivers/gpu/drm/dove/dove_card.c 
> b/drivers/gpu/drm/dove/dove_card.c
> new file mode 100644
> index 000..e4bcb5b
> --- /dev/null
> +++ b/drivers/gpu/drm/dove/dove_card.c
> @@ -0,0 +1,110 @@
> +/*
> + * Copyright (C) 2013
> + *   Sebastian Hesselbarth 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DOVE_LCD0_BASE   0x2
> +#define DOVE_LCD1_BASE   0x1
> +
> +static struct resource dove_drm_resources[5];
> +static struct platform_device dove_drm_platform_device = {
> + .name = "dove-drm",
> + .id = 0,
> + .dev = { .coherent_dma_mask = ~0, },
> + .resource = dove_drm_resources,
> +};
> +
> +static int dove_card_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *lcdnp;
> + struct resource *res = dove_drm_resources;
> + int ret, n = 0, crtcs = 0;
> +
> + /* get video memory resource */
> + if (of_address_to_resource(np, 0, &res[n++])) {
> + dev_err(&pdev->dev, "invalid or missing video memory\n");
> + return -EINVAL;
> + }
> +
> + /* get reg and irq resource from each enabled lcdc */
> + for_each_compatible_node(lcdnp, NULL, "marvell,dove-lcd") {
> + struct clk_lookup *cl;
> + struct clk *clk;
> + int lcd;
> +
> + if (!of_device_is_available(lcdnp))
> + continue;
> +
> + ret = of_address_to_resource(lcdnp, 0, &res[n]);
> + if (ret)
> + return ret;
> + lcd = ((res[n].start & 0xf) == DOVE_LCD1_BASE);
> + n++;
> +
> + ret = of_irq_to_resource(lcdnp, 0, &res[n]);
> + if (ret < 0)
> + return ret;
> + n++;
> +
> + crtcs++;
> +
> + clk = clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + if (ret == -ENOENT)
> + return -EPROBE_DEFER;
> + return ret;
> + }
> +
> + /* add clock alias for dovefb.0 */
> + cl = clkdev_alloc(clk, "extclk", "dovefb.0");
> + if (cl)
> + clkdev_add(cl);
> + clk_put(clk);
> + }
> +
> + if (!crtcs)
> + return -ENODEV;
> +
> + dove_drm_platform_device.num_resources = n;
> + ret = platform_device_register(&dove_drm_platform_device);
> + if (ret) {
> + dev_err(&pdev->dev, "unable to register drm device\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id dove_card_of_ids[] = {
> + { .compatible = "marvell,dove-video-card", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, dove_card_of_ids);
> +
> +static struct platform_driver dove_card_driver = {
> + .probe  = dove_card_probe,
> + .driver = {
> + .owner  = THIS_MODULE,
> + .name   = "dove-drm-card",
> + .of_match_table = of_match_ptr(dove_card_of_ids),
> + },
> +};
> +module_platform_driver(dove_card_driver);
> +
> +MODULE_AUTHOR("Sebastian

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 19:12:19 +0200
Sebastian Hesselbarth  wrote:

> The RFC sent by Russell King was missing an include for tda998x. This
> is just a compatible clone to remember Russell to add that later.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jason Cooper 
> Cc: Jean-Francois Moine 
> ---
>  include/drm/i2c/tda998x.h |   23 +++
>  1 file changed, 23 insertions(+)
>  create mode 100644 include/drm/i2c/tda998x.h
> 
> diff --git a/include/drm/i2c/tda998x.h b/include/drm/i2c/tda998x.h
> new file mode 100644
> index 000..41f799f
> --- /dev/null
> +++ b/include/drm/i2c/tda998x.h
> @@ -0,0 +1,23 @@
> +#ifndef __TDA998X_H__
> +#define __TDA998X_H__
> +
> +enum tda998x_audio_format {
> + AFMT_I2S,
> + AFMT_SPDIF,
> +};
> +
> +struct tda998x_encoder_params {
> + int audio_cfg;
> + int audio_clk_cfg;
> + enum tda998x_audio_format audio_format;
> + int audio_sample_rate;
> + char audio_frame[6];
> + int swap_a, mirr_a;
> + int swap_b, mirr_b;
> + int swap_c, mirr_c;
> + int swap_d, mirr_d;
> + int swap_e, mirr_e;
> + int swap_f, mirr_f;
> +};
> +
> +#endif

These parameters should not be there. It seems to me that the DT is the
right place.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Sebastian Hesselbarth

On 05/18/2013 07:45 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 19:12:18 +0200
> Sebastian Hesselbarth  wrote:
>> This adds OF support for the Dove DRM driver recently posted as RFC by
>> Russell King.
>>
...

Jean-Francois,

one thing first: It is an RFC! It is to allow you to _test_ rmk's driver
on DT. Nothing more, nothing less.

I will comment on your questions but that all can change for a full
patch set of rmk, you, or me.

The "video-card" node combines all devices that will be available and
active on a specific Dove board. As you may have noticed about rmk's
driver, it is registering crtcs from IORESOURCE_MEM passed with the
platform_device.

To match with this approach we _have to_ recreate that platform_device
from what we see on DT. On DT each bus node gets registered as its own
platform_device. So in the video-card driver we look for node we know
of and put together a platform_device for rmk's driver. We cannot hook
DT upon either an lcd node nor dcon node as they might be disabled and
the driver will get called multiple times.

> It seems we are moving backwards:
> - what about the display controller?

That would be part of probing DT nodes above. I did not take care of
that because rmk doesn't support dcon for now.

> - how do you clone the lcd 0 output to the port B?

Pass properties on video-card node or even better let dcon driver
take care of it when it sees a video-card with more than one crtc.

> - what occurs when the si5351 and the tda998x are modules?

Touche, forgot that part. Feel free to add module support to the
RFC.

> My driver had the same layout as Russell's when I proposed it to you
> and when you insisted to handle the 2 LCDs and the 2 ports as one card.

I still insist to handle 2 LCDs and DCON.

> I spent 2 months to have a nice design and you put it to garbage!
> I am not happy...

I put nothing to garbage. _You_ also agreed to merge with rmk's driver!
We can now put in all features we implemented differently
_step-by-step_.

Merging the drivers starts with adding support for DT - that is what
I provided. You know the HW better than me, why don't you start picking
features from your driver and add them in rmk's driver?

Sebastian

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth

On 05/18/2013 07:46 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 19:12:19 +0200
> Sebastian Hesselbarth  wrote:
>
>> The RFC sent by Russell King was missing an include for tda998x. This
>> is just a compatible clone to remember Russell to add that later.
>>
>> Signed-off-by: Sebastian Hesselbarth
...
> These parameters should not be there. It seems to me that the DT is the
> right place.

True, but if you just read the description above:
"RFC sent by Russell King was missing an include for tda998x".

You want to test the RFC, you need that include.

Sebastian

[RFC 2/4] ARM: dove: add video card node for SolidRun CuBox

2013-05-18 Thread Sebastian Hesselbarth

On 05/18/2013 07:33 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 19:12:17 +0200
> Sebastian Hesselbarth  wrote:
>> This adds a video card node required for rmk's dove_drm driver. Reg
>> property matches reserved memory region (currently 16M at top of memory),
>> clocks property should carry extclk0 for now.
>>
>> Signed-off-by: Sebastian Hesselbarth
>> ---
...
>> +vcard: video-card {
>> +compatible = "marvell,dove-video-card";
>> +reg =<0x3f00 0x100>;
>> +clocks =<&si5351 0>,<&si5351 0>;
>> +};
>> +};
...
>> +&lcd0 { status = "okay"; };
>
> May you explain a bit more this strange hack?

This "hack" adds the video-card device node that describes the board
dependent part of Dove SoC video. Remember, it is a device tree node
to match Russel's driver!

You have the video memory passed, the clocks property will vanish
later. And you enable lcd0 as you may have noticed that there is
nothing connected on lcd1 on the _CuBox_.

But there is on the D2Plug, and that DT description _will_ enable
lcd0, lcd1 and dcon.

Maybe, there is a misunderstanding in in the concept of DT here.
DT does _not_ describe the driver layout but the HW. And for Linux
this basically means, you replace board/SoC dependent init code
that register some platform_device with a description in DT.

The actual driver does _not_ need to know about non-DT or DT except
that somebody has to parse it and create a platform_device for it.
If you only have standard properties like reg and irq, it all gets
parsed automagically by DT bus probing. But as you already pointed
out, a video card on Dove is a little bit more complex as reg and
irq - so I provided a DT parser for rmk's *RFC* driver as *RFC*!

Sebastian

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 14:23:19 -0400
Rob Clark  wrote:

> > These parameters should not be there. It seems to me that the DT is the
> > right place.  
> 
> You might not want to directly have a hard DT dependency in tda998x,
> as the encoder could be used on non-DT platforms.  Although a DT to
> encoder-params helper might be a nice idea for platforms which do have
> DT.

If I correctly understand:

- Russell does not use any DT, so his drm driver should be declared in
  some cubox-setup code in mach-dove/

- this code should also declare the tda998x

- the drm driver contains/passes parameters to the tda998x

As the connection Dove LCD <-> tda998x is Cubox specific, the question
is: why are'nt the tda998x parameters in the cubox-setup code?

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Jean-Francois Moine

On Sat, 18 May 2013 20:20:00 +0200
Sebastian Hesselbarth  wrote:

> I put nothing to garbage. _You_ also agreed to merge with rmk's driver!
> We can now put in all features we implemented differently
> _step-by-step_.
> 
> Merging the drivers starts with adding support for DT - that is what
> I provided. You know the HW better than me, why don't you start picking
> features from your driver and add them in rmk's driver?

The general hardware code of both drivers is close enough for merging
may be done starting from anyone. But the general layout is not:

- my driver is DT driven and has one card with 2 CTRC's and 2 connectors.

- Russell's is non-DT, so, with some extra code I am not aware of, with
  any number of cards each one with one CRTC and one connector (no, I
  tried it, you cannot clone a connector of one card to the connector
  of another card).

So, for me, merging means enhance my code from Russell's, but I will
not go to a non-DT kernel.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

2013-05-18 Thread Niels Ole Salscheider

Add ULL prefix to avoid overflow.

Signed-off-by: Niels Ole Salscheider 
---
 drivers/gpu/drm/radeon/evergreen.c  | 4 ++--
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 drivers/gpu/drm/radeon/si.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 105bafb..06c261b 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3405,8 +3405,8 @@ int evergreen_mc_init(struct radeon_device *rdev)
rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE);
} else {
/* size in MB on evergreen/cayman/tn */
-   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
-   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
1024ULL;
+   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 
1024ULL;
}
rdev->mc.visible_vram_size = rdev->mc.aper_size;
r700_vram_gtt_location(rdev, &rdev->mc);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 93f760e..6c0ce89 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -726,7 +726,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
return r;
}
DRM_INFO("radeon: %uM of VRAM memory ready\n",
-(unsigned)rdev->mc.real_vram_size / (1024 * 1024));
+(unsigned) (rdev->mc.real_vram_size / (1024 * 1024)));
r = ttm_bo_init_mm(&rdev->mman.bdev, TTM_PL_TT,
rdev->mc.gtt_size >> PAGE_SHIFT);
if (r) {
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index f0b6c2f..113ed9f 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -3397,8 +3397,8 @@ static int si_mc_init(struct radeon_device *rdev)
rdev->mc.aper_base = pci_resource_start(rdev->pdev, 0);
rdev->mc.aper_size = pci_resource_len(rdev->pdev, 0);
/* size in MB on si */
-   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
-   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024 * 1024;
+   rdev->mc.mc_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+   rdev->mc.real_vram_size = RREG32(CONFIG_MEMSIZE) * 1024ULL * 1024ULL;
rdev->mc.visible_vram_size = rdev->mc.aper_size;
si_vram_gtt_location(rdev, &rdev->mc);
radeon_update_bandwidth_info(rdev);
-- 
1.8.2.3

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth

On 05/18/2013 08:58 PM, Jean-Francois Moine wrote:
> On Sat, 18 May 2013 14:23:19 -0400
> Rob Clark  wrote:
>
>>> These parameters should not be there. It seems to me that the DT is the
>>> right place.
>>
>> You might not want to directly have a hard DT dependency in tda998x,
>> as the encoder could be used on non-DT platforms.  Although a DT to
>> encoder-params helper might be a nice idea for platforms which do have
>> DT.
>
> If I correctly understand:
>
> - Russell does not use any DT, so his drm driver should be declared in
>some cubox-setup code in mach-dove/

No. The _device_ is declared in some cubox-setup but the _driver_ goes
into drivers/gpu/drm. Reading vendor provided kernel code may be
misleading as they often just put all stuff in arch/arm/mach-something.

> - this code should also declare the tda998x

The device for tda998x yes, but not the driver. Anyway, Russel decided
to have tda998x probed by his drm_driver.

> - the drm driver contains/passes parameters to the tda998x
>
> As the connection Dove LCD<->  tda998x is Cubox specific, the question
> is: why are'nt the tda998x parameters in the cubox-setup code?

The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
as you can find the very same controller on other Marvell SoCs with
little differences.

So in the end, we will have a DT node for the HW controllers found
in Dove SoCs, a node for TDA998x, and a node for the video card, i.e.
_how_ lcd controllers, external encoders, clocks, maybe audio, ...
are hooked up on that specific board.

There is so much to take care of like pixel format on lcd pins driving
an external encoder (_not_ only tda998x), what gpio pin is connected to
TDA interrupt line, one or two lcds, ...

The corresponding drivers _will_ take care of it .. but in the future.
All I try to make sure is that driver architecture does not prevent us
from e.g. having two lcds plus dcon later on. Or allows to reuse
dove-drm on pxa where only one lcd but no dcon is available.

Sebastian

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Russell King - ARM Linux

On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
> The device for tda998x yes, but not the driver. Anyway, Russel decided
> to have tda998x probed by his drm_driver.

For the simple reason that _that_ is how DRM slave encoders work.
Sometimes, reading the code of the subsystem you're using is well
worth the effort.

If Jean-Francois would like to read drm_encoder_slave.c, then it will
be found that in order to use the TDA998x driver, which is itself a
DRM slave encoder, you must use drm_i2c_encoder_init().  In order to
use that, you must provide the I2C adapter structure, and a board
info structure.

If you don't want to do that, your options are:
(a) you don't use the existing TDA998x DRM slave encoder, and instead
write your own TDA998x driver, which will likely be justifyable
rejected, or
(b) you propose a new DRM interface to allow DRM components to be
registered independently, without reference to a core drm_device
structure.

> The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
> also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
> as you can find the very same controller on other Marvell SoCs with
> little differences.

Well, to spoil the argument a little, actually, the interconnection
between the two is in no way "standardized".  There's many different
ways to wire the two chips together and have it work - because the
TDA998x chips have a set of input muxes and swaps which allow you to
connect the red, green, blue high/low nibbles in various ways and
still have a correctly working system.  The TDA998x connectivity is
_highly_ configuable.

So, just because one board connects LCD_D0 (red bit 0) to a particular
pin on the TDA998x does not mean that another board does it that way
too.

So Jean-Francois is quite correct that this data needs to be provided
by the board in some manner.  The question is - how to do that sensibly.

One possible stop-gap solution is to provide a default set which just
happens to match the cubox, and allow OF to override it. :)

> There is so much to take care of like pixel format on lcd pins driving
> an external encoder (_not_ only tda998x), what gpio pin is connected to
> TDA interrupt line, one or two lcds, ...

Luckily, drivers/gpu/drm/i2c/tda998x.c does not make use of the IRQ
signal at present - it's fairly basic and it currently operates by
polling.  Eventually, this could change of course. :)

I think people need to keep a sense of perspective here: this is all
entirely "new" stuff which is still being actively developed.  It is
not fully polished.  We've not had a true open source TDA998x driver
before 3.9 (that's when it was introduced.)  It has teething problems
at the moment, but I'm working with the authors to resolve these issues.
I'm also still working on the DRM driver.

For example, I've been playing with the RGB888 cursor support today,
which seems to be suffering from a one pixel error in the hotspot
location.  I've not got to the bottom of it, but that kind of error
_is_ important to understand and resolve, because it means that
things like drawing programmes become unusable.

What I'm starting to suspect is a bug in the X server causing this
and not either my DRM driver or Xorg driver.

[RFC 3/4] DRM: add OF support for Dove DRM driver

2013-05-18 Thread Russell King - ARM Linux

On Sat, May 18, 2013 at 07:45:02PM +0200, Jean-Francois Moine wrote:
> It seems we are moving backwards:
> - what about the display controller?
> - how do you clone the lcd 0 output to the port B?
> - what occurs when the si5351 and the tda998x are modules?

I've no idea why you keep bringing that last point up.  I've already
told you what happens when the SI5351 is a module.  It is already not
a problem as I have already evidenced by my boot log.  So please get
that and stop repeating this same point which I've already answered,
or I will start ranting at you and we will have a massive falling out.

As for cloning output to the VGA port, that's just a matter of dealing
with the display controller.  That's _not_ difficult.

> My driver had the same layout as Russell's when I proposed it to you
> and when you insisted to handle the 2 LCDs and the 2 ports as one card.

This seems to be a misrepresentation.  So what you're saying is that
your driver originally handled the two LCDs as two separate cards.

That is _not_ the same as my driver.  My driver handles the two LCDs
as two separate CRTs of the same DRM device.  This allows X to drive
the two CRTs together in any manner it desires depending on the
capabilities of the "connectors" associated with each CRTC and the
user preferences.

> I spent 2 months to have a nice design and you put it to garbage!
> I am not happy...

Stop that right now.  If you want to start whinging about the amount of
time you've spent on this, then I can tell you now that if you have only
spent two months on this, you are a total newbie to this and your effort
is utterly insignificant compared to mine.  And you *have* touched a
nerve here by making that statement.

[RFC 4/4] DRM: tda998x: add missing include

2013-05-18 Thread Sebastian Hesselbarth

On 05/18/2013 10:26 PM, Russell King - ARM Linux wrote:
> On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
>> The device for tda998x yes, but not the driver. Anyway, Russel decided
>> to have tda998x probed by his drm_driver.
>
> For the simple reason that _that_ is how DRM slave encoders work.
> Sometimes, reading the code of the subsystem you're using is well
> worth the effort.

I agree and add that the probing itself doesn't prevent you from using
DT for tda driver at all. You can still have an marvell,external-slave
property pointing to the phandle of tda node. With that you get the
adapter and i2c slave address for what is currently called
dove_tda19989.c and may become e.g. dove_ext_i2c.c. In tda998x_drv you
find the node and get all properties for input config or interrupt
gpio.

I have done that in the drivers before, but DT node parsing here is
_added_ to the driver as it can be used on other non-DT platforms as
well.

>> The connection of Dove LCD and tda998x is _not_ Cubox specific, it is
>> also on the D2Plug. To be precise, even "Dove LCD" is not Dove specific
>> as you can find the very same controller on other Marvell SoCs with
>> little differences.
>
> Well, to spoil the argument a little, actually, the interconnection
> between the two is in no way "standardized".  There's many different
> ways to wire the two chips together and have it work - because the
> TDA998x chips have a set of input muxes and swaps which allow you to
> connect the red, green, blue high/low nibbles in various ways and
> still have a correctly working system.  The TDA998x connectivity is
> _highly_ configuable.
>
> So, just because one board connects LCD_D0 (red bit 0) to a particular
> pin on the TDA998x does not mean that another board does it that way
> too.
>
> So Jean-Francois is quite correct that this data needs to be provided
> by the board in some manner.  The question is - how to do that sensibly.
>
> One possible stop-gap solution is to provide a default set which just
> happens to match the cubox, and allow OF to override it. :)

While I agree, Rob may have a different view on that for tda998x ;)

>> There is so much to take care of like pixel format on lcd pins driving
>> an external encoder (_not_ only tda998x), what gpio pin is connected to
>> TDA interrupt line, one or two lcds, ...
>
> Luckily, drivers/gpu/drm/i2c/tda998x.c does not make use of the IRQ
> signal at present - it's fairly basic and it currently operates by
> polling.  Eventually, this could change of course. :)

Again, that is in the driver Jean-Francois has available. Make sure irq
handler runs in a separate thread from get_edid and hpd and you will
be interrupted on hpd. Having said, that should finally lead to the
slave encoder setting .connector_type and .polled as this is where you
know it.

Sebastian

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #33 from Tom Stellard  ---
(In reply to comment #32)
> Created attachment 79504 [details]
> Results of OpenCL test
> 
> BREAKTHROUGH!
> 
> OpenCL works. Kinda. Tried the following kernel:
> __kernel void add(__global const uint *a,  __global const uint *b, __global
> uint *c){
> c[0]=1;
> }
> Complicated operations such as addition, memory loads, getting global ID,
> etc. fail with Cannot select errors.
> I have no idea if this has worked with earlier LLVM/mesa.
> 

All that is supported in the git tree is stores to global memory.  I have
global loads, work item functions, and a fair amount of arithmetic operations
working in a local branch, and I hope to get that pushed to mainline in the
next week or two.

> After the kernel is run, the 0-th element of c is equal to 1. I've attached
> full source code and outputs for various kernels.

-- 
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/20130518/edf36e84/attachment.html>

[Bug 64257] RS880 issues with r600-llvm-compiler

2013-05-18 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #11 from Tom Stellard  ---
(In reply to comment #10)
> I've now recompiled everything from upstream - kwin now renders however it
> has a pinkish hugh to the bottom right - this didn't happen when I tested
> the patches separately

It's possible that the recent scheduling changes have caused an unrelated
regression.  Does kwin render correctly if you use the LLVM 3.3 branch?

-- 
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/20130518/cc9d71f0/attachment.html>

72 matches

Mail list logo