[PATCH] dma-buf: add vmap interface (v3)

[Dave Airlie]

From: Dave Airlie 

The main requirement I have for this interface is for scanning out
using the USB gpu devices. Since these devices have to read the
framebuffer on updates and linearly compress it, using kmaps
is a major overhead for every update.

v2: fix warn issues pointed out by Sylwester Nawrocki.

v3: fix compile !CONFIG_DMA_SHARED_BUFFER and add _GPL for now

Signed-off-by: Dave Airlie 
---
 drivers/base/dma-buf.c  |   34 ++
 include/linux/dma-buf.h |   14 ++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 07cbbc6..0d8197e 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap);
+
+/**
+ * dma_buf_vmap - Create virtual mapping for the buffer object into kernel 
address space. The same restrictions as for vmap and friends apply.
+ * @dma_buf:   [in]buffer to vmap
+ *
+ * This call may fail due to lack of virtual mapping address space.
+ * These calls are optional in drivers. The intended use for them
+ * is for mapping objects linear in kernel space for high use objects.
+ * Please attempt to use kmap/kunmap before thinking about these interfaces.
+ */
+void *dma_buf_vmap(struct dma_buf *dmabuf)
+{
+   if (WARN_ON(!dmabuf))
+   return NULL;
+
+   if (dmabuf->ops->vmap)
+   return dmabuf->ops->vmap(dmabuf);
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_buf_vmap);
+
+/**
+ * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
+ * @dma_buf:   [in]buffer to vmap
+ */
+void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+{
+   if (WARN_ON(!dmabuf))
+   return;
+
+   if (dmabuf->ops->vunmap)
+   dmabuf->ops->vunmap(dmabuf, vaddr);
+}
+EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 3efbfc2..d8c2865 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -92,6 +92,9 @@ struct dma_buf_ops {
void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *);
void *(*kmap)(struct dma_buf *, unsigned long);
void (*kunmap)(struct dma_buf *, unsigned long, void *);
+
+   void *(*vmap)(struct dma_buf *);
+   void (*vunmap)(struct dma_buf *, void *vaddr);
 };

 /**
@@ -167,6 +170,9 @@ void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long);
 void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *);
 void *dma_buf_kmap(struct dma_buf *, unsigned long);
 void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
+
+void *dma_buf_vmap(struct dma_buf *);
+void dma_buf_vunmap(struct dma_buf *, void *vaddr);
 #else

 static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
@@ -248,6 +254,14 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
  unsigned long pnum, void *vaddr)
 {
 }
+
+static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
+{
+}
+
+static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+{
+}
 #endif /* CONFIG_DMA_SHARED_BUFFER */

 #endif /* __DMA_BUF_H__ */
-- 
1.7.6

linux-next: Tree for May 18 (drm drivers and vgacon)

[Randy Dunlap]

On 05/18/2012 01:49 AM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 201205017:


When CONFIG_VGA_CONSOLE is not enabled:

drivers/gpu/drm/cirrus/cirrus_drv.c:87:2: error: implicit declaration of 
function 'vgacon_text_force'
drivers/gpu/drm/ast/ast_drv.c:224:2: error: implicit declaration of function 
'vgacon_text_force'
drivers/gpu/drm/mgag200/mgag200_drv.c:96:2: error: implicit declaration of 
function 'vgacon_text_force'


-- 
~Randy

[PATCH 2/2] pcm038 lcdc support

[Sascha Hauer]

On Fri, May 18, 2012 at 10:03:54AM -0400, Adam Jackson wrote:
> On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:
> 
> > +   edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
> > +   0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
> > +   11 50 54
> > +
> > +   /* est timings */
> > +   00 00 00
> > +
> > +   /* std timings */
> > +   00 00
> > +   00 00
> > +   00 00
> > +   00 00
> > +   00 00
> > +   00 00
> > +   00 00
> > +   00 00
> > +
> > +   /* detailed timings */
> > +   05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 
> > 00 1E
> > +   00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 
> > 20 20
> > +   00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 
> > 20 20
> > +   00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 
> > 20 20
> > +   00 20];
> 
> This EDID block claims to be a Samsung SyncMaster, which isn't really
> the right thing to do.  The question is what to call it instead.  Red
> Hat has a PNP ID we can use for virtual EDID blocks like this if we
> want, I'd want to set up a little database to keep track of them but
> that's pretty trivial.

