[Bug 46231] Radeon NI: evergreen_resume fails after GPU lockup

2012-09-21 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=46231





--- Comment #3 from ben at b1c1l1.com  2012-09-21 22:46:37 ---
I got a different crash with 3.6-rc6 (includes the patch mentioned in comment
#2).  The system was not functional after these messages:

[143239.080420] radeon :01:00.0: GPU lockup CP stall for more than
1msec
[143239.080431] radeon :01:00.0: GPU lockup (waiting for 0x00a80f65
last fence id 0x00a80f5e)
[143239.579983] radeon :01:00.0: GPU lockup CP stall for more than
10500msec
[143239.579994] radeon :01:00.0: GPU lockup (waiting for
0x00a80f5f)
[143239.580002] radeon :01:00.0: failed to get a new IB (-35)
[143239.580007] [drm:radeon_cs_ib_chunk] *ERROR* Failed to get ib !
[143239.581196] radeon :01:00.0: Saved 887 dwords of commands on ring 0.
[143239.581219] radeon :01:00.0: GPU softreset 
[143239.581226] radeon :01:00.0:   GRBM_STATUS=0xA0003828
[143239.581232] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[143239.581238] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[143239.581244] radeon :01:00.0:   SRBM_STATUS=0x20C0
[143239.581249] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[143239.581256] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x00010002
[143239.581261] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x00020186
[143239.581267] radeon :01:00.0:   R_008680_CP_STAT  = 0x80038647
[143239.581280] radeon :01:00.0:   GRBM_SOFT_RESET=0x7F6B
[143239.581388] radeon :01:00.0:   GRBM_STATUS=0x3828
[143239.581393] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[143239.581399] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[143239.581404] radeon :01:00.0:   SRBM_STATUS=0x20C0
[143239.581410] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[143239.581416] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[143239.581422] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[143239.581428] radeon :01:00.0:   R_008680_CP_STAT  = 0x
[143239.582434] radeon :01:00.0: GPU reset succeeded, trying to resume
[143239.587527] [drm] probing gen 2 caps for device 8086:101 = 2/0
[143239.587530] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[143239.590542] [drm] PCIE GART of 512M enabled (table at 0x0004).
[143239.590743] radeon :01:00.0: WB enabled
[143239.590779] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x880265312c00
[143239.607117] [drm] ring test on 0 succeeded in 3 usecs
[143239.913692] [drm] ib test on ring 0 succeeded in 0 usecs
[143239.914882] radeon :01:00.0: GPU reset succeeded, trying to resume
[143239.920049] [drm] probing gen 2 caps for device 8086:101 = 2/0
[143239.920050] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[143239.923057] [drm] PCIE GART of 512M enabled (table at 0x0004).
[143239.923222] radeon :01:00.0: WB enabled
[143239.923231] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x880265312c00
[143239.939918] [drm] ring test on 0 succeeded in 2 usecs
[143240.178647] [drm] ib test on ring 0 succeeded in 0 usecs
[143251.248812] radeon :01:00.0: GPU lockup CP stall for more than
1msec
[143251.248827] radeon :01:00.0: GPU lockup (waiting for 0x00a80f90
last fence id 0x00a80f7c)
[143251.748424] radeon :01:00.0: GPU lockup CP stall for more than
10500msec
[143251.748434] radeon :01:00.0: GPU lockup (waiting for
0x00a80f7d)
[143251.748443] radeon :01:00.0: failed to get a new IB (-35)
[143251.748447] [drm:radeon_cs_ib_chunk] *ERROR* Failed to get ib !
[143251.749646] radeon :01:00.0: Saved 1495 dwords of commands on ring 0.
[143251.749656] radeon :01:00.0: GPU softreset 
[143251.749662] radeon :01:00.0:   GRBM_STATUS=0xA0003828
[143251.749668] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[143251.749674] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[143251.749680] radeon :01:00.0:   SRBM_STATUS=0x20C0
[143251.749686] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[143251.749692] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x4100
[143251.749698] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x00020182
[143251.749704] radeon :01:00.0:   R_008680_CP_STAT  = 0x80028243
[143251.749716] radeon :01:00.0:   GRBM_SOFT_RESET=0x7F6B
[143251.749824] radeon :01:00.0:   GRBM_STATUS=0x3828
[143251.749830] radeon :01:00.0:   GRBM_STATUS_SE0=0x0007
[143251.749835] radeon :01:00.0:   GRBM_STATUS_SE1=0x0007
[143251.749841] radeon :01:00.0:   SRBM_STATUS=0x20C0
[143251.749847] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[143251.749853] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[143251.749858] radeon :01:00.0:   

[PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+

2012-09-21 Thread Tom Stellard
From: Tom Stellard 

This makes it possible to create a surface for a buffer.
---
 radeon/radeon_surface.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 80b1505..235f4ae 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -686,7 +686,8 @@ static int eg_surface_sanity(struct radeon_surface_manager 
*surf_man,
 unsigned tileb;

 /* check surface dimension */
-if (surf->npix_x > 16384 || surf->npix_y > 16384 || surf->npix_z > 16384) {
+if ((surf->npix_x > 16384  && (surf->npix_y != 1 || surf->npix_z != 1)) ||
+surf->npix_y > 16384 || surf->npix_z > 16384) {
 return -EINVAL;
 }

-- 
1.7.11.4



[PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Leela Krishna Amudala
This patch adds device tree based discovery support for exynos DRM-FIMD
driver which includes driver modification to handle platform data in
both the cases with DT and non-DT, Also adds the documentation for bindings.

Signed-off-by: Leela Krishna Amudala 
---
 .../devicetree/bindings/drm/exynos/fimd.txt|   80 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   95 +++-
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/exynos/fimd.txt

diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
new file mode 100644
index 000..e94120c
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be "samsung,exynos5-fimd" or "samsung,exynos4-fimd" for
+   fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+   mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+   specified in the following order.
+   - VSYNC interrupt
+   - FIFO level interrupt
+   - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+   display device node which holds the video interface timing with the
+   below mentioned properties.
+
+   - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+   - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd 
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+   The following is an example for the fimd controller is split into
+   two portions. The SoC specific portion can be specified in the SoC
+   specific dts file. The board specific portion can be specified in the
+   board specific dts file.
+
+   - SoC Specific portion
+
+   fimd {
+   compatible = "samsung,exynos5-fimd";
+   interrupt-parent = <>;
+   reg = <0x1440 0x4>;
+   interrupts = <18 5>, <18 4>, <18 6>;
+   };
+
+   - Board Specific portion
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = <4 4 4 480>;
+   lcd-vtiming = <4 4 4 320>;
+   supports-mipi-panel;
+   };
+
+   fimd {
+   samsung,fimd-display = <_fimd0>;
+   samsung,fimd-vidout-rgb;
+   samsung,fimd-inv-vclk;
+   samsung,fimd-frame-rate = <60>;
+   samsung,default-window = <0>;
+   samsung,fimd-win-bpp = <32>;
+   };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1ad10b6..b2d22ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+static const struct of_device_id fimd_dt_match[];
+
 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+#ifdef CONFIG_OF
+   if (pdev->dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_ptr(fimd_dt_match);
+   return (struct fimd_driver_data *)match->data;
+   }
+#endif
return (struct fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
 }
@@ -809,12 +819,77 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
return 0;
 }

+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device 
*dev)
+{
+   struct device_node *np = dev->of_node;
+   struct device_node *disp_np;
+   struct exynos_drm_fimd_pdata *pd;
+   u32 data[4];
+
+   pd = 

[PATCH V6 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd

2012-09-21 Thread Leela Krishna Amudala
Two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.

Signed-off-by: Leela Krishna Amudala 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   43 +++---
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index d96db5e..1ad10b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@

 #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))

+struct fimd_driver_data {
+   unsigned int timing_base;
+};
+
+struct fimd_driver_data exynos4_fimd_driver_data = {
+   .timing_base = 0x0,
+};
+
+struct fimd_driver_data exynos5_fimd_driver_data = {
+   .timing_base = 0x2,
+};
+
 struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };

+static inline struct fimd_driver_data *drm_fimd_get_driver_data(
+   struct platform_device *pdev)
+{
+   return (struct fimd_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+}
+
 static bool fimd_display_is_connected(struct device *dev)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -194,32 +213,35 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx->panel;
struct fb_videomode *timing = >timing;
+   struct fimd_driver_data *driver_data;
+   struct platform_device *pdev = to_platform_device(dev);
u32 val;

+   driver_data = drm_fimd_get_driver_data(pdev);
if (ctx->suspended)
return;

DRM_DEBUG_KMS("%s\n", __FILE__);

/* setup polarity values from machine code. */
-   writel(ctx->vidcon1, ctx->regs + VIDCON1);
+   writel(ctx->vidcon1, ctx->regs + driver_data->timing_base + VIDCON1);

/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing->upper_margin - 1) |
   VIDTCON0_VFPD(timing->lower_margin - 1) |
   VIDTCON0_VSPW(timing->vsync_len - 1);
-   writel(val, ctx->regs + VIDTCON0);
+   writel(val, ctx->regs + driver_data->timing_base + VIDTCON0);

/* setup horizontal timing values.  */
val = VIDTCON1_HBPD(timing->left_margin - 1) |
   VIDTCON1_HFPD(timing->right_margin - 1) |
   VIDTCON1_HSPW(timing->hsync_len - 1);
-   writel(val, ctx->regs + VIDTCON1);
+   writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);

/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
   VIDTCON2_HOZVAL(timing->xres - 1);
-   writel(val, ctx->regs + VIDTCON2);
+   writel(val, ctx->regs + driver_data->timing_base + VIDTCON2);

/* setup clock source, clock divider, enable dma. */
val = ctx->vidcon0;
@@ -977,6 +999,18 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif

+static struct platform_device_id fimd_driver_ids[] = {
+   {
+   .name   = "exynos4-fb",
+   .driver_data= (unsigned long)_fimd_driver_data,
+   }, {
+   .name   = "exynos5-fb",
+   .driver_data= (unsigned long)_fimd_driver_data,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
+
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -985,6 +1019,7 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = __devexit_p(fimd_remove),
+   .id_table   = fimd_driver_ids,
.driver = {
.name   = "exynos4-fb",
.owner  = THIS_MODULE,
-- 
1.7.0.4



[PATCH V6 0/2] video: drm: Add Device tree support to exynos DRM-FIMD

2012-09-21 Thread Leela Krishna Amudala
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos4 and exynos5 devices.

This patchset is based and tested on top of v3.6-rc4 on smdk5250 board
Also depends on below patchset
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html

Changes since V5:
- Moved the documentation file to appropriate location.
- Given more description in the commit message to the patch 
  video: drm: exynos: Add device tree support

Changes since V4:
- Changed the compatible string from "samsung,exynos4-fb" to
  "samsung,exynos4-fimd".

Changes since V3:
- Removed the fimd version from driver data and using timing base
  address instead
- Removed the drm_ prefixes to the structures and fucntions

Changes since V2:
- Added driver data to exynos5-drm-fimd as per Marek Szyprowski 
suggestion

Changes since V1:
- Corrected typo errors and changed compatibility string

Leela Krishna Amudala (2):
  drm/exynos: add platform_device_id table and driver data for drm fimd
  video: drm: exynos: Add device tree support

 .../devicetree/bindings/drm/exynos/fimd.txt|   80 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  138 +++-
 2 files changed, 212 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/exynos/fimd.txt



[PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Inki Dae
2012/9/21 Stephen Warren :
> On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
>> This patch adds device tree based discovery support for exynos DRM-FIMD
>> driver which includes driver modification to handle platform data in
>> both the cases with DT and non-DT, Also adds the documentation for bindings.
>
>> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
>> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
> ...
>> + - samsung,fimd-display: This property should specify the phandle of the
>> +   display device node which holds the video interface timing with the
>> +   below mentioned properties.
>> +
>> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
>> + horizontal timing includes four parameters in the following order.
>> +
>> + - horizontal back porch (in number of lcd clocks)
>> + - horizontal front porch (in number of lcd clocks)
>> + - hsync pulse width (in number of lcd clocks)
>> + - Display panels X resolution.
>> +
>> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
>> + vertical timing includes four parameters in the following order.
>> +
>> + - vertical back porch (in number of lcd lines)
>> + - vertical front porch (in number of lcd lines)
>> + - vsync pulse width (in number of lcd clocks)
>> + - Display panels Y resolution.
>
> Should this not use the new videomode timings that are under discussion at:
>
> http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
>

ok, I agree with you. then the videomode helper is going to be merged
to mainline(3.6)? if so, this patch should be reworked based on the
videomode helper.


> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

2012-09-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=49943

--- Comment #8 from Harald Judt  2012-09-21 16:05:14 UTC ---
Reproducible with linux-3.6.0-rc6. If it is a duplicate of bug 51042, shouldn't
this be fixed now, or have the patches referenced in that bug not been
committed yet
(http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/22107, or
more specific the patches by Daniel Vetter:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023407.html)?

I still get only two events when monitoring with udevadm:

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[601.731162] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
MAJOR=226
MINOR=0
SEQNUM=1407
SUBSYSTEM=drm

UDEV  [601.731859] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
MAJOR=226
MINOR=0
SEQNUM=1407
SUBSYSTEM=drm

After that, no more events on plug/unplug.

-- 
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/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740

2012-09-21 Thread Greg KH
On Fri, Sep 21, 2012 at 08:56:27AM -0400, Josh Boyer wrote:
> On Tue, Aug 28, 2012 at 4:50 PM,   wrote:
> > From: Jerome Glisse 
> >
> > It seems some of those IGP dislike non dma32 page despite what
> > documentation says. Fix regression since we allowed non dma32
> > pages. It seems it only affect some revision of those IGP chips
> > as we don't know which one just force dma32 for all of them.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=785375
> >
> > Signed-off-by: Jerome Glisse 
> > Cc: 
> 
> 
> This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f.  I
> don't see it queued up in the stable-queue, so I thought I'd point it
> out in case it was missed.

I am way behind on the drm patches for stable, I have a ton of them in
my todo-queue, but have been traveling all week at a conference and
haven't had the chance to get to them.  Hopefully I'll be able to flush
them all out next week, but don't worry, it's not lost.

thanks,

greg k-h


[PATCH] drm/exynos: Fix potential NULL pointer dereference

2012-09-21 Thread Inki Dae
Applied.

Thanks,
Inki Dae

2012/9/18 Sachin Kamat :
> drm_mode_create() returns NULL if it fails to create
> a new display mode. Check the value returned to avoid NULL
> pointer deferencing later.
>
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index 9dce3b9..485e984 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -149,8 +149,12 @@ static int exynos_drm_connector_get_modes(struct 
> drm_connector *connector)
> count = drm_add_edid_modes(connector, edid);
> kfree(edid);
> } else {
> -   struct drm_display_mode *mode = 
> drm_mode_create(connector->dev);
> struct exynos_drm_panel_info *panel;
> +   struct drm_display_mode *mode = 
> drm_mode_create(connector->dev);
> +   if (!mode) {
> +   DRM_ERROR("failed to create a new display mode.\n");
> +   return 0;
> +   }
>
> if (display_ops->get_panel)
> panel = display_ops->get_panel(manager->dev);
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at 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

2012-09-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=49817

--- Comment #15 from Sven Arvidsson  2012-09-21 15:26:12 UTC ---
Are you guys talking about the same sample causing the bug? If not, it's
probably different bugs.

-- 
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

2012-09-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=49817

Laurent carlier  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #14 from Laurent carlier  2012-09-21 
15:20:42 UTC ---
Not fixed for me with:
* libdrm-2.4.39
* mesa from git
 OpenGL renderer string: Gallium 0.4 on AMD BARTS
 OpenGL version string: 3.0 Mesa 9.1-devel (git-aa3c2e3)
 OpenGL shading language version string: 1.30
* kernel 2.6rc6
 Linux archMain 3.6.0-1-mainline #1 SMP PREEMPT Mon Sep 17 14:03:55 UTC 2012
x86_64 GNU/Linux


[163750.003001] radeon :01:00.0: evergreen_cs_track_validate_texture:842
texture bo too small (layer size 256000, offset 0, max layer 1, depth 1, bo
size 4096) (800 80)
[163750.003006] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[163750.019950] radeon :01:00.0: evergreen_cs_track_validate_texture:842
texture bo too small (layer size 256000, offset 0, max layer 1, depth 1, bo
size 4096) (800 80)
[163750.019960] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[163750.042266] radeon :01:00.0: evergreen_cs_track_validate_texture:842
texture bo too small (layer size 256000, offset 0, max layer 1, depth 1, bo
size 4096) (800 80)
[163750.042277] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

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


[PATCH v4] of: Add videomode helper

2012-09-21 Thread Hans Verkuil
On Wed September 19 2012 10:20:43 Steffen Trumtrar wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
> 
> Signed-off-by: Sascha Hauer 
> Signed-off-by: Steffen Trumtrar 
> ---
> 
> Hi!
> 
> changes since v3:
>   - print error messages
>   - free alloced memory
>   - general cleanup
> 
> Regards
> Steffen
> 
>  .../devicetree/bindings/video/displaymode  |   74 +
>  drivers/of/Kconfig |5 +
>  drivers/of/Makefile|1 +
>  drivers/of/of_videomode.c  |  283 
> 
>  include/linux/of_videomode.h   |   56 
>  5 files changed, 419 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/displaymode
>  create mode 100644 drivers/of/of_videomode.c
>  create mode 100644 include/linux/of_videomode.h
> 
> diff --git a/Documentation/devicetree/bindings/video/displaymode 
> b/Documentation/devicetree/bindings/video/displaymode
> new file mode 100644
> index 000..990ca52
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/displaymode
> @@ -0,0 +1,74 @@
> +videomode bindings
> +==
> +
> +Required properties:
> + - hactive, vactive: Display resolution
> + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
> +   in pixels
> +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
> in
> +   lines

In the case of interlaced formats, can the vfront-porch, vback-porch and 
vsync-len
for the second field always be calculated from these values? Is that fully
standardized or can there be exceptions? struct v4l2_bt_timings has separate 
fields
for these, but that may have been overkill.

> + - clock: displayclock in Hz

CEA-861 defined the option to slightly lower the clock frequency by 1.000/1.001 
to
achieve frequencies like 29.97 or 59.94. In v4l2_bt_timings I made a flag for 
that.
I'm not sure whether it is better to just set the clock to the correct frequency
(which is a weird value) or mark it with a bool.

> +
> +Optional properties:
> + - width-mm, height-mm: Display dimensions in mm
> + - hsync-active-high (bool): Hsync pulse is active high
> + - vsync-active-high (bool): Vsync pulse is active high
> + - interlaced (bool): This is an interlaced mode
> + - doublescan (bool): This is a doublescan mode
> +
> +There are different ways of describing a display mode. The devicetree 
> representation
> +corresponds to the one commonly found in datasheets for displays.
> +The description of the display and its mode is split in two parts: first the 
> display
> +properties like size in mm and (optionally) multiple subnodes with the 
> supported modes.
> +
> +Example:
> +
> + display at 0 {
> + width-mm = <800>;
> + height-mm = <480>;
> + modes {
> + mode0: mode at 0 {
> + /* 1920x1080p24 */
> + clock = <5200>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hfront-porch = <25>;
> + hback-porch = <25>;
> + hsync-len = <25>;
> + vback-porch = <2>;
> + vfront-porch = <2>;
> + vsync-len = <2>;
> + hsync-active-high;
> + };
> + };
> + };
> +
> +Every property also supports the use of ranges, so the commonly used 
> datasheet
> +description with -tuples can be used.
> +
> +Example:
> +
> + mode1: mode at 1 {
> + /* 1920x1080p24 */
> + clock = <14850>;
> + hactive = <1920>;
> + vactive = <1080>;
> + hsync-len = <0 44 60>;
> + hfront-porch = <80 88 95>;
> + hback-porch = <100 148 160>;
> + vfront-porch = <0 4 6>;
> + vback-porch = <0 36 50>;
> + vsync-len = <0 5 6>;
> + };
> +
> +The videomode can be linked to a connector via phandles. The connector has to
> +support the display- and default-mode-property to link to and select a mode.
> +
> +Example:
> +
> + hdmi at 0012 {
> + status = "okay";
> + display = <>;
> + default-mode = <>;
> + };
> +
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index dfba3e6..a3acaa3 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -83,4 +83,9 @@ config OF_MTD
>   depends on MTD
>   def_bool y
>  
> +config OF_VIDEOMODE
> + def_bool y
> + help
> +   helper to parse videomodes from the devicetree
> +
>  endmenu # OF
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index e027f44..80e6db3 100644

[PATCH v4] of: Add videomode helper

2012-09-21 Thread Steffen Trumtrar


On Thu, Sep 20, 2012 at 11:29:42PM +0200, Laurent Pinchart wrote:
> Hi,
> 
> (CC'ing the linux-media mailing list, as video modes are of interest there as 
> well)
> 
> On Wednesday 19 September 2012 12:19:22 Tomi Valkeinen wrote:
> > On Wed, 2012-09-19 at 10:20 +0200, Steffen Trumtrar wrote:
> > > This patch adds a helper function for parsing videomodes from the
> > > devicetree. The videomode can be either converted to a struct
> > > drm_display_mode or a struct fb_videomode.
> > > 
> > > Signed-off-by: Sascha Hauer 
> > > Signed-off-by: Steffen Trumtrar 
> > > ---
> > > 
> > > Hi!
> > > 
> > > changes since v3:
> > >   - print error messages
> > >   - free alloced memory
> > >   - general cleanup
> > > 
> > > Regards
> > > Steffen
> > > 
> > >  .../devicetree/bindings/video/displaymode  |   74 +
> > >  drivers/of/Kconfig |5 +
> > >  drivers/of/Makefile|1 +
> > >  drivers/of/of_videomode.c  |  283 +++
> > >  include/linux/of_videomode.h   |   56 
> > >  5 files changed, 419 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/video/displaymode
> > >  create mode 100644 drivers/of/of_videomode.c
> > >  create mode 100644 include/linux/of_videomode.h
> > > 
> > > diff --git a/Documentation/devicetree/bindings/video/displaymode
> > > b/Documentation/devicetree/bindings/video/displaymode new file mode
> > > 100644
> > > index 000..990ca52
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/displaymode
> > > @@ -0,0 +1,74 @@
> > > +videomode bindings
> > > +==
> > > +
> > > +Required properties:
> > > + - hactive, vactive: Display resolution
> > > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
> > > parameters
> > > +   in pixels
> > > +   vfront-porch, vback-porch, vsync-len: Vertical display timing
> > > parameters in
> > > +   lines
> > > + - clock: displayclock in Hz
> > > +
> > > +Optional properties:
> > > + - width-mm, height-mm: Display dimensions in mm
> > > + - hsync-active-high (bool): Hsync pulse is active high
> > > + - vsync-active-high (bool): Vsync pulse is active high
> > > + - interlaced (bool): This is an interlaced mode
> > > + - doublescan (bool): This is a doublescan mode
> > > +
> > > +There are different ways of describing a display mode. The devicetree
> > > representation
> > > +corresponds to the one commonly found in datasheets for displays.
> > > +The description of the display and its mode is split in two parts: first
> > > the display
> > > +properties like size in mm and (optionally) multiple subnodes with the
> > > supported modes.
> > > +
> > > +Example:
> > > +
> > > + display at 0 {
> > > + width-mm = <800>;
> > > + height-mm = <480>;
> > > + modes {
> > > + mode0: mode at 0 {
> > > + /* 1920x1080p24 */
> > > + clock = <5200>;
> > > + hactive = <1920>;
> > > + vactive = <1080>;
> > > + hfront-porch = <25>;
> > > + hback-porch = <25>;
> > > + hsync-len = <25>;
> > > + vback-porch = <2>;
> > > + vfront-porch = <2>;
> > > + vsync-len = <2>;
> > > + hsync-active-high;
> > > + };
> > > + };
> > > + };
> > > +
> > > +Every property also supports the use of ranges, so the commonly used
> > > datasheet +description with -tuples can be used.
> > > +
> > > +Example:
> > > +
> > > + mode1: mode at 1 {
> > > + /* 1920x1080p24 */
> > > + clock = <14850>;
> > > + hactive = <1920>;
> > > + vactive = <1080>;
> > > + hsync-len = <0 44 60>;
> > > + hfront-porch = <80 88 95>;
> > > + hback-porch = <100 148 160>;
> > > + vfront-porch = <0 4 6>;
> > > + vback-porch = <0 36 50>;
> > > + vsync-len = <0 5 6>;
> > > + };
> > > +
> > > +The videomode can be linked to a connector via phandles. The connector
> > > has to
> > > +support the display- and default-mode-property to link to and select a
> > > mode.
> > > +
> > > +Example:
> > > +
> > > + hdmi at 0012 {
> > > + status = "okay";
> > > + display = <>;
> > > + default-mode = <>;
> > > + };
> > > +
> > > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > > index dfba3e6..a3acaa3 100644
> > > --- a/drivers/of/Kconfig
> > > +++ b/drivers/of/Kconfig
> > > @@ -83,4 +83,9 @@ config OF_MTD
> > > 
> > >   depends on MTD
> > >   def_bool y
> > > 
> > > +config OF_VIDEOMODE
> > > + def_bool y
> > > + help
> > > +   helper to parse videomodes from the devicetree
> > > +
> > > 
> > >  endmenu # OF
> > > 
> > > diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> > > index 

[PATCH V2] drm/exynos: Add match table for drm platform device

2012-09-21 Thread Srinivas KANDAGATLA
On 21/09/12 19:37, Leela Krishna Amudala wrote:
> This patch is a part of moving the driver to support DT style probing
> of exynos drm device. The compatible name should match with the
> entry in the dtsi file.
>
> Signed-off-by: Leela Krishna Amudala 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |   11 +++
>  1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index d070719..495be89 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -294,12 +294,23 @@ static int exynos_drm_platform_remove(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id drm_device_dt_match[] = {
> + { .compatible = "samsung,exynos-drm-device"},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, drm_device_dt_match);
> +#else
> +#define drm_device_dt_match NULL
> +#endif

No need of else here as you are using of_match_ptr.

> +
>  static struct platform_driver exynos_drm_platform_driver = {
>   .probe  = exynos_drm_platform_probe,
>   .remove = __devexit_p(exynos_drm_platform_remove),
>   .driver = {
>   .owner  = THIS_MODULE,
>   .name   = "exynos-drm",
> + .of_match_table = of_match_ptr(drm_device_dt_match),
>   },
>  };
>  



[git pull] drm rc7 fixes

2012-09-21 Thread Dave Airlie

Hi Linus,

 fixes for big 3 drivers:
nouveau: revert earlier MBP fix, put a dmi based MBP fix in its place 
(fixes a regression we found on some Dell eDP panels doing some internal 
tseting)
radeon: revert pll fixes, real fix is too invasive, fix scratch leak
intel: 3 minor fixes, one for HDMI audio.

Dave.

The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2:

  Linux 3.6-rc6 (2012-09-16 14:58:51 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to 017a27e7f52346ca8de6fc776579fbcc8ea55b48:

  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes (2012-09-21 
20:46:01 +1000)



Alex Deucher (1):
  Revert "drm/radeon: rework pll selection (v3)"

Chris Wilson (1):
  drm/i915: Reduce a pin-leak BUG into a WARN

Daniel Vetter (1):
  drm/i915: enable lvds pin pairs before dpll on gen2

Dave Airlie (5):
  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  Revert "drm/nv50-/gpio: initialise to vbios defaults during init"
  Merge branch 'drm-fixes-3.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes
  drm/nouveau: add dmi quirk for gpio reset
  Merge branch 'drm-intel-fixes' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-fixes

Simon Kitching (1):
  drm/radeon: Prevent leak of scratch register on resume from suspend

Wang Xingchao (1):
  drm/i915: HDMI - Clear Audio Enable bit for Hot Plug

 drivers/gpu/drm/i915/i915_gem.c|   3 +-
 drivers/gpu/drm/i915/intel_display.c   |  12 +--
 drivers/gpu/drm/i915/intel_hdmi.c  |   2 +-
 drivers/gpu/drm/nouveau/nv50_gpio.c|  15 ++-
 drivers/gpu/drm/radeon/atombios_crtc.c | 163 +++--
 drivers/gpu/drm/radeon/r100.c  |   3 +-
 6 files changed, 59 insertions(+), 139 deletions(-)


答复: 转发: Siliconmotion new kernel driver initial patch

2012-09-21 Thread Konrad Rzeszutek Wilk
On Fri, Aug 24, 2012 at 10:35:00AM +0800, Aaron.Chen  ??? wrote:
> Hi,
> 
> >What's with the #ifdef 0 or #ifdef 1?
> 
> >Why is there a bunch of ddkxxx something? Can those header files be squashed 
> >together?
> 
> We have deleted all the "#ifdef 0 or #ifdef 1" and cut our codes into smaller 
> parts in order to get reviewed easier. There are less ddkxxx something in 
> this patch.

Please next time post it inline, not as attachment.

Also explain why/where what machines this runs on.

>From 35c8c1675e2bf6d8e7a702d61558b99316aaeabe Mon Sep 17 00:00:00 2001
>From: Aaron Chen 
>Date: Fri, 24 Aug 2012 10:03:54 +0800
>Subject: [PATCH] siliconmotion kernel driver initial patch
>
>This is the initial patch for siliconmotion kernel driver. It can support 
>SM750 and SM718. It is a framebuffer driver.
>
>Signed-off-by: Aaron Chen 
>---
> drivers/video/Kconfig |   13 +
> drivers/video/Makefile|1 +
> drivers/video/lynxfb/Makefile |   63 ++
> drivers/video/lynxfb/ddk750.h |   31 +
> drivers/video/lynxfb/ddk750_chip.c|  586 
> drivers/video/lynxfb/ddk750_chip.h|   97 ++
> drivers/video/lynxfb/ddk750_display.c |  295 ++
> drivers/video/lynxfb/ddk750_display.h |  124 +++
> drivers/video/lynxfb/ddk750_dvi.c |  114 +++
> drivers/video/lynxfb/ddk750_dvi.h |   84 ++
> drivers/video/lynxfb/ddk750_help.c|   37 +
> drivers/video/lynxfb/ddk750_help.h|   42 +
> drivers/video/lynxfb/ddk750_hwi2c.c   |  290 ++
> drivers/video/lynxfb/ddk750_hwi2c.h   |   28 +
> drivers/video/lynxfb/ddk750_mode.c|  213 +
> drivers/video/lynxfb/ddk750_mode.h|   59 ++
> drivers/video/lynxfb/ddk750_power.c   |  243 +
> drivers/video/lynxfb/ddk750_power.h   |   85 ++
> drivers/video/lynxfb/ddk750_reg.h |  362 +++
> drivers/video/lynxfb/ddk750_sii164.c  |  435 +
> drivers/video/lynxfb/ddk750_sii164.h  |  187 
> drivers/video/lynxfb/ddk750_swi2c.c   |  522 ++
> drivers/video/lynxfb/ddk750_swi2c.h   |   98 ++
> drivers/video/lynxfb/lynx_accel.c |  417 
> drivers/video/lynxfb/lynx_accel.h |  161 
> drivers/video/lynxfb/lynx_cursor.c|  223 +
> drivers/video/lynxfb/lynx_cursor.h|   36 +
> drivers/video/lynxfb/lynx_drv.c   | 1688 +
> drivers/video/lynxfb/lynx_drv.h   |  271 ++
> drivers/video/lynxfb/lynx_help.h  |  115 +++
> drivers/video/lynxfb/lynx_hw750.c |  633 +
> drivers/video/lynxfb/lynx_hw750.h |  120 +++
> drivers/video/lynxfb/modedb.c |  238 +
> drivers/video/lynxfb/ver.h|   38 +
> 34 files changed, 7949 insertions(+)
> create mode 100644 drivers/video/lynxfb/Makefile
> create mode 100644 drivers/video/lynxfb/ddk750.h
> create mode 100644 drivers/video/lynxfb/ddk750_chip.c
> create mode 100644 drivers/video/lynxfb/ddk750_chip.h
> create mode 100644 drivers/video/lynxfb/ddk750_display.c
> create mode 100644 drivers/video/lynxfb/ddk750_display.h
> create mode 100644 drivers/video/lynxfb/ddk750_dvi.c
> create mode 100644 drivers/video/lynxfb/ddk750_dvi.h
> create mode 100644 drivers/video/lynxfb/ddk750_help.c
> create mode 100644 drivers/video/lynxfb/ddk750_help.h
> create mode 100644 drivers/video/lynxfb/ddk750_hwi2c.c
> create mode 100644 drivers/video/lynxfb/ddk750_hwi2c.h
> create mode 100644 drivers/video/lynxfb/ddk750_mode.c
> create mode 100644 drivers/video/lynxfb/ddk750_mode.h
> create mode 100644 drivers/video/lynxfb/ddk750_power.c
> create mode 100644 drivers/video/lynxfb/ddk750_power.h
> create mode 100644 drivers/video/lynxfb/ddk750_reg.h
> create mode 100644 drivers/video/lynxfb/ddk750_sii164.c
> create mode 100644 drivers/video/lynxfb/ddk750_sii164.h
> create mode 100644 drivers/video/lynxfb/ddk750_swi2c.c
> create mode 100644 drivers/video/lynxfb/ddk750_swi2c.h
> create mode 100644 drivers/video/lynxfb/lynx_accel.c
> create mode 100644 drivers/video/lynxfb/lynx_accel.h
> create mode 100644 drivers/video/lynxfb/lynx_cursor.c
> create mode 100644 drivers/video/lynxfb/lynx_cursor.h
> create mode 100644 drivers/video/lynxfb/lynx_drv.c
> create mode 100644 drivers/video/lynxfb/lynx_drv.h
> create mode 100644 drivers/video/lynxfb/lynx_help.h
> create mode 100644 drivers/video/lynxfb/lynx_hw750.c
> create mode 100644 drivers/video/lynxfb/lynx_hw750.h
> create mode 100644 drivers/video/lynxfb/modedb.c
> create mode 100644 drivers/video/lynxfb/ver.h
>
>diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>index 0217f74..8c52b1a 100644
>--- a/drivers/video/Kconfig
>+++ b/drivers/video/Kconfig
>@@ -2444,6 +2444,19 @@ config FB_PUV3_UNIGFX
> Choose this option if you want to use the Unigfx device as a
> framebuffer device. Without the support of PCI & AGP.
> 
>+config FB_LYNXFB
>+  tristate "SMI lynx sm750/718/712/722/502 display support"
>+  depends on FB && PCI
>+  select FB_CFB_IMAGEBLIT
>+  select FB_CFB_FILLRECT
>+  select FB_CFB_COPYAREA
>+ 

FOSDEM2013: DevRoom or not?

2012-09-21 Thread Luc Verhaegen
On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote:
> Hi,
> 
> The FOSDEM organizers have sent out a call for devrooms. FOSDEM this 
> year is on the weekend of the 2nd and 3rd of February 2013.
> 
> After the success of this formula last year, where, for the first time 
> ever, we had a properly filled devroom schedule when the deadline hit, i 
> am going to re-apply the same formula:
> * By the 28th of september, i need 6 committed speakers, otherwise i 
>   will not apply for a DevRoom. 6 people need to apply for a talk slot 
>   who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. 
>   This "definitely" means:
> * Don't knowingly plan anything else for this weekend.
> * Come to FOSDEM even if your corporation does not fund you (though 
>   feel free to contact the board individually for funding)
> * Make sure that you are allowed to travel to the shengen area in 
>   february.
> * Catastrophies excluded of course. Such catastrophies include 
>   things like train-derailments and such, but explicitely excludes 
>   hangovers :p
> * Scheduling based on timeliness of application: the earlier you apply, 
>   the better slot you get.
> * FOSDEMs final deadline for the full schedule is likely around 15th of 
>   january 2013. But do not count on that deadline, we will only do 
>   hourly slots, to keep people from running around between devrooms like 
>   headless chickens. Only 12-16 slots will be available, first come, 
>   first serve.
> 
> I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 
> 
> I hope we get a nice devroom like we had last time. That new building we 
> were in was really amazing, even though it took a while before all 
> FOSDEM visitors found it.
> 
> Thanks,
> 
> Luc Verhaegen.

Just a heads up guys, we have a week left and not a single speaker yet!

Given the timing of XDC and the FOSDEM deadines, this is not too 
surprising, but still, with XDC2012 in its final day it is high time 
that we start thinking about FOSDEM. I will later on shout at people 
here in the room too :)

All we need now is people who will definitely come to FOSDEM, and who 
are willing to talk in the DevRoom. If a vague idea of a topic is 
already known, then great, but this is not necessary yet. I now put up a 
preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the 
list there.

Thanks,

Luc Verhaegen.


[PATCH 6/6] staging: drm/imx: Add TODO

2012-09-21 Thread Sascha Hauer
Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/TODO |   22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 drivers/staging/imx-drm/TODO

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
new file mode 100644
index 000..e52adc4
--- /dev/null
+++ b/drivers/staging/imx-drm/TODO
@@ -0,0 +1,22 @@
+TODO:
+- get DRM Maintainer review for this code
+- Factor out more code to common helper functions
+- decide where to put the base driver. It is not specific to a subsystem
+  and would be used by DRM/KMS and media/V4L2
+- convert irq driver to irq_domain_add_linear
+
+Missing features (not necessarily for moving out of staging):
+
+- Add KMS plane support for CRTC driver
+- Add LDB (LVDS Display Bridge) support
+- Add i.MX6 HDMI support
+- Add support for IC (Image converter)
+- Add support for CSI (CMOS Sensor interface)
+- Add support for VDIC (Video Deinterlacer)
+
+Many work-in-progress patches for the above features exist. Contact
+Sascha Hauer  if you are interested in working
+on a specific feature.
+
+Please send any patches to Greg Kroah-Hartman  
and
+Sascha Hauer 
-- 
1.7.10.4



[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation

2012-09-21 Thread Sascha Hauer
From: Philipp Zabel 

Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
new file mode 100644
index 000..07654f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -0,0 +1,41 @@
+Freescale i.MX IPUv3
+
+
+Required properties:
+- compatible: Should be "fsl,-ipu"
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain sync interrupt and error interrupt,
+  in this order.
+- #crtc-cells: 1, See below
+
+example:
+
+ipu: ipu at 1800 {
+   #crtc-cells = <1>;
+   compatible = "fsl,imx53-ipu";
+   reg = <0x1800 0x08000>;
+   interrupts = <11 10>;
+};
+
+Parallel display support
+
+
+Required properties:
+- compatible: Should be "fsl,imx-parallel-display"
+- crtc: the crtc this display is connected to, see below
+Optional properties:
+- interface_pix_fmt: How this display is connected to the
+  crtc. Currently supported types: "rgb24", "rgb565"
+- edid: verbatim EDID data block describing attached display.
+- ddc: phandle describing the i2c bus handling the display data
+  channel
+
+example:
+
+display at di0 {
+   compatible = "fsl,imx-parallel-display";
+   edid = [edid-data];
+   crtc = < 0>;
+   interface-pix-fmt = "rgb24";
+};
-- 
1.7.10.4



[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support

2012-09-21 Thread Sascha Hauer
This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
board and the i.MX6q sabrelite board in different clone mode and dual
head setups.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/Kconfig  |6 +
 drivers/staging/imx-drm/Makefile |1 +
 drivers/staging/imx-drm/ipuv3-crtc.c |  579 ++
 3 files changed, 586 insertions(+)
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 4849bfa..14b4449 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -27,3 +27,9 @@ config DRM_IMX_IPUV3_CORE
  Choose this if you have a i.MX5/6 system and want
  to use the IPU. This option only enables IPU base
  support.
+
+config DRM_IMX_IPUV3
+   tristate "DRM Support for i.MX IPUv3"
+   depends on DRM_IMX
+   help
+ Choose this if you have a i.MX5 or i.MX6 processor.
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index e3a5b6f..83a9056 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRM_IMX) += imxdrm.o
 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
 obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
+obj-$(CONFIG_DRM_IMX_IPUV3)+= ipuv3-crtc.o
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
new file mode 100644
index 000..78d3eda
--- /dev/null
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -0,0 +1,579 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu-v3/imx-ipu-v3.h"
+#include "imx-drm.h"
+
+#define DRIVER_DESC"i.MX IPUv3 Graphics"
+
+struct ipu_framebuffer {
+   struct drm_framebuffer  base;
+   void*virt;
+   dma_addr_t  phys;
+   size_t  len;
+};
+
+struct ipu_crtc {
+   struct drm_fb_helperfb_helper;
+   struct ipu_framebuffer  ifb;
+   int num_crtcs;
+   struct device   *dev;
+   struct drm_crtc base;
+   struct imx_drm_crtc *imx_crtc;
+   struct ipuv3_channel*ipu_ch;
+   struct ipu_dc   *dc;
+   struct ipu_dp   *dp;
+   struct dmfc_channel *dmfc;
+   struct ipu_di   *di;
+   int enabled;
+   struct ipu_priv *ipu_priv;
+   struct drm_pending_vblank_event *page_flip_event;
+   struct drm_framebuffer  *newfb;
+   int irq;
+   u32 interface_pix_fmt;
+   unsigned long   di_clkflags;
+};
+
+#define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)
+
+static int calc_vref(struct drm_display_mode *mode)
+{
+   unsigned long htotal, vtotal;
+
+   htotal = mode->htotal;
+   vtotal = mode->vtotal;
+
+   if (!htotal || !vtotal)
+   return 60;
+
+   return mode->clock * 1000 / vtotal / htotal;
+}
+
+static int calc_bandwidth(struct drm_display_mode *mode, unsigned int vref)
+{
+   return mode->hdisplay * mode->vdisplay * vref;
+}
+
+static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
+{
+   if (ipu_crtc->enabled)
+   return;
+
+   ipu_di_enable(ipu_crtc->di);
+   ipu_dmfc_enable_channel(ipu_crtc->dmfc);
+   ipu_idmac_enable_channel(ipu_crtc->ipu_ch);
+   ipu_dc_enable_channel(ipu_crtc->dc);
+   if (ipu_crtc->dp)
+   ipu_dp_enable_channel(ipu_crtc->dp);
+
+   ipu_crtc->enabled = 1;
+}
+
+static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
+{
+   if (!ipu_crtc->enabled)
+   return;
+
+   if (ipu_crtc->dp)
+   ipu_dp_disable_channel(ipu_crtc->dp);
+   ipu_dc_disable_channel(ipu_crtc->dc);
+   ipu_idmac_disable_channel(ipu_crtc->ipu_ch);
+   ipu_dmfc_disable_channel(ipu_crtc->dmfc);
+   

[PATCH 3/6] staging: drm/imx: add i.MX IPUv3 base driver

2012-09-21 Thread Sascha Hauer
The IPU is the Image Processing Unit found on i.MX51/53/6 SoCs. It
features several units for image processing, this patch adds support
for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different
approach. The Freescale code implements logical idmac channels and
the handling of the subunits is hidden in common idmac code pathes
in big switch/case statements. This patch instead just provides code
and resource management for the different subunits. The user, in this
case the framebuffer driver, decides how the different units play
together.

The IPU has other units missing in this patch:

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/Kconfig |8 +
 drivers/staging/imx-drm/Makefile|1 +
 drivers/staging/imx-drm/imx-drm-core.c  |2 +
 drivers/staging/imx-drm/ipu-v3/Makefile |3 +
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  318 
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 1143 +++
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c |  372 +
 drivers/staging/imx-drm/ipu-v3/ipu-di.c |  700 
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c   |  408 ++
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c |  336 
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  206 +
 11 files changed, 3497 insertions(+)
 create mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile
 create mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 9e27012..4849bfa 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -19,3 +19,11 @@ config DRM_IMX_FB_HELPER
 config DRM_IMX_PARALLEL_DISPLAY
tristate "Support for parallel displays"
depends on DRM_IMX
+
+config DRM_IMX_IPUV3_CORE
+   tristate "IPUv3 core support"
+   depends on DRM_IMX
+   help
+ Choose this if you have a i.MX5/6 system and want
+ to use the IPU. This option only enables IPU base
+ support.
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index c8f582e..e3a5b6f 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_DRM_IMX) += imxdrm.o

 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
+obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
index 225e835..1913199b 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -137,6 +137,7 @@ found:
encoder_type, interface_pix_fmt);
return 0;
 }
+EXPORT_SYMBOL_GPL(imx_drm_crtc_panel_format);

 int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc)
 {
@@ -647,6 +648,7 @@ int imx_drm_encoder_add_possible_crtcs(

return 0;
 }
+EXPORT_SYMBOL_GPL(imx_drm_encoder_add_possible_crtcs);

 int imx_drm_encoder_get_mux_id(struct imx_drm_encoder *imx_drm_encoder,
struct drm_crtc *crtc)
diff --git a/drivers/staging/imx-drm/ipu-v3/Makefile 
b/drivers/staging/imx-drm/ipu-v3/Makefile
new file mode 100644
index 000..28ed72e
--- /dev/null
+++ b/drivers/staging/imx-drm/ipu-v3/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += imx-ipu-v3.o
+
+imx-ipu-v3-objs := ipu-common.o ipu-dc.o ipu-di.o ipu-dp.o ipu-dmfc.o
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
new file mode 100644
index 000..74158dd
--- /dev/null
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -0,0 +1,318 @@
+/*
+ * Copyright 2005-2009 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU Lesser General
+ * Public License.  You may obtain a copy of the GNU Lesser General
+ * Public License Version 2.1 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/lgpl-license.html
+ * http://www.gnu.org/copyleft/lgpl.html
+ */
+
+#ifndef __DRM_IPU_H__
+#define __DRM_IPU_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct ipu_soc;
+
+enum ipuv3_type {
+   IPUV3EX,
+   IPUV3M,
+   IPUV3H,
+};
+

[PATCH 2/6] staging: drm/imx: Add parallel display support

2012-09-21 Thread Sascha Hauer
This adds support for parallel displays for i.MX. It consists
of a drm encoder/connector pair which eventually passes EDID
data from the devicetree to the drm core.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/Kconfig|4 +
 drivers/staging/imx-drm/Makefile   |1 +
 drivers/staging/imx-drm/parallel-display.c |  261 
 3 files changed, 266 insertions(+)
 create mode 100644 drivers/staging/imx-drm/parallel-display.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 2ef867b..9e27012 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -15,3 +15,7 @@ config DRM_IMX_FB_HELPER
  The DRM framework can provide a legacy /dev/fb0 framebuffer
  for your device. This is necessary to get a framebuffer console
  and also for appplications using the legacy framebuffer API
+
+config DRM_IMX_PARALLEL_DISPLAY
+   tristate "Support for parallel displays"
+   depends on DRM_IMX
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index ff825f7..c8f582e 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -3,4 +3,5 @@ imxdrm-objs := imx-drm-core.o imx-fb.o

 obj-$(CONFIG_DRM_IMX) += imxdrm.o

+obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
new file mode 100644
index 000..9b51d73
--- /dev/null
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -0,0 +1,261 @@
+/*
+ * i.MX drm driver - parallel display implementation
+ *
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+
+#define con_to_imxpd(x) container_of(x, struct imx_parallel_display, connector)
+#define enc_to_imxpd(x) container_of(x, struct imx_parallel_display, encoder)
+
+struct imx_parallel_display {
+   struct drm_connector connector;
+   struct imx_drm_connector *imx_drm_connector;
+   struct drm_encoder encoder;
+   struct imx_drm_encoder *imx_drm_encoder;
+   struct device *dev;
+   void *edid;
+   int edid_len;
+   u32 interface_pix_fmt;
+   int mode_valid;
+   struct drm_display_mode mode;
+};
+
+static enum drm_connector_status imx_pd_connector_detect(
+   struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void imx_pd_connector_destroy(struct drm_connector *connector)
+{
+   /* do not free here */
+}
+
+static int imx_pd_connector_get_modes(struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+   int num_modes = 0;
+
+   if (imxpd->edid) {
+   drm_mode_connector_update_edid_property(connector, imxpd->edid);
+   num_modes = drm_add_edid_modes(connector, imxpd->edid);
+   }
+
+   if (imxpd->mode_valid) {
+   struct drm_display_mode *mode = drm_mode_create(connector->dev);
+   drm_mode_copy(mode, >mode);
+   mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+   drm_mode_probed_add(connector, mode);
+   num_modes++;
+   }
+
+   return num_modes;
+}
+
+static int imx_pd_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   return 0;
+}
+
+static struct drm_encoder *imx_pd_connector_best_encoder(
+   struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+
+   return >encoder;
+}
+
+static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+}
+
+static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void imx_pd_encoder_prepare(struct drm_encoder *encoder)
+{
+   struct imx_parallel_display *imxpd = enc_to_imxpd(encoder);
+
+   

[PATCH 1/6] staging: drm/imx: Add i.MX drm core support

2012-09-21 Thread Sascha Hauer
This patch adds the i.MX glue stuff between i.MX and drm.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   17 +
 drivers/staging/imx-drm/Makefile   |6 +
 drivers/staging/imx-drm/imx-drm-core.c |  882 
 drivers/staging/imx-drm/imx-drm.h  |   58 +++
 drivers/staging/imx-drm/imx-fb.c   |   47 ++
 drivers/staging/imx-drm/imx-fbdev.c|   74 +++
 8 files changed, 1087 insertions(+)
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 025d8c9..0f51a15 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -140,4 +140,6 @@ source "drivers/staging/silicom/Kconfig"

 source "drivers/staging/ced1401/Kconfig"

+source "drivers/staging/imx-drm/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 08e9667..f4b2bc4 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_OMAP_BANDGAP)+= omap-thermal/
 obj-$(CONFIG_ZCACHE2)  += ramster/
 obj-$(CONFIG_NET_VENDOR_SILICOM)   += silicom/
 obj-$(CONFIG_CED1401)  += ced1401/
+obj-$(CONFIG_DRM_IMX)  += imx-drm/
diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
new file mode 100644
index 000..2ef867b
--- /dev/null
+++ b/drivers/staging/imx-drm/Kconfig
@@ -0,0 +1,17 @@
+config DRM_IMX
+   tristate "DRM Support for Freescale i.MX"
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   depends on DRM && ARCH_MXC
+   help
+ enable i.MX graphics support
+
+config DRM_IMX_FB_HELPER
+   tristate "provide legacy framebuffer /dev/fb0"
+   select DRM_KMS_CMA_HELPER
+   depends on DRM_IMX
+   help
+ The DRM framework can provide a legacy /dev/fb0 framebuffer
+ for your device. This is necessary to get a framebuffer console
+ and also for appplications using the legacy framebuffer API
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
new file mode 100644
index 000..ff825f7
--- /dev/null
+++ b/drivers/staging/imx-drm/Makefile
@@ -0,0 +1,6 @@
+
+imxdrm-objs := imx-drm-core.o imx-fb.o
+
+obj-$(CONFIG_DRM_IMX) += imxdrm.o
+
+obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
new file mode 100644
index 000..225e835
--- /dev/null
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -0,0 +1,882 @@
+/*
+ * Freescale i.MX drm driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+
+#define MAX_CRTC   4
+
+struct crtc_cookie {
+   void *cookie;
+   int id;
+   struct list_head list;
+};
+
+struct imx_drm_device {
+   struct drm_device   *drm;
+   struct device   *dev;
+   struct list_headcrtc_list;
+   struct list_headencoder_list;
+   struct list_headconnector_list;
+   struct mutexmutex;
+   int references;
+   int pipes;
+   struct drm_fbdev_cma*fbhelper;
+};
+
+struct imx_drm_crtc {
+   struct drm_crtc *crtc;
+   struct list_headlist;
+   struct imx_drm_device   *imxdrm;
+   int pipe;
+   struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
+   struct module   *owner;
+   struct crtc_cookie  cookie;
+};
+
+struct imx_drm_encoder {
+   struct drm_encoder  *encoder;
+   struct list_headlist;
+   struct module   *owner;

[PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree

2012-09-21 Thread Sascha Hauer
The following adds the i.MX IPUv3 base and KMS driver to the staging
tree. The patches apply cleanly on next-20120921. Dave has merged the
missing helper functions, so this series has no further dependencies.

Greg, please apply this for staging.

Thanks,
  Sascha

The following changes since commit d2711cb78d2533e66d1172a917391502ce3ddd85:

  Add linux-next specific files for 20120921 (2012-09-21 16:51:19 +1000)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-ipu-staging

for you to fetch changes up to 2d1cf926a36f3e4ea71ea115df846d857e755efd:

  staging: drm/imx: Add TODO (2012-09-21 09:58:52 +0200)


Add support to the ARM i.MX5/6 IPUv3 to staging


Philipp Zabel (1):
  staging: drm/imx: Add devicetree binding documentation

Sascha Hauer (5):
  staging: drm/imx: Add i.MX drm core support
  staging: drm/imx: Add parallel display support
  staging: drm/imx: add i.MX IPUv3 base driver
  staging: drm/imx: Add i.MX IPUv3 crtc support
  staging: drm/imx: Add TODO

 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   35 +
 drivers/staging/imx-drm/Makefile   |9 +
 drivers/staging/imx-drm/TODO   |   22 +
 drivers/staging/imx-drm/imx-drm-core.c |  884 +++
 drivers/staging/imx-drm/imx-drm.h  |   58 +
 drivers/staging/imx-drm/imx-fb.c   |   47 +
 drivers/staging/imx-drm/imx-fbdev.c|   74 ++
 drivers/staging/imx-drm/ipu-v3/Makefile|3 +
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h|  318 ++
 drivers/staging/imx-drm/ipu-v3/ipu-common.c| 1143 
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|  372 +++
 drivers/staging/imx-drm/ipu-v3/ipu-di.c|  700 
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c  |  408 +++
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c|  336 ++
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h   |  206 
 drivers/staging/imx-drm/ipuv3-crtc.c   |  579 ++
 drivers/staging/imx-drm/parallel-display.c |  261 +
 20 files changed, 5499 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/TODO
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile
 create mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c
 create mode 100644 drivers/staging/imx-drm/parallel-display.c


[PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Stephen Warren
On 09/21/2012 01:22 AM, Inki Dae wrote:
> 2012/9/21 Stephen Warren :
>> On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
>>> This patch adds device tree based discovery support for exynos DRM-FIMD
>>> driver which includes driver modification to handle platform data in
>>> both the cases with DT and non-DT, Also adds the documentation for bindings.
>>
>>> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
>>> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
>> ...
>>> + - samsung,fimd-display: This property should specify the phandle of the
>>> +   display device node which holds the video interface timing with the
>>> +   below mentioned properties.
>>> +
>>> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
>>> + horizontal timing includes four parameters in the following order.
>>> +
>>> + - horizontal back porch (in number of lcd clocks)
>>> + - horizontal front porch (in number of lcd clocks)
>>> + - hsync pulse width (in number of lcd clocks)
>>> + - Display panels X resolution.
>>> +
>>> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
>>> + vertical timing includes four parameters in the following order.
>>> +
>>> + - vertical back porch (in number of lcd lines)
>>> + - vertical front porch (in number of lcd lines)
>>> + - vsync pulse width (in number of lcd clocks)
>>> + - Display panels Y resolution.
>>
>> Should this not use the new videomode timings that are under discussion at:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
>>
> 
> ok, I agree with you. then the videomode helper is going to be merged
> to mainline(3.6)? if so, this patch should be reworked based on the
> videomode helper.

I think the videomode helpers would be merged for 3.7 at the very
earliest; 3.6 is cooked already. Given there are still some comments on
the binding, perhaps it won't happen until 3.8, but it'd be best to ask
on that thread so that people more directly involved with the status can
answer.


[Bug 55172] Skybox misrendering (Unvanquished, texture compression enabled)

2012-09-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=55172

--- Comment #1 from Vadim Girlin  2012-09-21 09:59:15 UTC 
---
Created attachment 67489
  --> https://bugs.freedesktop.org/attachment.cgi?id=67489
[PATCH] st/mesa: don't use decompress_with_blit for cubemaps

Does this patch help?

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


[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support

2012-09-21 Thread Eric Nelson
Hi Sascha,

While testing against a video-enabled U-Boot on i.MX6, I found the issue
below.

On 09/21/2012 01:07 AM, Sascha Hauer wrote:
> This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
> driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
> board and the i.MX6q sabrelite board in different clone mode and dual
> head setups.
>
> Signed-off-by: Sascha Hauer
> ---
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -0,0 +1,579 @@
> +/*
> + * i.MX IPUv3 Graphics driver
> + *
 >
 > 
 >
> +static int ipu_get_resources(struct ipu_crtc *ipu_crtc,
> + struct ipu_client_platformdata *pdata)
> +{
> +
> + ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
> + IPU_IRQ_EOF);

Interrupts get enabled here

> + ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, ipu_irq_handler, 0,
> + "imx_drm", ipu_crtc);
> + if (ret<  0) {
> + dev_err(ipu_crtc->dev, "irq request failed with %d.\n", ret);
> + goto err_out;
> + }
> +
>
> 
>
> +
> +static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
> + struct ipu_client_platformdata *pdata)
> +{
> + int ret;
> +
> + ret = ipu_get_resources(ipu_crtc, pdata);
> + if (ret) {
> + dev_err(ipu_crtc->dev, "getting resources failed with %d.\n",
> + ret);
> + return ret;
> + }
> +

But ipu_crtc->imx_crtc gets initialized in this call, and
ipu_irq_handler() makes use of it.

The U-Boot code doesn't enable interrupts, so it's not acking
along the way, and leaves bits set in IPU1_INT_STAT_15.

I found that I can get around this in U-Boot by disabling the
LCD controller and acking all of the interrupts after disabling
the controller, but I haven't yet figured out where to tap into 
cleanup_before_linux().

Regards,


Eric


[PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree

2012-09-21 Thread Greg Kroah-Hartman
On Fri, Sep 21, 2012 at 10:07:46AM +0200, Sascha Hauer wrote:
> The following adds the i.MX IPUv3 base and KMS driver to the staging
> tree. The patches apply cleanly on next-20120921. Dave has merged the
> missing helper functions, so this series has no further dependencies.
> 
> Greg, please apply this for staging.

Nice job, all now applied to the staging-next tree.

greg k-h


[PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740

2012-09-21 Thread Josh Boyer
On Tue, Aug 28, 2012 at 4:50 PM,   wrote:
> From: Jerome Glisse 
>
> It seems some of those IGP dislike non dma32 page despite what
> documentation says. Fix regression since we allowed non dma32
> pages. It seems it only affect some revision of those IGP chips
> as we don't know which one just force dma32 for all of them.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=785375
>
> Signed-off-by: Jerome Glisse 
> Cc: 


This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f.  I
don't see it queued up in the stable-queue, so I thought I'd point it
out in case it was missed.

josh

> ---
>  drivers/gpu/drm/radeon/radeon_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 066c98b..8867400 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -774,7 +774,7 @@ int radeon_device_init(struct radeon_device *rdev,
> if (rdev->flags & RADEON_IS_AGP)
> rdev->need_dma32 = true;
> if ((rdev->flags & RADEON_IS_PCI) &&
> -   (rdev->family < CHIP_RS400))
> +   (rdev->family <= CHIP_RS740))
> rdev->need_dma32 = true;
>
> dma_bits = rdev->need_dma32 ? 32 : 40;
> --
> 1.7.11.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Bug 55172] New: Skybox misrendering (Unvanquished, texture compression enabled)

2012-09-21 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=55172

 Bug #: 55172
   Summary: Skybox misrendering (Unvanquished, texture compression
enabled)
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bugspam at moreofthesa.me.uk


The more distant parts of the skybox texture in maps such as atcshd are
misrendered in a consistent way if texture compression is enabled.

(Mesa git cf76edd, Linux 3.6-rc3, HD6770)

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


[PATCH v4] of: Add videomode helper

2012-09-21 Thread Laurent Pinchart
Hi,

(CC'ing the linux-media mailing list, as video modes are of interest there as 
well)

On Wednesday 19 September 2012 12:19:22 Tomi Valkeinen wrote:
> On Wed, 2012-09-19 at 10:20 +0200, Steffen Trumtrar wrote:
> > This patch adds a helper function for parsing videomodes from the
> > devicetree. The videomode can be either converted to a struct
> > drm_display_mode or a struct fb_videomode.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Steffen Trumtrar 
> > ---
> > 
> > Hi!
> > 
> > changes since v3:
> > - print error messages
> > - free alloced memory
> > - general cleanup
> > 
> > Regards
> > Steffen
> > 
> >  .../devicetree/bindings/video/displaymode  |   74 +
> >  drivers/of/Kconfig |5 +
> >  drivers/of/Makefile|1 +
> >  drivers/of/of_videomode.c  |  283 +++
> >  include/linux/of_videomode.h   |   56 
> >  5 files changed, 419 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/video/displaymode
> >  create mode 100644 drivers/of/of_videomode.c
> >  create mode 100644 include/linux/of_videomode.h
> > 
> > diff --git a/Documentation/devicetree/bindings/video/displaymode
> > b/Documentation/devicetree/bindings/video/displaymode new file mode
> > 100644
> > index 000..990ca52
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/displaymode
> > @@ -0,0 +1,74 @@
> > +videomode bindings
> > +==
> > +
> > +Required properties:
> > + - hactive, vactive: Display resolution
> > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
> > parameters
> > +   in pixels
> > +   vfront-porch, vback-porch, vsync-len: Vertical display timing
> > parameters in
> > +   lines
> > + - clock: displayclock in Hz
> > +
> > +Optional properties:
> > + - width-mm, height-mm: Display dimensions in mm
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
> > + - interlaced (bool): This is an interlaced mode
> > + - doublescan (bool): This is a doublescan mode
> > +
> > +There are different ways of describing a display mode. The devicetree
> > representation
> > +corresponds to the one commonly found in datasheets for displays.
> > +The description of the display and its mode is split in two parts: first
> > the display
> > +properties like size in mm and (optionally) multiple subnodes with the
> > supported modes.
> > +
> > +Example:
> > +
> > +   display at 0 {
> > +   width-mm = <800>;
> > +   height-mm = <480>;
> > +   modes {
> > +   mode0: mode at 0 {
> > +   /* 1920x1080p24 */
> > +   clock = <5200>;
> > +   hactive = <1920>;
> > +   vactive = <1080>;
> > +   hfront-porch = <25>;
> > +   hback-porch = <25>;
> > +   hsync-len = <25>;
> > +   vback-porch = <2>;
> > +   vfront-porch = <2>;
> > +   vsync-len = <2>;
> > +   hsync-active-high;
> > +   };
> > +   };
> > +   };
> > +
> > +Every property also supports the use of ranges, so the commonly used
> > datasheet +description with -tuples can be used.
> > +
> > +Example:
> > +
> > +   mode1: mode at 1 {
> > +   /* 1920x1080p24 */
> > +   clock = <14850>;
> > +   hactive = <1920>;
> > +   vactive = <1080>;
> > +   hsync-len = <0 44 60>;
> > +   hfront-porch = <80 88 95>;
> > +   hback-porch = <100 148 160>;
> > +   vfront-porch = <0 4 6>;
> > +   vback-porch = <0 36 50>;
> > +   vsync-len = <0 5 6>;
> > +   };
> > +
> > +The videomode can be linked to a connector via phandles. The connector
> > has to
> > +support the display- and default-mode-property to link to and select a
> > mode.
> > +
> > +Example:
> > +
> > +   hdmi at 0012 {
> > +   status = "okay";
> > +   display = <>;
> > +   default-mode = <>;
> > +   };
> > +
> > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > index dfba3e6..a3acaa3 100644
> > --- a/drivers/of/Kconfig
> > +++ b/drivers/of/Kconfig
> > @@ -83,4 +83,9 @@ config OF_MTD
> > 
> > depends on MTD
> > def_bool y
> > 
> > +config OF_VIDEOMODE
> > +   def_bool y
> > +   help
> > + helper to parse videomodes from the devicetree
> > +
> > 
> >  endmenu # OF
> > 
> > diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> > index e027f44..80e6db3 100644
> > --- a/drivers/of/Makefile
> > +++ b/drivers/of/Makefile
> > @@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
> > 
> >  obj-$(CONFIG_OF_PCI)   += of_pci.o
> >  obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
> >  obj-$(CONFIG_OF_MTD)   += 

[PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Stephen Warren
On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
> This patch adds device tree based discovery support for exynos DRM-FIMD
> driver which includes driver modification to handle platform data in
> both the cases with DT and non-DT, Also adds the documentation for bindings.

> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
...
> + - samsung,fimd-display: This property should specify the phandle of the
> +   display device node which holds the video interface timing with the
> +   below mentioned properties.
> +
> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
> + horizontal timing includes four parameters in the following order.
> +
> + - horizontal back porch (in number of lcd clocks)
> + - horizontal front porch (in number of lcd clocks)
> + - hsync pulse width (in number of lcd clocks)
> + - Display panels X resolution.
> +
> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
> + vertical timing includes four parameters in the following order.
> +
> + - vertical back porch (in number of lcd lines)
> + - vertical front porch (in number of lcd lines)
> + - vsync pulse width (in number of lcd clocks)
> + - Display panels Y resolution.

Should this not use the new videomode timings that are under discussion at:

http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html


Re: [PATCH] drm/exynos: Fix potential NULL pointer dereference

2012-09-21 Thread Inki Dae
Applied.

Thanks,
Inki Dae

2012/9/18 Sachin Kamat sachin.ka...@linaro.org:
 drm_mode_create() returns NULL if it fails to create
 a new display mode. Check the value returned to avoid NULL
 pointer deferencing later.

 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  drivers/gpu/drm/exynos/exynos_drm_connector.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
 b/drivers/gpu/drm/exynos/exynos_drm_connector.c
 index 9dce3b9..485e984 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
 @@ -149,8 +149,12 @@ static int exynos_drm_connector_get_modes(struct 
 drm_connector *connector)
 count = drm_add_edid_modes(connector, edid);
 kfree(edid);
 } else {
 -   struct drm_display_mode *mode = 
 drm_mode_create(connector-dev);
 struct exynos_drm_panel_info *panel;
 +   struct drm_display_mode *mode = 
 drm_mode_create(connector-dev);
 +   if (!mode) {
 +   DRM_ERROR(failed to create a new display mode.\n);
 +   return 0;
 +   }

 if (display_ops-get_panel)
 panel = display_ops-get_panel(manager-dev);
 --
 1.7.4.1

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


Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Inki Dae
2012/9/21 Stephen Warren swar...@wwwdotorg.org:
 On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
 This patch adds device tree based discovery support for exynos DRM-FIMD
 driver which includes driver modification to handle platform data in
 both the cases with DT and non-DT, Also adds the documentation for bindings.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
 b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
 ...
 + - samsung,fimd-display: This property should specify the phandle of the
 +   display device node which holds the video interface timing with the
 +   below mentioned properties.
 +
 +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
 + horizontal timing includes four parameters in the following order.
 +
 + - horizontal back porch (in number of lcd clocks)
 + - horizontal front porch (in number of lcd clocks)
 + - hsync pulse width (in number of lcd clocks)
 + - Display panels X resolution.
 +
 +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
 + vertical timing includes four parameters in the following order.
 +
 + - vertical back porch (in number of lcd lines)
 + - vertical front porch (in number of lcd lines)
 + - vsync pulse width (in number of lcd clocks)
 + - Display panels Y resolution.

 Should this not use the new videomode timings that are under discussion at:

 http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html


ok, I agree with you. then the videomode helper is going to be merged
to mainline(3.6)? if so, this patch should be reworked based on the
videomode helper.


 ___
 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


[PATCH V6 0/2] video: drm: Add Device tree support to exynos DRM-FIMD

2012-09-21 Thread Leela Krishna Amudala
This patch set adds device tree support for DRM-FIMD for Samsung's Exynos5250.
It includes parsing platform data from dts file. Also, adds the driver data
for exynos4 and exynos5 devices.

This patchset is based and tested on top of v3.6-rc4 on smdk5250 board
Also depends on below patchset
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html

Changes since V5:
- Moved the documentation file to appropriate location.
- Given more description in the commit message to the patch 
  video: drm: exynos: Add device tree support

Changes since V4:
- Changed the compatible string from samsung,exynos4-fb to
  samsung,exynos4-fimd.

Changes since V3:
- Removed the fimd version from driver data and using timing base
  address instead
- Removed the drm_ prefixes to the structures and fucntions

Changes since V2:
- Added driver data to exynos5-drm-fimd as per Marek Szyprowski 
suggestion

Changes since V1:
- Corrected typo errors and changed compatibility string

Leela Krishna Amudala (2):
  drm/exynos: add platform_device_id table and driver data for drm fimd
  video: drm: exynos: Add device tree support

 .../devicetree/bindings/drm/exynos/fimd.txt|   80 +++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  138 +++-
 2 files changed, 212 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/exynos/fimd.txt

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


[PATCH V6 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd

2012-09-21 Thread Leela Krishna Amudala
Two device ids are created for exynos4-fb and exynos5-fb.
Also, added driver data for exynos4 and exynos5 to pick the timing base address
at runtime to write data into appropriate register address.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   43 +++---
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index d96db5e..1ad10b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -57,6 +57,18 @@
 
 #define get_fimd_context(dev)  platform_get_drvdata(to_platform_device(dev))
 
+struct fimd_driver_data {
+   unsigned int timing_base;
+};
+
+struct fimd_driver_data exynos4_fimd_driver_data = {
+   .timing_base = 0x0,
+};
+
+struct fimd_driver_data exynos5_fimd_driver_data = {
+   .timing_base = 0x2,
+};
+
 struct fimd_win_data {
unsigned intoffset_x;
unsigned intoffset_y;
@@ -91,6 +103,13 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };
 
+static inline struct fimd_driver_data *drm_fimd_get_driver_data(
+   struct platform_device *pdev)
+{
+   return (struct fimd_driver_data *)
+   platform_get_device_id(pdev)-driver_data;
+}
+
 static bool fimd_display_is_connected(struct device *dev)
 {
DRM_DEBUG_KMS(%s\n, __FILE__);
@@ -194,32 +213,35 @@ static void fimd_commit(struct device *dev)
struct fimd_context *ctx = get_fimd_context(dev);
struct exynos_drm_panel_info *panel = ctx-panel;
struct fb_videomode *timing = panel-timing;
+   struct fimd_driver_data *driver_data;
+   struct platform_device *pdev = to_platform_device(dev);
u32 val;
 
+   driver_data = drm_fimd_get_driver_data(pdev);
if (ctx-suspended)
return;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
/* setup polarity values from machine code. */
-   writel(ctx-vidcon1, ctx-regs + VIDCON1);
+   writel(ctx-vidcon1, ctx-regs + driver_data-timing_base + VIDCON1);
 
/* setup vertical timing values. */
val = VIDTCON0_VBPD(timing-upper_margin - 1) |
   VIDTCON0_VFPD(timing-lower_margin - 1) |
   VIDTCON0_VSPW(timing-vsync_len - 1);
-   writel(val, ctx-regs + VIDTCON0);
+   writel(val, ctx-regs + driver_data-timing_base + VIDTCON0);
 
/* setup horizontal timing values.  */
val = VIDTCON1_HBPD(timing-left_margin - 1) |
   VIDTCON1_HFPD(timing-right_margin - 1) |
   VIDTCON1_HSPW(timing-hsync_len - 1);
-   writel(val, ctx-regs + VIDTCON1);
+   writel(val, ctx-regs + driver_data-timing_base + VIDTCON1);
 
/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing-yres - 1) |
   VIDTCON2_HOZVAL(timing-xres - 1);
-   writel(val, ctx-regs + VIDTCON2);
+   writel(val, ctx-regs + driver_data-timing_base + VIDTCON2);
 
/* setup clock source, clock divider, enable dma. */
val = ctx-vidcon0;
@@ -977,6 +999,18 @@ static int fimd_runtime_resume(struct device *dev)
 }
 #endif
 
+static struct platform_device_id fimd_driver_ids[] = {
+   {
+   .name   = exynos4-fb,
+   .driver_data= (unsigned long)exynos4_fimd_driver_data,
+   }, {
+   .name   = exynos5-fb,
+   .driver_data= (unsigned long)exynos5_fimd_driver_data,
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(platform, fimd_driver_ids);
+
 static const struct dev_pm_ops fimd_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
@@ -985,6 +1019,7 @@ static const struct dev_pm_ops fimd_pm_ops = {
 struct platform_driver fimd_driver = {
.probe  = fimd_probe,
.remove = __devexit_p(fimd_remove),
+   .id_table   = fimd_driver_ids,
.driver = {
.name   = exynos4-fb,
.owner  = THIS_MODULE,
-- 
1.7.0.4

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


[PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Leela Krishna Amudala
This patch adds device tree based discovery support for exynos DRM-FIMD
driver which includes driver modification to handle platform data in
both the cases with DT and non-DT, Also adds the documentation for bindings.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 .../devicetree/bindings/drm/exynos/fimd.txt|   80 
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   95 +++-
 2 files changed, 173 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/exynos/fimd.txt

diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
new file mode 100644
index 000..e94120c
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
@@ -0,0 +1,80 @@
+* Samsung Display Controller using DRM frame work
+
+The display controller is used to transfer image data from memory to an
+external LCD driver interface. It supports various color formats such as
+rgb and yuv.
+
+Required properties:
+ - compatible: Should be samsung,exynos5-fimd or samsung,exynos4-fimd for
+   fimd using DRM frame work.
+ - reg: physical base address of the controller and length of memory
+   mapped region.
+ - interrupts: Three interrupts should be specified. The interrupts should be
+   specified in the following order.
+   - VSYNC interrupt
+   - FIFO level interrupt
+   - FIMD System Interrupt
+
+ - samsung,fimd-display: This property should specify the phandle of the
+   display device node which holds the video interface timing with the
+   below mentioned properties.
+
+   - lcd-htiming: Specifies the horizontal timing for the overlay. The
+ horizontal timing includes four parameters in the following order.
+
+ - horizontal back porch (in number of lcd clocks)
+ - horizontal front porch (in number of lcd clocks)
+ - hsync pulse width (in number of lcd clocks)
+ - Display panels X resolution.
+
+   - lcd-vtiming: Specifies the vertical timing for the overlay. The
+ vertical timing includes four parameters in the following order.
+
+ - vertical back porch (in number of lcd lines)
+ - vertical front porch (in number of lcd lines)
+ - vsync pulse width (in number of lcd clocks)
+ - Display panels Y resolution.
+
+
+ - samsung,default-window: Specifies the default window number of the fimd 
controller.
+
+ - samsung,fimd-win-bpp: Specifies the bits per pixel.
+
+Optional properties:
+ - samsung,fimd-vidout-rgb: Video output format is RGB.
+ - samsung,fimd-inv-vclk: invert video clock polarity.
+ - samsung,fimd-frame-rate: Number of video frames per second.
+
+Example:
+
+   The following is an example for the fimd controller is split into
+   two portions. The SoC specific portion can be specified in the SoC
+   specific dts file. The board specific portion can be specified in the
+   board specific dts file.
+
+   - SoC Specific portion
+
+   fimd {
+   compatible = samsung,exynos5-fimd;
+   interrupt-parent = combiner;
+   reg = 0x1440 0x4;
+   interrupts = 18 5, 18 4, 18 6;
+   };
+
+   - Board Specific portion
+
+   lcd_fimd0: lcd_panel0 {
+   lcd-htiming = 4 4 4 480;
+   lcd-vtiming = 4 4 4 320;
+   supports-mipi-panel;
+   };
+
+   fimd {
+   samsung,fimd-display = lcd_fimd0;
+   samsung,fimd-vidout-rgb;
+   samsung,fimd-inv-vclk;
+   samsung,fimd-frame-rate = 60;
+   samsung,default-window = 0;
+   samsung,fimd-win-bpp = 32;
+   };
+
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1ad10b6..b2d22ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -18,6 +18,7 @@
 #include linux/platform_device.h
 #include linux/clk.h
 #include linux/pm_runtime.h
+#include linux/of.h
 
 #include video/samsung_fimd.h
 #include drm/exynos_drm.h
@@ -103,9 +104,18 @@ struct fimd_context {
struct exynos_drm_panel_info *panel;
 };
 
+static const struct of_device_id fimd_dt_match[];
+
 static inline struct fimd_driver_data *drm_fimd_get_driver_data(
struct platform_device *pdev)
 {
+#ifdef CONFIG_OF
+   if (pdev-dev.of_node) {
+   const struct of_device_id *match;
+   match = of_match_ptr(fimd_dt_match);
+   return (struct fimd_driver_data *)match-data;
+   }
+#endif
return (struct fimd_driver_data *)
platform_get_device_id(pdev)-driver_data;
 }
@@ -809,12 +819,77 @@ static int fimd_power_on(struct fimd_context *ctx, bool 
enable)
return 0;
 }
 
+#ifdef CONFIG_OF
+static struct exynos_drm_fimd_pdata *drm_fimd_dt_parse_pdata(struct device 
*dev)
+{
+   struct device_node *np = dev-of_node;
+   struct device_node 

Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Stephen Warren
On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
 This patch adds device tree based discovery support for exynos DRM-FIMD
 driver which includes driver modification to handle platform data in
 both the cases with DT and non-DT, Also adds the documentation for bindings.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
 b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
...
 + - samsung,fimd-display: This property should specify the phandle of the
 +   display device node which holds the video interface timing with the
 +   below mentioned properties.
 +
 +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
 + horizontal timing includes four parameters in the following order.
 +
 + - horizontal back porch (in number of lcd clocks)
 + - horizontal front porch (in number of lcd clocks)
 + - hsync pulse width (in number of lcd clocks)
 + - Display panels X resolution.
 +
 +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
 + vertical timing includes four parameters in the following order.
 +
 + - vertical back porch (in number of lcd lines)
 + - vertical front porch (in number of lcd lines)
 + - vsync pulse width (in number of lcd clocks)
 + - Display panels Y resolution.

Should this not use the new videomode timings that are under discussion at:

http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree

2012-09-21 Thread Sascha Hauer
The following adds the i.MX IPUv3 base and KMS driver to the staging
tree. The patches apply cleanly on next-20120921. Dave has merged the
missing helper functions, so this series has no further dependencies.

Greg, please apply this for staging.

Thanks,
  Sascha

The following changes since commit d2711cb78d2533e66d1172a917391502ce3ddd85:

  Add linux-next specific files for 20120921 (2012-09-21 16:51:19 +1000)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-ipu-staging

for you to fetch changes up to 2d1cf926a36f3e4ea71ea115df846d857e755efd:

  staging: drm/imx: Add TODO (2012-09-21 09:58:52 +0200)


Add support to the ARM i.MX5/6 IPUv3 to staging


Philipp Zabel (1):
  staging: drm/imx: Add devicetree binding documentation

Sascha Hauer (5):
  staging: drm/imx: Add i.MX drm core support
  staging: drm/imx: Add parallel display support
  staging: drm/imx: add i.MX IPUv3 base driver
  staging: drm/imx: Add i.MX IPUv3 crtc support
  staging: drm/imx: Add TODO

 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   35 +
 drivers/staging/imx-drm/Makefile   |9 +
 drivers/staging/imx-drm/TODO   |   22 +
 drivers/staging/imx-drm/imx-drm-core.c |  884 +++
 drivers/staging/imx-drm/imx-drm.h  |   58 +
 drivers/staging/imx-drm/imx-fb.c   |   47 +
 drivers/staging/imx-drm/imx-fbdev.c|   74 ++
 drivers/staging/imx-drm/ipu-v3/Makefile|3 +
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h|  318 ++
 drivers/staging/imx-drm/ipu-v3/ipu-common.c| 1143 
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|  372 +++
 drivers/staging/imx-drm/ipu-v3/ipu-di.c|  700 
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c  |  408 +++
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c|  336 ++
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h   |  206 
 drivers/staging/imx-drm/ipuv3-crtc.c   |  579 ++
 drivers/staging/imx-drm/parallel-display.c |  261 +
 20 files changed, 5499 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/TODO
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile
 create mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c
 create mode 100644 drivers/staging/imx-drm/parallel-display.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/6] staging: drm/imx: Add parallel display support

2012-09-21 Thread Sascha Hauer
This adds support for parallel displays for i.MX. It consists
of a drm encoder/connector pair which eventually passes EDID
data from the devicetree to the drm core.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/imx-drm/Kconfig|4 +
 drivers/staging/imx-drm/Makefile   |1 +
 drivers/staging/imx-drm/parallel-display.c |  261 
 3 files changed, 266 insertions(+)
 create mode 100644 drivers/staging/imx-drm/parallel-display.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 2ef867b..9e27012 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -15,3 +15,7 @@ config DRM_IMX_FB_HELPER
  The DRM framework can provide a legacy /dev/fb0 framebuffer
  for your device. This is necessary to get a framebuffer console
  and also for appplications using the legacy framebuffer API
+
+config DRM_IMX_PARALLEL_DISPLAY
+   tristate Support for parallel displays
+   depends on DRM_IMX
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index ff825f7..c8f582e 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -3,4 +3,5 @@ imxdrm-objs := imx-drm-core.o imx-fb.o
 
 obj-$(CONFIG_DRM_IMX) += imxdrm.o
 
+obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
new file mode 100644
index 000..9b51d73
--- /dev/null
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -0,0 +1,261 @@
+/*
+ * i.MX drm driver - parallel display implementation
+ *
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include linux/module.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/videodev2.h
+
+#include imx-drm.h
+
+#define con_to_imxpd(x) container_of(x, struct imx_parallel_display, connector)
+#define enc_to_imxpd(x) container_of(x, struct imx_parallel_display, encoder)
+
+struct imx_parallel_display {
+   struct drm_connector connector;
+   struct imx_drm_connector *imx_drm_connector;
+   struct drm_encoder encoder;
+   struct imx_drm_encoder *imx_drm_encoder;
+   struct device *dev;
+   void *edid;
+   int edid_len;
+   u32 interface_pix_fmt;
+   int mode_valid;
+   struct drm_display_mode mode;
+};
+
+static enum drm_connector_status imx_pd_connector_detect(
+   struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void imx_pd_connector_destroy(struct drm_connector *connector)
+{
+   /* do not free here */
+}
+
+static int imx_pd_connector_get_modes(struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+   int num_modes = 0;
+
+   if (imxpd-edid) {
+   drm_mode_connector_update_edid_property(connector, imxpd-edid);
+   num_modes = drm_add_edid_modes(connector, imxpd-edid);
+   }
+
+   if (imxpd-mode_valid) {
+   struct drm_display_mode *mode = drm_mode_create(connector-dev);
+   drm_mode_copy(mode, imxpd-mode);
+   mode-type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+   drm_mode_probed_add(connector, mode);
+   num_modes++;
+   }
+
+   return num_modes;
+}
+
+static int imx_pd_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   return 0;
+}
+
+static struct drm_encoder *imx_pd_connector_best_encoder(
+   struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+
+   return imxpd-encoder;
+}
+
+static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+}
+
+static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void imx_pd_encoder_prepare(struct drm_encoder *encoder)
+{
+   

[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support

2012-09-21 Thread Sascha Hauer
This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
board and the i.MX6q sabrelite board in different clone mode and dual
head setups.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/imx-drm/Kconfig  |6 +
 drivers/staging/imx-drm/Makefile |1 +
 drivers/staging/imx-drm/ipuv3-crtc.c |  579 ++
 3 files changed, 586 insertions(+)
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 4849bfa..14b4449 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -27,3 +27,9 @@ config DRM_IMX_IPUV3_CORE
  Choose this if you have a i.MX5/6 system and want
  to use the IPU. This option only enables IPU base
  support.
+
+config DRM_IMX_IPUV3
+   tristate DRM Support for i.MX IPUv3
+   depends on DRM_IMX
+   help
+ Choose this if you have a i.MX5 or i.MX6 processor.
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index e3a5b6f..83a9056 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRM_IMX) += imxdrm.o
 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
 obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
+obj-$(CONFIG_DRM_IMX_IPUV3)+= ipuv3-crtc.o
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
new file mode 100644
index 000..78d3eda
--- /dev/null
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -0,0 +1,579 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include linux/module.h
+#include linux/export.h
+#include linux/device.h
+#include linux/platform_device.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/fb.h
+#include linux/clk.h
+#include drm/drm_gem_cma_helper.h
+#include drm/drm_fb_cma_helper.h
+
+#include ipu-v3/imx-ipu-v3.h
+#include imx-drm.h
+
+#define DRIVER_DESCi.MX IPUv3 Graphics
+
+struct ipu_framebuffer {
+   struct drm_framebuffer  base;
+   void*virt;
+   dma_addr_t  phys;
+   size_t  len;
+};
+
+struct ipu_crtc {
+   struct drm_fb_helperfb_helper;
+   struct ipu_framebuffer  ifb;
+   int num_crtcs;
+   struct device   *dev;
+   struct drm_crtc base;
+   struct imx_drm_crtc *imx_crtc;
+   struct ipuv3_channel*ipu_ch;
+   struct ipu_dc   *dc;
+   struct ipu_dp   *dp;
+   struct dmfc_channel *dmfc;
+   struct ipu_di   *di;
+   int enabled;
+   struct ipu_priv *ipu_priv;
+   struct drm_pending_vblank_event *page_flip_event;
+   struct drm_framebuffer  *newfb;
+   int irq;
+   u32 interface_pix_fmt;
+   unsigned long   di_clkflags;
+};
+
+#define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)
+
+static int calc_vref(struct drm_display_mode *mode)
+{
+   unsigned long htotal, vtotal;
+
+   htotal = mode-htotal;
+   vtotal = mode-vtotal;
+
+   if (!htotal || !vtotal)
+   return 60;
+
+   return mode-clock * 1000 / vtotal / htotal;
+}
+
+static int calc_bandwidth(struct drm_display_mode *mode, unsigned int vref)
+{
+   return mode-hdisplay * mode-vdisplay * vref;
+}
+
+static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
+{
+   if (ipu_crtc-enabled)
+   return;
+
+   ipu_di_enable(ipu_crtc-di);
+   ipu_dmfc_enable_channel(ipu_crtc-dmfc);
+   ipu_idmac_enable_channel(ipu_crtc-ipu_ch);
+   ipu_dc_enable_channel(ipu_crtc-dc);
+   if (ipu_crtc-dp)
+   ipu_dp_enable_channel(ipu_crtc-dp);
+
+   ipu_crtc-enabled = 1;
+}
+
+static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
+{
+   if (!ipu_crtc-enabled)
+   return;
+
+   if (ipu_crtc-dp)
+   

[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation

2012-09-21 Thread Sascha Hauer
From: Philipp Zabel p.za...@pengutronix.de

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
new file mode 100644
index 000..07654f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -0,0 +1,41 @@
+Freescale i.MX IPUv3
+
+
+Required properties:
+- compatible: Should be fsl,chip-ipu
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain sync interrupt and error interrupt,
+  in this order.
+- #crtc-cells: 1, See below
+
+example:
+
+ipu: ipu@1800 {
+   #crtc-cells = 1;
+   compatible = fsl,imx53-ipu;
+   reg = 0x1800 0x08000;
+   interrupts = 11 10;
+};
+
+Parallel display support
+
+
+Required properties:
+- compatible: Should be fsl,imx-parallel-display
+- crtc: the crtc this display is connected to, see below
+Optional properties:
+- interface_pix_fmt: How this display is connected to the
+  crtc. Currently supported types: rgb24, rgb565
+- edid: verbatim EDID data block describing attached display.
+- ddc: phandle describing the i2c bus handling the display data
+  channel
+
+example:
+
+display@di0 {
+   compatible = fsl,imx-parallel-display;
+   edid = [edid-data];
+   crtc = ipu 0;
+   interface-pix-fmt = rgb24;
+};
-- 
1.7.10.4

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


[PATCH 6/6] staging: drm/imx: Add TODO

2012-09-21 Thread Sascha Hauer
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/imx-drm/TODO |   22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 drivers/staging/imx-drm/TODO

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
new file mode 100644
index 000..e52adc4
--- /dev/null
+++ b/drivers/staging/imx-drm/TODO
@@ -0,0 +1,22 @@
+TODO:
+- get DRM Maintainer review for this code
+- Factor out more code to common helper functions
+- decide where to put the base driver. It is not specific to a subsystem
+  and would be used by DRM/KMS and media/V4L2
+- convert irq driver to irq_domain_add_linear
+
+Missing features (not necessarily for moving out of staging):
+
+- Add KMS plane support for CRTC driver
+- Add LDB (LVDS Display Bridge) support
+- Add i.MX6 HDMI support
+- Add support for IC (Image converter)
+- Add support for CSI (CMOS Sensor interface)
+- Add support for VDIC (Video Deinterlacer)
+
+Many work-in-progress patches for the above features exist. Contact
+Sascha Hauer ker...@pengutronix.de if you are interested in working
+on a specific feature.
+
+Please send any patches to Greg Kroah-Hartman gre...@linuxfoundation.org and
+Sascha Hauer ker...@pengutronix.de
-- 
1.7.10.4

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


[PATCH 1/6] staging: drm/imx: Add i.MX drm core support

2012-09-21 Thread Sascha Hauer
This patch adds the i.MX glue stuff between i.MX and drm.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   17 +
 drivers/staging/imx-drm/Makefile   |6 +
 drivers/staging/imx-drm/imx-drm-core.c |  882 
 drivers/staging/imx-drm/imx-drm.h  |   58 +++
 drivers/staging/imx-drm/imx-fb.c   |   47 ++
 drivers/staging/imx-drm/imx-fbdev.c|   74 +++
 8 files changed, 1087 insertions(+)
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 025d8c9..0f51a15 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -140,4 +140,6 @@ source drivers/staging/silicom/Kconfig
 
 source drivers/staging/ced1401/Kconfig
 
+source drivers/staging/imx-drm/Kconfig
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 08e9667..f4b2bc4 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_OMAP_BANDGAP)+= omap-thermal/
 obj-$(CONFIG_ZCACHE2)  += ramster/
 obj-$(CONFIG_NET_VENDOR_SILICOM)   += silicom/
 obj-$(CONFIG_CED1401)  += ced1401/
+obj-$(CONFIG_DRM_IMX)  += imx-drm/
diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
new file mode 100644
index 000..2ef867b
--- /dev/null
+++ b/drivers/staging/imx-drm/Kconfig
@@ -0,0 +1,17 @@
+config DRM_IMX
+   tristate DRM Support for Freescale i.MX
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   depends on DRM  ARCH_MXC
+   help
+ enable i.MX graphics support
+
+config DRM_IMX_FB_HELPER
+   tristate provide legacy framebuffer /dev/fb0
+   select DRM_KMS_CMA_HELPER
+   depends on DRM_IMX
+   help
+ The DRM framework can provide a legacy /dev/fb0 framebuffer
+ for your device. This is necessary to get a framebuffer console
+ and also for appplications using the legacy framebuffer API
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
new file mode 100644
index 000..ff825f7
--- /dev/null
+++ b/drivers/staging/imx-drm/Makefile
@@ -0,0 +1,6 @@
+
+imxdrm-objs := imx-drm-core.o imx-fb.o
+
+obj-$(CONFIG_DRM_IMX) += imxdrm.o
+
+obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
new file mode 100644
index 000..225e835
--- /dev/null
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -0,0 +1,882 @@
+/*
+ * Freescale i.MX drm driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/device.h
+#include linux/platform_device.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/fb.h
+#include linux/module.h
+#include drm/drm_gem_cma_helper.h
+#include drm/drm_fb_cma_helper.h
+
+#include imx-drm.h
+
+#define MAX_CRTC   4
+
+struct crtc_cookie {
+   void *cookie;
+   int id;
+   struct list_head list;
+};
+
+struct imx_drm_device {
+   struct drm_device   *drm;
+   struct device   *dev;
+   struct list_headcrtc_list;
+   struct list_headencoder_list;
+   struct list_headconnector_list;
+   struct mutexmutex;
+   int references;
+   int pipes;
+   struct drm_fbdev_cma*fbhelper;
+};
+
+struct imx_drm_crtc {
+   struct drm_crtc *crtc;
+   struct list_headlist;
+   struct imx_drm_device   *imxdrm;
+   int pipe;
+   struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
+   struct module   *owner;
+   struct crtc_cookie  cookie;
+};
+
+struct imx_drm_encoder {

Re: FOSDEM2013: DevRoom or not?

2012-09-21 Thread Luc Verhaegen
On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote:
 Hi,
 
 The FOSDEM organizers have sent out a call for devrooms. FOSDEM this 
 year is on the weekend of the 2nd and 3rd of February 2013.
 
 After the success of this formula last year, where, for the first time 
 ever, we had a properly filled devroom schedule when the deadline hit, i 
 am going to re-apply the same formula:
 * By the 28th of september, i need 6 committed speakers, otherwise i 
   will not apply for a DevRoom. 6 people need to apply for a talk slot 
   who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. 
   This definitely means:
 * Don't knowingly plan anything else for this weekend.
 * Come to FOSDEM even if your corporation does not fund you (though 
   feel free to contact the board individually for funding)
 * Make sure that you are allowed to travel to the shengen area in 
   february.
 * Catastrophies excluded of course. Such catastrophies include 
   things like train-derailments and such, but explicitely excludes 
   hangovers :p
 * Scheduling based on timeliness of application: the earlier you apply, 
   the better slot you get.
 * FOSDEMs final deadline for the full schedule is likely around 15th of 
   january 2013. But do not count on that deadline, we will only do 
   hourly slots, to keep people from running around between devrooms like 
   headless chickens. Only 12-16 slots will be available, first come, 
   first serve.
 
 I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 
 
 I hope we get a nice devroom like we had last time. That new building we 
 were in was really amazing, even though it took a while before all 
 FOSDEM visitors found it.
 
 Thanks,
 
 Luc Verhaegen.

Just a heads up guys, we have a week left and not a single speaker yet!

Given the timing of XDC and the FOSDEM deadines, this is not too 
surprising, but still, with XDC2012 in its final day it is high time 
that we start thinking about FOSDEM. I will later on shout at people 
here in the room too :)

All we need now is people who will definitely come to FOSDEM, and who 
are willing to talk in the DevRoom. If a vague idea of a topic is 
already known, then great, but this is not necessary yet. I now put up a 
preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the 
list there.

Thanks,

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


[Bug 55172] Skybox misrendering (Unvanquished, texture compression enabled)

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55172

--- Comment #1 from Vadim Girlin pt...@yandex.ru 2012-09-21 09:59:15 UTC ---
Created attachment 67489
  -- https://bugs.freedesktop.org/attachment.cgi?id=67489
[PATCH] st/mesa: don't use decompress_with_blit for cubemaps

Does this patch help?

-- 
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 v4] of: Add videomode helper

2012-09-21 Thread Hans Verkuil
On Wed September 19 2012 10:20:43 Steffen Trumtrar wrote:
 This patch adds a helper function for parsing videomodes from the devicetree.
 The videomode can be either converted to a struct drm_display_mode or a
 struct fb_videomode.
 
 Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
 Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
 ---
 
 Hi!
 
 changes since v3:
   - print error messages
   - free alloced memory
   - general cleanup
 
 Regards
 Steffen
 
  .../devicetree/bindings/video/displaymode  |   74 +
  drivers/of/Kconfig |5 +
  drivers/of/Makefile|1 +
  drivers/of/of_videomode.c  |  283 
 
  include/linux/of_videomode.h   |   56 
  5 files changed, 419 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/video/displaymode
  create mode 100644 drivers/of/of_videomode.c
  create mode 100644 include/linux/of_videomode.h
 
 diff --git a/Documentation/devicetree/bindings/video/displaymode 
 b/Documentation/devicetree/bindings/video/displaymode
 new file mode 100644
 index 000..990ca52
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/video/displaymode
 @@ -0,0 +1,74 @@
 +videomode bindings
 +==
 +
 +Required properties:
 + - hactive, vactive: Display resolution
 + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
 +   in pixels
 +   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters 
 in
 +   lines

In the case of interlaced formats, can the vfront-porch, vback-porch and 
vsync-len
for the second field always be calculated from these values? Is that fully
standardized or can there be exceptions? struct v4l2_bt_timings has separate 
fields
for these, but that may have been overkill.

 + - clock: displayclock in Hz

CEA-861 defined the option to slightly lower the clock frequency by 1.000/1.001 
to
achieve frequencies like 29.97 or 59.94. In v4l2_bt_timings I made a flag for 
that.
I'm not sure whether it is better to just set the clock to the correct frequency
(which is a weird value) or mark it with a bool.

 +
 +Optional properties:
 + - width-mm, height-mm: Display dimensions in mm
 + - hsync-active-high (bool): Hsync pulse is active high
 + - vsync-active-high (bool): Vsync pulse is active high
 + - interlaced (bool): This is an interlaced mode
 + - doublescan (bool): This is a doublescan mode
 +
 +There are different ways of describing a display mode. The devicetree 
 representation
 +corresponds to the one commonly found in datasheets for displays.
 +The description of the display and its mode is split in two parts: first the 
 display
 +properties like size in mm and (optionally) multiple subnodes with the 
 supported modes.
 +
 +Example:
 +
 + display@0 {
 + width-mm = 800;
 + height-mm = 480;
 + modes {
 + mode0: mode@0 {
 + /* 1920x1080p24 */
 + clock = 5200;
 + hactive = 1920;
 + vactive = 1080;
 + hfront-porch = 25;
 + hback-porch = 25;
 + hsync-len = 25;
 + vback-porch = 2;
 + vfront-porch = 2;
 + vsync-len = 2;
 + hsync-active-high;
 + };
 + };
 + };
 +
 +Every property also supports the use of ranges, so the commonly used 
 datasheet
 +description with min typ max-tuples can be used.
 +
 +Example:
 +
 + mode1: mode@1 {
 + /* 1920x1080p24 */
 + clock = 14850;
 + hactive = 1920;
 + vactive = 1080;
 + hsync-len = 0 44 60;
 + hfront-porch = 80 88 95;
 + hback-porch = 100 148 160;
 + vfront-porch = 0 4 6;
 + vback-porch = 0 36 50;
 + vsync-len = 0 5 6;
 + };
 +
 +The videomode can be linked to a connector via phandles. The connector has to
 +support the display- and default-mode-property to link to and select a mode.
 +
 +Example:
 +
 + hdmi@0012 {
 + status = okay;
 + display = benq;
 + default-mode = mode1;
 + };
 +
 diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
 index dfba3e6..a3acaa3 100644
 --- a/drivers/of/Kconfig
 +++ b/drivers/of/Kconfig
 @@ -83,4 +83,9 @@ config OF_MTD
   depends on MTD
   def_bool y
  
 +config OF_VIDEOMODE
 + def_bool y
 + help
 +   helper to parse videomodes from the devicetree
 +
  endmenu # OF
 diff --git a/drivers/of/Makefile b/drivers/of/Makefile
 index e027f44..80e6db3 100644
 --- a/drivers/of/Makefile
 +++ b/drivers/of/Makefile
 @@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO)   += of_mdio.o
  

[PATCH V2] drm/exynos: Add match table for drm platform device

2012-09-21 Thread Leela Krishna Amudala
This patch is a part of moving the driver to support DT style probing
of exynos drm device. The compatible name should match with the
entry in the dtsi file.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index d070719..495be89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -294,12 +294,23 @@ static int exynos_drm_platform_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id drm_device_dt_match[] = {
+   { .compatible = samsung,exynos-drm-device},
+   {},
+};
+MODULE_DEVICE_TABLE(of, drm_device_dt_match);
+#else
+#define drm_device_dt_match NULL
+#endif
+
 static struct platform_driver exynos_drm_platform_driver = {
.probe  = exynos_drm_platform_probe,
.remove = __devexit_p(exynos_drm_platform_remove),
.driver = {
.owner  = THIS_MODULE,
.name   = exynos-drm,
+   .of_match_table = of_match_ptr(drm_device_dt_match),
},
 };
 
-- 
1.7.0.4

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


Re: [PATCH V2] drm/exynos: Add match table for drm platform device

2012-09-21 Thread Srinivas KANDAGATLA
On 21/09/12 19:37, Leela Krishna Amudala wrote:
 This patch is a part of moving the driver to support DT style probing
 of exynos drm device. The compatible name should match with the
 entry in the dtsi file.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index d070719..495be89 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -294,12 +294,23 @@ static int exynos_drm_platform_remove(struct 
 platform_device *pdev)
   return 0;
  }
  
 +#ifdef CONFIG_OF
 +static const struct of_device_id drm_device_dt_match[] = {
 + { .compatible = samsung,exynos-drm-device},
 + {},
 +};
 +MODULE_DEVICE_TABLE(of, drm_device_dt_match);
 +#else
 +#define drm_device_dt_match NULL
 +#endif

No need of else here as you are using of_match_ptr.

 +
  static struct platform_driver exynos_drm_platform_driver = {
   .probe  = exynos_drm_platform_probe,
   .remove = __devexit_p(exynos_drm_platform_remove),
   .driver = {
   .owner  = THIS_MODULE,
   .name   = exynos-drm,
 + .of_match_table = of_match_ptr(drm_device_dt_match),
   },
  };
  

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


Re: [PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740

2012-09-21 Thread Josh Boyer
On Tue, Aug 28, 2012 at 4:50 PM,  j.gli...@gmail.com wrote:
 From: Jerome Glisse jgli...@redhat.com

 It seems some of those IGP dislike non dma32 page despite what
 documentation says. Fix regression since we allowed non dma32
 pages. It seems it only affect some revision of those IGP chips
 as we don't know which one just force dma32 for all of them.

 https://bugzilla.redhat.com/show_bug.cgi?id=785375

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 Cc: sta...@vger.kernel.org


This is upstream commit 4a2b6662c3632176b4fdf012243dd3751367bf1f.  I
don't see it queued up in the stable-queue, so I thought I'd point it
out in case it was missed.

josh

 ---
  drivers/gpu/drm/radeon/radeon_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
 b/drivers/gpu/drm/radeon/radeon_device.c
 index 066c98b..8867400 100644
 --- a/drivers/gpu/drm/radeon/radeon_device.c
 +++ b/drivers/gpu/drm/radeon/radeon_device.c
 @@ -774,7 +774,7 @@ int radeon_device_init(struct radeon_device *rdev,
 if (rdev-flags  RADEON_IS_AGP)
 rdev-need_dma32 = true;
 if ((rdev-flags  RADEON_IS_PCI) 
 -   (rdev-family  CHIP_RS400))
 +   (rdev-family = CHIP_RS740))
 rdev-need_dma32 = true;

 dma_bits = rdev-need_dma32 ? 32 : 40;
 --
 1.7.11.2

 --
 To unsubscribe from this list: send the line unsubscribe stable in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
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

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=49817

Laurent carlier lordhea...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #14 from Laurent carlier lordhea...@gmail.com 2012-09-21 15:20:42 
UTC ---
Not fixed for me with:
* libdrm-2.4.39
* mesa from git
 OpenGL renderer string: Gallium 0.4 on AMD BARTS
 OpenGL version string: 3.0 Mesa 9.1-devel (git-aa3c2e3)
 OpenGL shading language version string: 1.30
* kernel 2.6rc6
 Linux archMain 3.6.0-1-mainline #1 SMP PREEMPT Mon Sep 17 14:03:55 UTC 2012
x86_64 GNU/Linux


[163750.003001] radeon :01:00.0: evergreen_cs_track_validate_texture:842
texture bo too small (layer size 256000, offset 0, max layer 1, depth 1, bo
size 4096) (800 80)
[163750.003006] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[163750.019950] radeon :01:00.0: evergreen_cs_track_validate_texture:842
texture bo too small (layer size 256000, offset 0, max layer 1, depth 1, bo
size 4096) (800 80)
[163750.019960] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[163750.042266] radeon :01:00.0: evergreen_cs_track_validate_texture:842
texture bo too small (layer size 256000, offset 0, max layer 1, depth 1, bo
size 4096) (800 80)
[163750.042277] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

-- 
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 49817] radeon: The kernel rejected CS when running shader example from SFML library

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=49817

--- Comment #15 from Sven Arvidsson s...@whiz.se 2012-09-21 15:26:12 UTC ---
Are you guys talking about the same sample causing the bug? If not, it's
probably different bugs.

-- 
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

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=49943

--- Comment #8 from Harald Judt h.j...@gmx.at 2012-09-21 16:05:14 UTC ---
Reproducible with linux-3.6.0-rc6. If it is a duplicate of bug 51042, shouldn't
this be fixed now, or have the patches referenced in that bug not been
committed yet
(http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.ati/22107, or
more specific the patches by Daniel Vetter:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023407.html)?

I still get only two events when monitoring with udevadm:

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[601.731162] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
MAJOR=226
MINOR=0
SEQNUM=1407
SUBSYSTEM=drm

UDEV  [601.731859] change  
/devices/pci:00/:00:01.0/:01:00.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci:00/:00:01.0/:01:00.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
MAJOR=226
MINOR=0
SEQNUM=1407
SUBSYSTEM=drm

After that, no more events on plug/unplug.

-- 
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 V6 2/2] video: drm: exynos: Add device tree support

