[Bug 55207] New: this commit break r600 llvm shader compiler
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 at lists.freedesktop.org ReportedBy: jrch2k10 at 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.
[Bug 55206] New: this commit break r600 llvm shader compiler
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 at lists.freedesktop.org ReportedBy: jrch2k10 at 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.
[Bug 46231] Radeon NI: evergreen_resume fails after GPU lockup
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: R_00867C_CP_BUSY_S
[PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+
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
Re: [PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+
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 wrote: > 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 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55206] this commit break r600 llvm shader compiler
https://bugs.freedesktop.org/show_bug.cgi?id=55206 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Tom Stellard 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
[PATCH V6 2/2] video: drm: exynos: Add device tree support
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 = <&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 #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 = devm
[PATCH V6 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd
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 = &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
[PATCH V6 0/2] video: drm: Add Device tree support to exynos DRM-FIMD
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/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 55207] New: this commit break r600 llvm shader compiler
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] New: this commit break r600 llvm shader compiler
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 49943] radeon/drm: Hotplug udev events stop working
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
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
[Bug 46231] Radeon NI: evergreen_resume fails after GPU lockup
https://bugzilla.kernel.org/show_bug.cgi?id=46231 --- Comment #3 from b...@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: R_00867C_CP_BUSY_STA
[PATCH] drm/exynos: Fix potential NULL pointer dereference
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
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
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
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 = <&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..80e6
[PATCH v4] of: Add videomode helper
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 = <&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 e027
[PATCH] radeon: Allow N x 1 x 1 surfaces for evergreen+
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 ___ 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
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
Re: [PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
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 ___ 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
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/exynos: Add match table for drm platform device
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
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
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?
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
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
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 = <&ipu 0>; + interface-pix-fmt = "rgb24"; +}; -- 1.7.10.4
[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
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); + ipu_di_disable(i
[PATCH 3/6] staging: drm/imx: add i.MX IPUv3 base driver
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
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, &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) +{ + struct imx_parallel_display *imxpd = enc_to_imxpd(encoder); + + imx_drm_crtc_panel_form
[PATCH 1/6] staging: drm/imx: Add i.MX drm core support
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
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
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)
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
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
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
[Bug 49943] radeon/drm: Hotplug udev events stop working
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: force dma32 to fix regression rs4xx, rs6xx, rs740
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 49817] radeon: The kernel rejected CS when running shader example from SFML library
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. ___ 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
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. ___ 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
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 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
Re: [PATCH v4] of: Add videomode helper
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@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 -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
Re: [PATCH V2] drm/exynos: Add match table for drm platform device
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), > }, > }; > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/exynos: Add match table for drm platform device
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 + 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 v4] of: Add videomode helper
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@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 -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 >
[git pull] drm rc7 fixes
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(-) ___ 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)
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 55172] New: Skybox misrendering (Unvanquished, texture compression enabled)
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.
Re: FOSDEM2013: DevRoom or not?
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
[PATCH 1/6] staging: drm/imx: Add i.MX drm core support
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 6/6] staging: drm/imx: Add TODO
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
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@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 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
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); + ipu_di_disable(i
[PATCH 2/6] staging: drm/imx: Add parallel display support
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, &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) +{ + struct imx_parallel_display *imxpd = enc_to_imxpd(encoder); + + imx_drm_crtc_panel_fo
[PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree
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
Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support
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 V6 2/2] video: drm: exynos: Add device tree support
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 = <&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 #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 = d
[PATCH V6 1/2] drm/exynos: add platform_device_id table and driver data for drm fimd
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 = &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 0/2] video: drm: Add Device tree support to exynos DRM-FIMD
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
Re: [PATCH V6 2/2] video: drm: exynos: Add device tree support
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-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