Sorry, should have mentioned this in the commit log. This in fact is a
hacked version of my office monitor. This patch is more meant as a usage
example and not for upstream. I don't know yet if it's even acceptable
to put edid data into the devicetree. I saw some discussion about it,
but also about some generic display description, which I would prefer.

BTW is there a more convenient tool than a hex editor around to generate
edid data? I only found some windows tools

> 
> Also, empty standard timing fields are 01 01, not 00 00.

Good to know

Thanks
 Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

dce crtc mem req and atombios

[Sylvain BERTRAND]

Hi,

On radeon hardware (I have an evergreen based board):

Must stopping/resuming the DCE to access the memory controller be done
with the EnableCRTCMemReq atombios table? (from DCE3 in dpm code).

Because, in evergreen.c, evergreen_mc_stop and evergreen_mc_resume
functions do not make use of that table (register direct access).

regards,

-- 
Sylvain

[PATCH] nouveau: nouveau_set_bo_placement takes TTM flags

[Dave Airlie]

From: Dave Airlie 

This seems to be wrong to me, spotted while thinking about dma-buf.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7d15a77..12ce044 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1030,7 +1030,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object 
*bo)

nvbo->placement.fpfn = 0;
nvbo->placement.lpfn = dev_priv->fb_mappable_pages;
-   nouveau_bo_placement_set(nvbo, TTM_PL_VRAM, 0);
+   nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_VRAM, 0);
return nouveau_bo_validate(nvbo, false, true, false);
 }

-- 
1.7.7.6

[PATCH 2/2] pcm038 lcdc support

[Sascha Hauer]

Signed-off-by: Sascha Hauer 
---
 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 3 files changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dts 
b/arch/arm/boot/dts/imx27-phytec-phycore.dts
index a51a08f..bdb7547 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore.dts
@@ -20,6 +20,41 @@
reg = <0x0 0x0>;
};

+   baseboard {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+#size-cells = <1>;
+
+   display {
+   compatible = "fsl,imx-parallel-display";
+   edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
+   0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
+   11 50 54
+
+   /* est timings */
+   00 00 00
+
+   /* std timings */
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+
+   /* detailed timings */
+   05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 
00 1E
+   00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 
20 20
+   00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 
20 20
+   00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 
20 20
+   00 20];
+
+   crtc = < 0>;
+   };
+   };
+
soc {
aipi at 1000 { /* aipi */

@@ -46,6 +81,10 @@
status = "okay";
};

+   lcdc at 10021000 {
+   status = "okay";
+   };
+
i2c at 1001d000 {
clock-frequency = <40>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index bc5e7d5..eab9095 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -206,6 +206,13 @@
status = "disabled";
};

+   lcdc: lcdc at 10021000 {
+   compatible = "fsl,imx27-lcdc", "fsl,imx21-lcdc";
+   reg = <0x10021000 0x4000>;
+   interrupts = <61>;
+   status = "enabled";
+   };
+
fec: fec at 1002b000 {
compatible = "fsl,imx27-fec";
reg = <0x1002b000 0x4000>;
diff --git a/arch/arm/mach-imx/clock-imx27.c b/arch/arm/mach-imx/clock-imx27.c
index 98e04f5..a393483 100644
--- a/arch/arm/mach-imx/clock-imx27.c
+++ b/arch/arm/mach-imx/clock-imx27.c
@@ -646,6 +646,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK("imx27-cspi.1", NULL, cspi2_clk)
_REGISTER_CLOCK("imx27-cspi.2", NULL, cspi3_clk)
_REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk)
+   _REGISTER_CLOCK("10021000.lcdc", NULL, lcdc_clk)
_REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk1)
-- 
1.7.10