2012-09-21 Thread Stephen Warren
On 09/21/2012 01:22 AM, Inki Dae wrote:
 2012/9/21 Stephen Warren swar...@wwwdotorg.org:
 On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
 This patch adds device tree based discovery support for exynos DRM-FIMD
 driver which includes driver modification to handle platform data in
 both the cases with DT and non-DT, Also adds the documentation for bindings.

 diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt 
 b/Documentation/devicetree/bindings/drm/exynos/fimd.txt
 ...
 + - samsung,fimd-display: This property should specify the phandle of the
 +   display device node which holds the video interface timing with the
 +   below mentioned properties.
 +
 +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
 + horizontal timing includes four parameters in the following order.
 +
 + - horizontal back porch (in number of lcd clocks)
 + - horizontal front porch (in number of lcd clocks)
 + - hsync pulse width (in number of lcd clocks)
 + - Display panels X resolution.
 +
 +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
 + vertical timing includes four parameters in the following order.
 +
 + - vertical back porch (in number of lcd lines)
 + - vertical front porch (in number of lcd lines)
 + - vsync pulse width (in number of lcd clocks)
 + - Display panels Y resolution.

 Should this not use the new videomode timings that are under discussion at:

 http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html

 
 ok, I agree with you. then the videomode helper is going to be merged
 to mainline(3.6)? if so, this patch should be reworked based on the
 videomode helper.