[Bug 49943] radeon/drm: Hotplug udev events stop working

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

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

--- Comment #2 from Harald Judt  2012-05-18 06:45:13 PDT ---
BTW: Connecting HDMI again shows the following values:
HDMI connected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff0ff012 (-15732718)

HDMI disconnected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff0ff000 (-15732736)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49943] radeon/drm: Hotplug udev events stop working

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

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

--- Comment #1 from Harald Judt  2012-05-18 06:35:44 PDT ---
Ok, I've run radeonreg, here is the output:

Before HDMI connected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0x (0)

HDMI connected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff12 (-16777198)

HDMI disconnected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff0ff000 (-15732736)

The value of reg 0x6058 changes (HDMI-0). As you can see, after HDMI has been
disconnected, it is different from the original value (0). I suspect that there
is some problem with this?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

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

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

--- Comment #1 from C?dric Legrand  2012-05-18 
06:16:00 PDT ---
Same here : creating 2 SFML canvas in a wxWidgets application results in the
same problem. Each canvas shows when alone, but the second does not when
together. It seems not to refresh, as it sometimes shows other parts of the
application in the canvas (title, the other canvas, menus...).
In Windows 7, the same code works well.

* Application output : lots of :
radeon: The kernel rejected CS, see dmesg for more information.

* dmesg output : lots of :
radeon :01:00.0: texture bo too small (384 480 26 0 -> 737280 have 4096)
radeon :01:00.0: alignments 384 1 1 1
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

* uname -a :
Linux perfection 3.3.5-gentoo #1 SMP Wed May 16 19:54:18 CEST 2012 x86_64
Intel(R) Core(TM)2 Duo CPU T6500 @ 2.10GHz GenuineIntel GNU/Linux

* glxinfo | grep OpenGL :
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV710
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20
OpenGL extensions:

* latest libdrm in testing portage tree (2.4.33)

* SFML-2.0rc

 I'm sorry for my english 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm_edid: support CEA video modes

[Andy Furniss]

Joakim Plate wrote:
> Joakim Plate  writes:
>
>>
>> Christian Schmidt  writes:
>>
>>>
>>> TFT/plasma televisions and projectors have become commonplace, and so
>>> has the use of PCs to drive them. Add the video modes specified by an
>>> EDID's CEA extension to the mode database for a connector.
>>
>> /Joakim
>>
>
> Shameless bump on the subject. Would be nice if we could
> get this list complete when connecting to HDTV's.

Yea, it would be nice.

UK bluray seems to use 24/1.001 - not that it's that bad watching with 
TV at 24Hz.

I do have issues with interlaced modes on my TV. I don't know how DRM 
handles interlaced, but CEA says that the number of vblank lines 
alternates per field. If that isn't happening then I guess that's why.

[PATCH] drm_edid: support CEA video modes

[Joakim Plate]

Joakim Plate  ecce.se> writes:

> 
> Christian Schmidt  digadd.de> writes:
> 
> > 
> > TFT/plasma televisions and projectors have become commonplace, and so
> > has the use of PCs to drive them. Add the video modes specified by an
> > EDID's CEA extension to the mode database for a connector.
> 
> /Joakim
> 

Shameless bump on the subject. Would be nice if we could
get this list complete when connecting to HDTV's.

[PATCH 2/2] pcm038 lcdc support

[Adam Jackson]

On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:

> + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
> + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
> + 11 50 54
> +
> + /* est timings */
> + 00 00 00
> +
> + /* std timings */
> + 00 00
> + 00 00
> + 00 00
> + 00 00
> + 00 00
> + 00 00
> + 00 00
> + 00 00
> +
> + /* detailed timings */
> + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 
> 00 1E
> + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 
> 20 20
> + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 
> 20 20
> + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 
> 20 20
> + 00 20];

This EDID block claims to be a Samsung SyncMaster, which isn't really
the right thing to do.  The question is what to call it instead.  Red
Hat has a PNP ID we can use for virtual EDID blocks like this if we
want, I'd want to set up a little database to keep track of them but
that's pretty trivial.

Also, empty standard timing fields are 01 01, not 00 00.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120518/70b0e903/attachment.pgp>

[PATCH] dma-buf: mmap support

[Sumit Semwal]

Hi Daniel, Rob,

On 11 May 2012 21:00, Rob Clark  wrote:
> On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter  
> wrote:
>> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks

>>
>> Cc: Rob Clark 
>> Cc: Rebecca Schultz Zavin 
>> Signed-Off-by: Daniel Vetter 
>
> Acked-by: Rob Clark 
Thanks, applied to my for-next.
Sorry, I was away due to some medical reasons for some time, hence the delay.
>

Best regards,
~Sumit.

[Linaro-mm-sig] [PATCH] dma-buf: add vmap interface (v2)

[Sumit Semwal]

Hi Dave,

On 17 May 2012 16:01, Dave Airlie  wrote:
> From: Dave Airlie 
>
> The main requirement I have for this interface is for scanning out
> using the USB gpu devices. Since these devices have to read the
> framebuffer on updates and linearly compress it, using kmaps
> is a major overhead for every update.
>
> v2: fix warn issues pointed out by Sylwester Nawrocki.
>
> Signed-off-by: Dave Airlie 
> ---
> ?drivers/base/dma-buf.c ?| ? 34 ++
> ?include/linux/dma-buf.h | ? 14 ++
> ?2 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 07cbbc6..750f92c 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned 
> long page_num,
> ? ? ? ? ? ? ? ?dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> ?}
> ?EXPORT_SYMBOL_GPL(dma_buf_kunmap);
> +
> +/**
> + * dma_buf_vmap - Create virtual mapping for the buffer object into kernel 
> address space. The same restrictions as for vmap and friends apply.
> + * @dma_buf: ? [in] ? ?buffer to vmap
> + *
> + * This call may fail due to lack of virtual mapping address space.
> + * These calls are optional in drivers. The intended use for them
> + * is for mapping objects linear in kernel space for high use objects.
> + * Please attempt to use kmap/kunmap before thinking about these interfaces.
> + */
> +void *dma_buf_vmap(struct dma_buf *dmabuf)
> +{
> + ? ? ? if (WARN_ON(!dmabuf))
> + ? ? ? ? ? ? ? return NULL;
> +
> + ? ? ? if (dmabuf->ops->vmap)
> + ? ? ? ? ? ? ? return dmabuf->ops->vmap(dmabuf);
> + ? ? ? return NULL;
> +}
> +EXPORT_SYMBOL(dma_buf_vmap);
I am afraid we don't yet have a clear consensus on the usage of
EXPORT_SYMBOL - till it is done, I would prefer that we use
EXPORT_SYMBOL_GPL for consistency. Once we reach agreement, we can
change them all in one go if required.
> +

-- 
Thanks and regards,
~Sumit.

PCI resources above 4GB

[Yinghai Lu]

On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu  wrote:
> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu  wrote:
>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury  
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Strange, the busn branch is merged with for-pci-res-alloc, but for
>>> some reason it isn't working. ?Only the bridge is detected, not the
>>> devices behind it.
>>
>> Can you post the boot log ? maybe recently reordering patches applying
>> sequence break it.
>
> Never mind, found the problem.

updated for-pci-res-alloc branch. please check it.

Thanks

Yinghai

PCI resources above 4GB

[Yinghai Lu]

On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu  wrote:
> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Strange, the busn branch is merged with for-pci-res-alloc, but for
>> some reason it isn't working. ?Only the bridge is detected, not the
>> devices behind it.
>
> Can you post the boot log ? maybe recently reordering patches applying
> sequence break it.

Never mind, found the problem.