I think the videomode helpers would be merged for 3.7 at the very
earliest; 3.6 is cooked already. Given there are still some comments on
the binding, perhaps it won't happen until 3.8, but it'd be best to ask
on that thread so that people more directly involved with the status can
answer.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support

2012-09-21 Thread Eric Nelson

Hi Sascha,

While testing against a video-enabled U-Boot on i.MX6, I found the issue
below.

On 09/21/2012 01:07 AM, Sascha Hauer wrote:

This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
board and the i.MX6q sabrelite board in different clone mode and dual
head setups.

Signed-off-by: Sascha Hauers.ha...@pengutronix.de
---
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -0,0 +1,579 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *


 snip


+static int ipu_get_resources(struct ipu_crtc *ipu_crtc,
+   struct ipu_client_platformdata *pdata)
+{
+
+   ipu_crtc-irq = ipu_idmac_channel_irq(ipu, ipu_crtc-ipu_ch,
+   IPU_IRQ_EOF);


Interrupts get enabled here


+   ret = devm_request_irq(ipu_crtc-dev, ipu_crtc-irq, ipu_irq_handler, 0,
+   imx_drm, ipu_crtc);
+   if (ret  0) {
+   dev_err(ipu_crtc-dev, irq request failed with %d.\n, ret);
+   goto err_out;
+   }
+

snip

+
+static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
+   struct ipu_client_platformdata *pdata)
+{
+   int ret;
+
+   ret = ipu_get_resources(ipu_crtc, pdata);
+   if (ret) {
+   dev_err(ipu_crtc-dev, getting resources failed with %d.\n,
+   ret);
+   return ret;
+   }
+


But ipu_crtc-imx_crtc gets initialized in this call, and
ipu_irq_handler() makes use of it.

The U-Boot code doesn't enable interrupts, so it's not acking
along the way, and leaves bits set in IPU1_INT_STAT_15.

I found that I can get around this in U-Boot by disabling the
LCD controller and acking all of the interrupts after disabling
the controller, but I haven't yet figured out where to tap into 
cleanup_before_linux().


Regards,


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


Re: [PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree

2012-09-21 Thread Greg Kroah-Hartman
On Fri, Sep 21, 2012 at 10:07:46AM +0200, Sascha Hauer wrote:
 The following adds the i.MX IPUv3 base and KMS driver to the staging
 tree. The patches apply cleanly on next-20120921. Dave has merged the
 missing helper functions, so this series has no further dependencies.
 
 Greg, please apply this for staging.

Nice job, all now applied to the staging-next tree.

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


[PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+

2012-09-21 Thread Tom Stellard
From: Tom Stellard thomas.stell...@amd.com

This makes it possible to create a surface for a buffer.
---
 radeon/radeon_surface.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 80b1505..235f4ae 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -686,7 +686,8 @@ static int eg_surface_sanity(struct radeon_surface_manager 
*surf_man,
 unsigned tileb;
 
 /* check surface dimension */
-if (surf-npix_x  16384 || surf-npix_y  16384 || surf-npix_z  16384) {
+if ((surf-npix_x  16384   (surf-npix_y != 1 || surf-npix_z != 1)) ||
+surf-npix_y  16384 || surf-npix_z  16384) {
 return -EINVAL;
 }
 
-- 
1.7.11.4

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


[Bug 55206] New: this commit break r600 llvm shader compiler

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55206

 Bug #: 55206
   Summary: this commit break r600 llvm shader compiler
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: jrch2...@gmail.com


todays marek patch b6521801070d52bdd5908824e82c1ce2dde16e8e breaks r600_llvm
since rctx context is still used by llvm path

-- 
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 55207] New: this commit break r600 llvm shader compiler

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55207

 Bug #: 55207
   Summary: this commit break r600 llvm shader compiler
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: jrch2...@gmail.com


todays marek patch b6521801070d52bdd5908824e82c1ce2dde16e8e breaks r600_llvm
since rctx context is still used by llvm path

-- 
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 55206] this commit break r600 llvm shader compiler

2012-09-21 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=55206

Tom Stellard tstel...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Tom Stellard tstel...@gmail.com 2012-09-22 00:07:10 UTC 
---
Fixed by commit bbb2ebe2fc073793c5129b164b61fe1b36dfc4b1

-- 
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] radeon: Allow N x 1 x 1 surfaces for evergreen+

2012-09-21 Thread Marek Olšák
I think it would be cleaner to add a new SURF_TYPE for buffers and
only allow large npix_x for that (and adding all the necessary sanity
checks to disallow invalid values).

Also, if you want to use it in Mesa, you or somebody else should:
1) make a libdrm release
2) bump libdrm_radeon version requirement in Mesa's configure.ac

Marek

On Fri, Sep 21, 2012 at 10:23 PM, Tom Stellard t...@stellard.net wrote:
 From: Tom Stellard thomas.stell...@amd.com

 This makes it possible to create a surface for a buffer.
 ---
  radeon/radeon_surface.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
 index 80b1505..235f4ae 100644
 --- a/radeon/radeon_surface.c
 +++ b/radeon/radeon_surface.c
 @@ -686,7 +686,8 @@ static int eg_surface_sanity(struct 
 radeon_surface_manager *surf_man,
  unsigned tileb;

  /* check surface dimension */
 -if (surf-npix_x  16384 || surf-npix_y  16384 || surf-npix_z  
 16384) {
 +if ((surf-npix_x  16384   (surf-npix_y != 1 || surf-npix_z != 1)) 
 ||
 +surf-npix_y  16384 || surf-npix_z  16384) {
  return -EINVAL;
  }

 --
 1.7.11.4

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