will check if i could fix it tomorrow.

Yinghai

Re: PCI resources above 4GB

[Yinghai Lu]

On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Strange, the busn branch is merged with for-pci-res-alloc, but for
 some reason it isn't working.  Only the bridge is detected, not the
 devices behind it.

 Can you post the boot log ? maybe recently reordering patches applying
 sequence break it.

Never mind, found the problem.

will check if i could fix it tomorrow.

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

Re: PCI resources above 4GB

[Yinghai Lu]

On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk 
 wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Strange, the busn branch is merged with for-pci-res-alloc, but for
 some reason it isn't working.  Only the bridge is detected, not the
 devices behind it.

 Can you post the boot log ? maybe recently reordering patches applying
 sequence break it.

 Never mind, found the problem.

updated for-pci-res-alloc branch. please check it.

Thanks

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

Re: [PATCH] drm_edid: support CEA video modes

[Joakim Plate]

Joakim Plate elupus at ecce.se writes:

 
 Christian Schmidt schmidt at digadd.de writes:
 
  
  TFT/plasma televisions and projectors have become commonplace, and so
  has the use of PCs to drive them. Add the video modes specified by an
  EDID's CEA extension to the mode database for a connector.
 
 /Joakim
 

Shameless bump on the subject. Would be nice if we could
get this list complete when connecting to HDTV's.




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

Re: [PATCH] drm_edid: support CEA video modes

[Andy Furniss]

Joakim Plate wrote:

Joakim Plateelupusat  ecce.se  writes:



Christian Schmidtschmidtat  digadd.de  writes:



TFT/plasma televisions and projectors have become commonplace, and so
has the use of PCs to drive them. Add the video modes specified by an
EDID's CEA extension to the mode database for a connector.


/Joakim



Shameless bump on the subject. Would be nice if we could
get this list complete when connecting to HDTV's.


Yea, it would be nice.

UK bluray seems to use 24/1.001 - not that it's that bad watching with 
TV@24Hz.


I do have issues with interlaced modes on my TV. I don't know how DRM 
handles interlaced, but CEA says that the number of vblank lines 
alternates per field. If that isn't happening then I guess that's why.


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

[no subject]

[Sascha Hauer]

Hi All,

The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.

Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.

Comments very welcome.

Thanks
 Sascha


Sascha Hauer (2):
  DRM: add Freescale i.MX LCDC driver
  pcm038 lcdc support

 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/imx/Kconfig|   18 +
 drivers/gpu/drm/imx/Makefile   |8 +
 drivers/gpu/drm/imx/imx-drm-core.c |  745 
 drivers/gpu/drm/imx/imx-fb.c   |  179 +++
 drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
 drivers/gpu/drm/imx/imx-gem.c  |  343 +
 drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
 drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
 13 files changed, 2363 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/Kconfig
 create mode 100644 drivers/gpu/drm/imx/Makefile
 create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
 create mode 100644 drivers/gpu/drm/imx/imx-fb.c
 create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
 create mode 100644 drivers/gpu/drm/imx/imx-gem.c
 create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
 create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] pcm038 lcdc support

[Sascha Hauer]

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 3 files changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/imx27-phytec-phycore.dts 
b/arch/arm/boot/dts/imx27-phytec-phycore.dts
index a51a08f..bdb7547 100644
--- a/arch/arm/boot/dts/imx27-phytec-phycore.dts
+++ b/arch/arm/boot/dts/imx27-phytec-phycore.dts
@@ -20,6 +20,41 @@
reg = 0x0 0x0;
};
 
+   baseboard {
+   compatible = simple-bus;
+   #address-cells = 2;
+#size-cells = 1;
+
+   display {
+   compatible = fsl,imx-parallel-display;
+   edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
+   0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
+   11 50 54
+
+   /* est timings */
+   00 00 00
+
+   /* std timings */
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+   00 00
+
+   /* detailed timings */
+   05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 
00 1E
+   00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 
20 20
+   00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 
20 20
+   00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 
20 20
+   00 20];
+
+   crtc = lcdc 0;
+   };
+   };
+
soc {
aipi@1000 { /* aipi */
 
@@ -46,6 +81,10 @@
status = okay;
};
 
+   lcdc@10021000 {
+   status = okay;
+   };
+
i2c@1001d000 {
clock-frequency = 40;
status = okay;
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index bc5e7d5..eab9095 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -206,6 +206,13 @@
status = disabled;
};
 
+   lcdc: lcdc@10021000 {
+   compatible = fsl,imx27-lcdc, fsl,imx21-lcdc;
+   reg = 0x10021000 0x4000;
+   interrupts = 61;
+   status = enabled;
+   };
+
fec: fec@1002b000 {
compatible = fsl,imx27-fec;
reg = 0x1002b000 0x4000;
diff --git a/arch/arm/mach-imx/clock-imx27.c b/arch/arm/mach-imx/clock-imx27.c
index 98e04f5..a393483 100644
--- a/arch/arm/mach-imx/clock-imx27.c
+++ b/arch/arm/mach-imx/clock-imx27.c
@@ -646,6 +646,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK(imx27-cspi.1, NULL, cspi2_clk)
_REGISTER_CLOCK(imx27-cspi.2, NULL, cspi3_clk)
_REGISTER_CLOCK(imx-fb.0, NULL, lcdc_clk)
+   _REGISTER_CLOCK(10021000.lcdc, NULL, lcdc_clk)
_REGISTER_CLOCK(mx2-camera.0, NULL, csi_clk)
_REGISTER_CLOCK(fsl-usb2-udc, usb, usb_clk)
_REGISTER_CLOCK(fsl-usb2-udc, usb_ahb, usb_clk1)
-- 
1.7.10

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

[Bug 49817] radeon: The kernel rejected CS when running shader example from SFML library

[bugzilla-daemon]

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

--- Comment #1 from Cédric Legrand legrand.cedric...@gmail.com 2012-05-18 
06:16:00 PDT ---
Same here : creating 2 SFML canvas in a wxWidgets application results in the
same problem. Each canvas shows when alone, but the second does not when
together. It seems not to refresh, as it sometimes shows other parts of the
application in the canvas (title, the other canvas, menus...).
In Windows 7, the same code works well.

* Application output : lots of :
radeon: The kernel rejected CS, see dmesg for more information.

* dmesg output : lots of :
radeon :01:00.0: texture bo too small (384 480 26 0 - 737280 have 4096)
radeon :01:00.0: alignments 384 1 1 1
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

* uname -a :
Linux perfection 3.3.5-gentoo #1 SMP Wed May 16 19:54:18 CEST 2012 x86_64
Intel(R) Core(TM)2 Duo CPU T6500 @ 2.10GHz GenuineIntel GNU/Linux

* glxinfo | grep OpenGL :
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV710
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20
OpenGL extensions:

* latest libdrm in testing portage tree (2.4.33)

* SFML-2.0rc

 I'm sorry for my english 

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49943] radeon/drm: Hotplug udev events stop working

[bugzilla-daemon]

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

--- Comment #1 from Harald Judt h.j...@gmx.at 2012-05-18 06:35:44 PDT ---
Ok, I've run radeonreg, here is the output:

Before HDMI connected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0x (0)

HDMI connected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff12 (-16777198)

HDMI disconnected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff0ff000 (-15732736)

The value of reg 0x6058 changes (HDMI-0). As you can see, after HDMI has been
disconnected, it is different from the original value (0). I suspect that there
is some problem with this?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 49943] radeon/drm: Hotplug udev events stop working

[bugzilla-daemon]

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

--- Comment #2 from Harald Judt h.j...@gmx.at 2012-05-18 06:45:13 PDT ---
BTW: Connecting HDMI again shows the following values:
HDMI connected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff0ff012 (-15732718)

HDMI disconnected:
0x601c  0x (0)
0x6028  0x0612 (100663314)
0x6034  0x0012 (18)
0x6040  0x (0)
0x604c  0x (0)
0x6058  0xff0ff000 (-15732736)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] pcm038 lcdc support

[Adam Jackson]

On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:

 + edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
 + 0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
 + 11 50 54
 +
 + /* est timings */
 + 00 00 00
 +
 + /* std timings */
 + 00 00
 + 00 00
 + 00 00
 + 00 00
 + 00 00
 + 00 00
 + 00 00
 + 00 00
 +
 + /* detailed timings */
 + 05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 
 00 1E
 + 00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 
 20 20
 + 00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 
 20 20
 + 00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 
 20 20
 + 00 20];

This EDID block claims to be a Samsung SyncMaster, which isn't really
the right thing to do.  The question is what to call it instead.  Red
Hat has a PNP ID we can use for virtual EDID blocks like this if we
want, I'd want to set up a little database to keep track of them but
that's pretty trivial.

Also, empty standard timing fields are 01 01, not 00 00.

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: nouveau_set_bo_placement takes TTM flags

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

This seems to be wrong to me, spotted while thinking about dma-buf.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7d15a77..12ce044 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1030,7 +1030,7 @@ nouveau_ttm_fault_reserve_notify(struct ttm_buffer_object 
*bo)
 
nvbo-placement.fpfn = 0;
nvbo-placement.lpfn = dev_priv-fb_mappable_pages;
-   nouveau_bo_placement_set(nvbo, TTM_PL_VRAM, 0);
+   nouveau_bo_placement_set(nvbo, TTM_PL_FLAG_VRAM, 0);
return nouveau_bo_validate(nvbo, false, true, false);
 }
 
-- 
1.7.7.6

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

Re: [PATCH 2/2] pcm038 lcdc support

[Sascha Hauer]

On Fri, May 18, 2012 at 10:03:54AM -0400, Adam Jackson wrote:
 On Fri, 2012-05-18 at 14:27 +0200, Sascha Hauer wrote:
 
  +   edid = [00 ff ff ff ff ff ff 00 4c 2d 6c 03 36 32 49 4b
  +   0f 13 01 03 80 37 22 a0 2a fe 21 a8 53 37 ae 24
  +   11 50 54
  +
  +   /* est timings */
  +   00 00 00
  +
  +   /* std timings */
  +   00 00
  +   00 00
  +   00 00
  +   00 00
  +   00 00
  +   00 00
  +   00 00
  +   00 00
  +
  +   /* detailed timings */
  +   05 0D 20 A0 30 58 1C 20 28 20 14 00 26 57 21 00 
  00 1E
  +   00 00 00 fd 00 32 4b 1b 51 11 00 0a 20 20 20 20 
  20 20
  +   00 00 00 fc 00 53 79 6e 63 4d 61 73 74 65 72 0a 
  20 20
  +   00 00 00 ff 00 48 39 58 53 34 30 30 34 34 32 0a 
  20 20
  +   00 20];
 
 This EDID block claims to be a Samsung SyncMaster, which isn't really
 the right thing to do.  The question is what to call it instead.  Red
 Hat has a PNP ID we can use for virtual EDID blocks like this if we
 want, I'd want to set up a little database to keep track of them but
 that's pretty trivial.

Sorry, should have mentioned this in the commit log. This in fact is a
hacked version of my office monitor. This patch is more meant as a usage
example and not for upstream. I don't know yet if it's even acceptable
to put edid data into the devicetree. I saw some discussion about it,
but also about some generic display description, which I would prefer.

BTW is there a more convenient tool than a hex editor around to generate
edid data? I only found some windows tools

 
 Also, empty standard timing fields are 01 01, not 00 00.

Good to know

Thanks
 Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

dce crtc mem req and atombios

[Sylvain BERTRAND]

Hi,

On radeon hardware (I have an evergreen based board):

Must stopping/resuming the DCE to access the memory controller be done
with the EnableCRTCMemReq atombios table? (from DCE3 in dpm code).

Because, in evergreen.c, evergreen_mc_stop and evergreen_mc_resume
functions do not make use of that table (register direct access).

regards,

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

[PATCH] dma-buf: add vmap interface (v3)

[Dave Airlie]

From: Dave Airlie airl...@redhat.com

The main requirement I have for this interface is for scanning out
using the USB gpu devices. Since these devices have to read the
framebuffer on updates and linearly compress it, using kmaps
is a major overhead for every update.

v2: fix warn issues pointed out by Sylwester Nawrocki.

v3: fix compile !CONFIG_DMA_SHARED_BUFFER and add _GPL for now

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/base/dma-buf.c  |   34 ++
 include/linux/dma-buf.h |   14 ++
 2 files changed, 48 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 07cbbc6..0d8197e 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -406,3 +406,37 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
dmabuf-ops-kunmap(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap);
+
+/**
+ * dma_buf_vmap - Create virtual mapping for the buffer object into kernel 
address space. The same restrictions as for vmap and friends apply.
+ * @dma_buf:   [in]buffer to vmap
+ *
+ * This call may fail due to lack of virtual mapping address space.
+ * These calls are optional in drivers. The intended use for them
+ * is for mapping objects linear in kernel space for high use objects.
+ * Please attempt to use kmap/kunmap before thinking about these interfaces.
+ */
+void *dma_buf_vmap(struct dma_buf *dmabuf)
+{
+   if (WARN_ON(!dmabuf))
+   return NULL;
+
+   if (dmabuf-ops-vmap)
+   return dmabuf-ops-vmap(dmabuf);
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_buf_vmap);
+
+/**
+ * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap.
+ * @dma_buf:   [in]buffer to vmap
+ */
+void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+{
+   if (WARN_ON(!dmabuf))
+   return;
+
+   if (dmabuf-ops-vunmap)
+   dmabuf-ops-vunmap(dmabuf, vaddr);
+}
+EXPORT_SYMBOL_GPL(dma_buf_vunmap);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 3efbfc2..d8c2865 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -92,6 +92,9 @@ struct dma_buf_ops {
void (*kunmap_atomic)(struct dma_buf *, unsigned long, void *);
void *(*kmap)(struct dma_buf *, unsigned long);
void (*kunmap)(struct dma_buf *, unsigned long, void *);
+
+   void *(*vmap)(struct dma_buf *);
+   void (*vunmap)(struct dma_buf *, void *vaddr);
 };
 
 /**
@@ -167,6 +170,9 @@ void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long);
 void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *);
 void *dma_buf_kmap(struct dma_buf *, unsigned long);
 void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
+
+void *dma_buf_vmap(struct dma_buf *);
+void dma_buf_vunmap(struct dma_buf *, void *vaddr);
 #else
 
 static inline struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
@@ -248,6 +254,14 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf,
  unsigned long pnum, void *vaddr)
 {
 }
+
+static inline void *dma_buf_vmap(struct dma_buf *dmabuf)
+{
+}
+
+static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr)
+{
+}
 #endif /* CONFIG_DMA_SHARED_BUFFER */
 
 #endif /* __DMA_BUF_H__ */
-- 
1.7.6

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

Re: linux-next: Tree for May 18 (drm drivers and vgacon)

[Randy Dunlap]

On 05/18/2012 01:49 AM, Stephen Rothwell wrote:

 Hi all,
 
 Changes since 201205017:


When CONFIG_VGA_CONSOLE is not enabled:

drivers/gpu/drm/cirrus/cirrus_drv.c:87:2: error: implicit declaration of 
function 'vgacon_text_force'
drivers/gpu/drm/ast/ast_drv.c:224:2: error: implicit declaration of function 
'vgacon_text_force'
drivers/gpu/drm/mgag200/mgag200_drv.c:96:2: error: implicit declaration of 
function 'vgacon_text_force'


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