[PATCH V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd
The name of the exynos drm fimd device is renamed to exynos-drm-fimd
and two device ids are created for exynos4-fb and exynos5-drm-fimd.
Also, added driver data for exynos5 to pick the fimd version at runtime and
to choose the VIDTCON register offsets accordingly.
Signed-off-by: Leela Krishna Amudala
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 56 +++---
1 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 24c0bd4..8379c59 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))
+enum fimd_version_type {
+ VERSION_8, /* FIMD_VERSION8 */
+};
+
+struct drm_fimd_driver_data {
+ enum fimd_version_type fimd_ver;
+};
+
+struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
+ .fimd_ver = VERSION_8,
+};
+
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 drm_fimd_driver_data *drm_fimd_get_driver_data(
+ struct platform_device *pdev)
+{
+ return (struct drm_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,47 @@ 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 drm_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);
+ if (driver_data->fimd_ver == VERSION_8)
+ writel(ctx->vidcon1, ctx->regs + FIMD_V8_VIDCON1);
+ else
+ writel(ctx->vidcon1, ctx->regs + 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);
+ if (driver_data->fimd_ver == VERSION_8)
+ writel(val, ctx->regs + FIMD_V8_VIDTCON0);
+ else
+ writel(val, ctx->regs + 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);
+ if (driver_data->fimd_ver == VERSION_8)
+ writel(val, ctx->regs + FIMD_V8_VIDTCON1);
+ else
+ writel(val, ctx->regs + VIDTCON1);
/* setup horizontal and vertical display size. */
val = VIDTCON2_LINEVAL(timing->yres - 1) |
VIDTCON2_HOZVAL(timing->xres - 1);
- writel(val, ctx->regs + VIDTCON2);
+ if (driver_data->fimd_ver == VERSION_8)
+ writel(val, ctx->regs + FIMD_V8_VIDTCON2);
+ else
+ writel(val, ctx->regs + VIDTCON2);
/* setup clock source, clock divider, enable dma. */
val = ctx->vidcon0;
@@ -982,6 +1016,17 @@ static int fimd_runtime_resume(struct device *dev)
}
#endif
+static struct platform_device_id exynos_drm_fimd_driver_ids[] = {
+ {
+ .name = "exynos4-fb",
+ }, {
+ .name = "exynos5-drm-fimd",
+ .driver_data= (unsigned long)&exynos5_drm_fimd_driver_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, exynos_drm_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)
@@ -990,8 +1035,9 @@ static const struct dev_pm_ops fimd_pm_ops = {
struct platform_driver fimd_driver = {
.probe = fimd_probe,
.remove = __devexit_p(fimd_remove),
+ .id_table = exynos_drm_fimd_driver_ids,
.driver = {
- .name = "exynos4-fb",
+ .name = "exynos-drm-fimd",
.owner = THIS_MODULE,
.pm = &fimd_pm_ops,
},
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3 2/2] video: drm: exynos: Add device tree support
Add device tree based discovery support for DRM-FIMD driver.
Signed-off-by: Leela Krishna Amudala
---
Documentation/devicetree/bindings/fb/drm-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/fb/drm-fimd.txt
diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
b/Documentation/devicetree/bindings/fb/drm-fimd.txt
new file mode 100644
index 000..8ad8814
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/drm-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-drm" 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:
+ - supports-mipi-panel: Specifies the lcd is mipi panel type
+ - 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-drm";
+ 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 8379c59..1753846 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 drm_fimd_dt_match[];
+
static inline struct drm_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_node(drm_fimd_dt_match, pdev->dev.of_node);
+ return (struct drm_fimd_driver_data *)match->data;
+ }
+#endif
return (struct drm_fimd_driver_data *)
platform_get_device_id(pdev)->driver_data;
}
@@ -821,12 +831,79 @@ 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_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd) {
+ dev_err(dev, "memory allo
[PATCH V3 0/2] video: drm: Add Device tree support to 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 exynos5 device. This patchset is based and tested on top of v3.6-rc1 Also depends on below patchset http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html 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 exynos5 drm fimd video: drm: exynos: Add device tree support Documentation/devicetree/bindings/fb/drm-fimd.txt | 80 +++ drivers/gpu/drm/exynos/exynos_drm_fimd.c | 151 - 2 files changed, 224 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/fb/drm-fimd.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.
Hi Hans,
For EDID update, it is recommended that the HPD line be toggled
after the EDID update is completed. So for the driver to detect the
EDID write is complete, probably a field mentioning the EDID write
completed would be good, so that the HPD toggling can be done by the
driver.
Best Regards
Soby Mathew
On 8/10/12, Hans Verkuil wrote:
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/v4l2-compat-ioctl32.c | 57
> +
> drivers/media/video/v4l2-ioctl.c | 13 +++
> drivers/media/video/v4l2-subdev.c |6 +++
> include/media/v4l2-subdev.h |2 +
> 4 files changed, 78 insertions(+)
>
> diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
> b/drivers/media/video/v4l2-compat-ioctl32.c
> index 9ebd5c5..e843705 100644
> --- a/drivers/media/video/v4l2-compat-ioctl32.c
> +++ b/drivers/media/video/v4l2-compat-ioctl32.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -729,6 +730,44 @@ static int put_v4l2_event32(struct v4l2_event *kp,
> struct v4l2_event32 __user *u
> return 0;
> }
>
> +struct v4l2_subdev_edid32 {
> + __u32 pad;
> + __u32 start_block;
> + __u32 blocks;
> + __u32 reserved[5];
> + compat_caddr_t edid;
> +};
> +
> +static int get_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
> v4l2_subdev_edid32 __user *up)
> +{
> + u32 tmp;
> +
> + if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_subdev_edid32)) ||
> + get_user(kp->pad, &up->pad) ||
> + get_user(kp->start_block, &up->start_block) ||
> + get_user(kp->blocks, &up->blocks) ||
> + get_user(tmp, &up->edid) ||
> + copy_from_user(kp->reserved, up->reserved,
> sizeof(kp->reserved)))
> + return -EFAULT;
> + kp->edid = compat_ptr(tmp);
> + return 0;
> +}
> +
> +static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid *kp, struct
> v4l2_subdev_edid32 __user *up)
> +{
> + u32 tmp = (u32)((unsigned long)kp->edid);
> +
> + if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_subdev_edid32)) ||
> + put_user(kp->pad, &up->pad) ||
> + put_user(kp->start_block, &up->start_block) ||
> + put_user(kp->blocks, &up->blocks) ||
> + put_user(tmp, &up->edid) ||
> + copy_to_user(kp->reserved, up->reserved, sizeof(kp->reserved)))
> + return -EFAULT;
> + return 0;
> +}
> +
> +
> #define VIDIOC_G_FMT32 _IOWR('V', 4, struct v4l2_format32)
> #define VIDIOC_S_FMT32 _IOWR('V', 5, struct v4l2_format32)
> #define VIDIOC_QUERYBUF32_IOWR('V', 9, struct v4l2_buffer32)
> @@ -738,6 +777,8 @@ static int put_v4l2_event32(struct v4l2_event *kp,
> struct v4l2_event32 __user *u
> #define VIDIOC_DQBUF32 _IOWR('V', 17, struct v4l2_buffer32)
> #define VIDIOC_ENUMSTD32 _IOWR('V', 25, struct v4l2_standard32)
> #define VIDIOC_ENUMINPUT32 _IOWR('V', 26, struct v4l2_input32)
> +#define VIDIOC_SUBDEV_G_EDID32 _IOWR('V', 63, struct
> v4l2_subdev_edid32)
> +#define VIDIOC_SUBDEV_S_EDID32 _IOWR('V', 64, struct
> v4l2_subdev_edid32)
> #define VIDIOC_TRY_FMT32 _IOWR('V', 64, struct v4l2_format32)
> #define VIDIOC_G_EXT_CTRLS32_IOWR('V', 71, struct v4l2_ext_controls32)
> #define VIDIOC_S_EXT_CTRLS32_IOWR('V', 72, struct v4l2_ext_controls32)
> @@ -765,6 +806,7 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
> struct v4l2_ext_controls v2ecs;
> struct v4l2_event v2ev;
> struct v4l2_create_buffers v2crt;
> + struct v4l2_subdev_edid v2edid;
> unsigned long vx;
> int vi;
> } karg;
> @@ -797,6 +839,8 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
> case VIDIOC_S_OUTPUT32: cmd = VIDIOC_S_OUTPUT; break;
> case VIDIOC_CREATE_BUFS32: cmd = VIDIOC_CREATE_BUFS; break;
> case VIDIOC_PREPARE_BUF32: cmd = VIDIOC_PREPARE_BUF; break;
> + case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
> + case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
> }
>
> switch (cmd) {
> @@ -814,6 +858,12 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
> compatible_arg = 0;
> break;
>
> + case VIDIOC_SUBDEV_G_EDID:
> + case VIDIOC_SUBDEV_S_EDID:
> + err = get_v4l2_subdev_edid32(&karg.v2edid, up);
> + compatible_arg = 0;
> + break;
> +
> case VIDIOC_G_FMT:
> case VIDIOC_S_FMT:
> case VIDIOC_TRY_FMT:
> @@ -906,6 +956,11 @@ static long do_video_ioctl(struct file *file, unsigned
> int cmd, unsigned long ar
> err = put_v4l2_event32(&karg.v2ev, up);
> break;
>
> + case VIDIOC_SUBDEV_G_EDID:
> + case VIDIOC_
Re: [PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch
On Thu, Aug 16, 2012 at 01:54:55PM -0400, alexdeuc...@gmail.com wrote:
> From: David L
>
> This is required for pure UEFI systems. The vbios is stored
> in ACPI rather than at the legacy vga location.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_bios.c | 59
> ++
> 1 files changed, 59 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 501f488..f06494a7 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -32,6 +32,9 @@
>
> #include
> #include
> +#ifdef CONFIG_ACPI
> +#include
> +#endif
This #ifdef should not be needed, right?
> +#ifdef CONFIG_ACPI
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
> +{
> + bool ret = false;
> + struct acpi_table_header *hdr;
> + /* acpi_get_table_with_size is not exported :( */
> + acpi_size tbl_size = 0x7fff;
> + UEFI_ACPI_VFCT *vfct;
> + GOP_VBIOS_CONTENT *vbios;
> + VFCT_IMAGE_HEADER *vhdr;
> +
> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
> + return false;
> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short
> #1)\n");
> + goto out_unmap;
> + }
> +
> + vfct = (UEFI_ACPI_VFCT *)hdr;
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short
> #2)\n");
> + goto out_unmap;
> + }
> +
> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
> + vhdr = &vbios->VbiosHeader;
> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size
> %d\n",
> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
> +
> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
> + vhdr->VendorID != rdev->pdev->vendor ||
> + vhdr->DeviceID != rdev->pdev->device) {
> + DRM_INFO("ACPI VFCT table is not for this card\n");
> + goto out_unmap;
> + };
> +
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) +
> vhdr->ImageLength > tbl_size) {
> + DRM_ERROR("ACPI VFCT image truncated\n");
> + goto out_unmap;
> + }
> +
> + rdev->bios = kmemdup(&vbios->VbiosContent, vhdr->ImageLength,
> GFP_KERNEL);
> + ret = !!rdev->bios;
> +
> +out_unmap:
> + /* uh, no idea what to do here... */
> + return ret;
> +}
> +#endif
Please provide an "empty" function here if the #ifdef is not true, which
then makes the following #ifdef not needed:
> @@ -487,6 +542,10 @@ bool radeon_get_bios(struct radeon_device *rdev)
> r = igp_read_bios_from_vram(rdev);
> if (r == false)
> r = radeon_read_bios(rdev);
> +#ifdef CONFIG_ACPI
> + if (r == false)
> + r = radeon_acpi_vfct_bios(rdev);
> +#endif
See, then that #ifdef isn't needed.
That cleans up the code more, remember, we don't want #ifdefs in .c
files unless we _really_ have to have them.
thanks,
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon: split ATRM support out from the ATPX handler
On Thu, Aug 16, 2012 at 01:54:56PM -0400, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > There are systems that use ATRM, but not ATPX. > > Fixes: > https://bugs.freedesktop.org/show_bug.cgi?id=41265 Same #ifdef comments here as for patch 1/2. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)
On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeuc...@gmail.com wrote:
> From: David L
>
> This is required for pure UEFI systems. The vbios is stored
> in ACPI rather than at the legacy vga location.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>
> V2: fix #ifdefs as per Greg's comments
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/radeon_bios.c | 62
> ++
> 1 files changed, 62 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
> b/drivers/gpu/drm/radeon/radeon_bios.c
> index 501f488..bf21f65 100644
> --- a/drivers/gpu/drm/radeon/radeon_bios.c
> +++ b/drivers/gpu/drm/radeon/radeon_bios.c
> @@ -32,6 +32,9 @@
>
> #include
> #include
> +#ifdef CONFIG_ACPI
> +#include
> +#endif
You forgot to remove this one :(
> /*
> * BIOS.
> */
> @@ -476,6 +479,63 @@ static bool radeon_read_disabled_bios(struct
> radeon_device *rdev)
> return legacy_read_disabled_bios(rdev);
> }
>
> +#ifdef CONFIG_ACPI
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
> +{
> + bool ret = false;
> + struct acpi_table_header *hdr;
> + /* acpi_get_table_with_size is not exported :( */
> + acpi_size tbl_size = 0x7fff;
> + UEFI_ACPI_VFCT *vfct;
> + GOP_VBIOS_CONTENT *vbios;
> + VFCT_IMAGE_HEADER *vhdr;
> +
> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
> + return false;
> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short
> #1)\n");
> + goto out_unmap;
> + }
> +
> + vfct = (UEFI_ACPI_VFCT *)hdr;
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
> + DRM_ERROR("ACPI VFCT table present but broken (too short
> #2)\n");
> + goto out_unmap;
> + }
> +
> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
> + vhdr = &vbios->VbiosHeader;
> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size
> %d\n",
> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
> +
> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
> + vhdr->VendorID != rdev->pdev->vendor ||
> + vhdr->DeviceID != rdev->pdev->device) {
> + DRM_INFO("ACPI VFCT table is not for this card\n");
> + goto out_unmap;
> + };
> +
> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) +
> vhdr->ImageLength > tbl_size) {
> + DRM_ERROR("ACPI VFCT image truncated\n");
> + goto out_unmap;
> + }
> +
> + rdev->bios = kmemdup(&vbios->VbiosContent, vhdr->ImageLength,
> GFP_KERNEL);
> + ret = !!rdev->bios;
> +
> +out_unmap:
> + /* uh, no idea what to do here... */
> + return ret;
> +}
> +#else
> +static bool radeon_acpi_vfct_bios(struct radeon_device *rdev)
Make it inline, and then the compiler is smart enough to just delete the
whole if () check you make when you call it.
Third time's a charm?
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v4
On Mon, Aug 06, 2012 at 12:56:04PM -0400, j.gli...@gmail.com wrote: > From: Jerome Glisse > > Virtual address need to be fenced to know when we can safely remove it. > This patch also properly clear the pagetable. Previously it was > serouisly broken. > > v2: For to update pagetable when unbinding bo (don't bailout if > bo_va->valid is true). > v3: Fix compilation warnings > v4: We need a special version for 3.5 because the locking scheme > is different btw 3.5 and 3.6. There is no longer cs mutex in > 3.6 instead there is a global vm mutex. > > This version is for stable 3.5 only. Is the version that fixes this problem in the 3.6 tree, already in Linus's tree? If so, what is the git commit id? If not, I need to wait until it gets in there, so please tell me when it does so. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/5] Generic panel framework
On Friday, August 17, 2012 9:50 AM Laurent Pinchart wrote: > > Hi everybody, > > While working on DT bindings for the Renesas Mobile SoC display controller > (a.k.a. LCDC) I quickly realized that display panel implementation based on > board code callbacks would need to be replaced by a driver-based panel > framework. > > Several driver-based panel support solution already exist in the kernel. > > - The LCD device class is implemented in drivers/video/backlight/lcd.c and > exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV > API for historical reason, uses board code callback for reset and power > management, and doesn't include support for standard features available in > today's "smart panels". > > - OMAP2+ based systems use custom panel drivers available in > drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display > controller) specific APIs. > > - Similarly, Exynos based systems use custom panel drivers available in > drivers/video/exynos. Only a single driver (s6e8ax0) is currently available. > That driver is based on Exynos display controller specific APIs and on the > LCD device class API. > Hi Laurent, I am a Exynos DP maintainer and Samsung FB maintainer. Actually, eDP (embedded display port) will be faced with this kind of problem. According to the eDP standard, eDP panel can have their own specific registers that handle extra operations. In this case, custom panel driver for this eDP panel will be necessary. In my opinion, the panel framework would be helpful to solve this problem. Best regards, Jingoo Han > I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus > Lorentzon (working on panel support for ST/Linaro), and we agreed that a > generic panel framework for display devices is needed. These patches implement > a first proof of concept. > > One of the main reasons for creating a new panel framework instead of adding > missing features to the LCD framework is to avoid being tied to the FBDEV > framework. Panels will be used by DRM drivers as well, and their API should > thus be subsystem-agnostic. Note that the panel framework used the > fb_videomode structure in its API, this will be replaced by a common video > mode structure shared across subsystems (there's only so many hours per day). > > Panels, as used in these patches, are defined as physical devices combining a > matrix of pixels and a controller capable of driving that matrix. > > Panel physical devices are registered as children of the control bus the panel > controller is connected to (depending on the panel type, we can find platform > devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ... > devices). The generic panel framework matches registered panel devices with > panel drivers and call the panel drivers probe method, as done by other device > classes in the kernel. The driver probe() method is responsible for > instantiating a struct panel instance and registering it with the generic > panel framework. > > Display drivers are panel consumers. They register a panel notifier with the > framework, which then calls the notifier when a matching panel is registered. > The reason for this asynchronous mode of operation, compared to how drivers > acquire regulator or clock resources, is that the panel can use resources > provided by the display driver. For instance a panel can be a child of the DBI > or DSI bus controlled by the display device, or use a clock provided by that > device. We can't defer the display device probe until the panel is registered > and also defer the panel device probe until the display is registered. As > most display drivers need to handle output devices hotplug (HDMI monitors for > instance), handling panel through a notification system seemed to be the > easiest solution. > > Note that this brings a different issue after registration, as display and > panel drivers would take a reference to each other. Those circular references > would make driver unloading impossible. I haven't found a good solution for > that problem yet (hence the RFC state of those patches), and I would > appreciate your input here. This might also be a hint that the framework > design is wrong to start with. I guess I can't get everything right on the > first try ;-) > > Getting hold of the panel is the most complex part. Once done, display drivers > can call abstract operations provided by panel drivers to control the panel > operation. These patches implement three of those operations (enable, start > transfer and get modes). More operations will be needed, and those three > operations will likely get modified during review. Most of the panels on > devices I own are dumb panels with no control bus, and are thus not the best > candidates to design a framework that needs to take complex panels' needs into > account. > > In addition to the generic panel core, I've implemented MIPI DBI (Display Bus > Interfac
Re: [PATCH] drm/edid: limit printk when facing bad edid
On Thu, 16 Aug 2012, Jerome Glisse wrote: > On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula > wrote: >> >> There's a bug [1] where the faster GMBUS transmissions fail with some >> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As >> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so >> some measures to reduce the EDID error messages would be most welcome. >> >> [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881 >> [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912 >> >> On Tue, 14 Aug 2012, Jerome Glisse wrote: >>> On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson wrote: On 8/9/12 11:25 AM, j.gli...@gmail.com wrote: > > From: Jerome Glisse > > Limit printing bad edid information at one time per connector. > Connector that are connected to a bad monitor/kvm will likely > stay connected to the same bad monitor/kvm and it makes no > sense to keep printing the bad edid message. >> >> Do I understand correctly that bad_edid_counter is only reset when you >> reboot or reload the module? So if you have a laptop that you connect to >> the monitor at home, the monitor at the office, the projector in the >> meeting room, and to a TV somewhere else, etc, the message about bad >> EDID will only printed once? I don't think that's good. But please do >> correct me if I'm wrong. > > I wanted to reset the counter any time the connector is connected to > something with good edid but i did not do that in the end. I can do a > patch on top if you think it would be nicer. That way only thing with > bad edid will be printed once and assuming you don't repeatly > alternate btw good and bad edid device you would not get spam. IMHO this is, with or without the additional patch, overengineering the logic to print out error messages. For me, as a developer, this would be annoying because, to debug an EDID issue, I'd have to reload the module, connect to something with "good" EDID in between, or patch this out, to repeat a problem. I might have to ask a tester or a bug reporter to do the same. Also, in the referenced bug, the first problem with GMBUS would disable error messages, and the fallback retry with GPIO bit-banging would no longer produce messages even if that failed too. > > > Signed-off-by: Jerome Glisse I guess. I don't see why we don't just move it into DRM_DEBUG_KMS if we're going to suppress it, but this does what it says on the box. Reviewed-by: Adam Jackson - ajax >>> >>> I think there is still value in getting at least once the bad edid. >> >> I think the raw edid dumps should be DEBUG level no matter what. Perhaps >> some of the other messages could use WARNING/DEBUG too. And with that, >> and my comment above, I not sure there really needs to be all that logic >> to count errors and act differently further on. >> > > No, i do think we want bad edid as normal log at least once per > connector and we definitely don't want to spam bomb the log messages. Well, at least we agree on silencing the dmesg here. ;) I'd be happy with very simply adjusting the loglevel of the messages, so that I can also very simply adjust the amount of messages I get. Or ask a bug reported to do drm.debug=0xe instead of trying to ensure they follow a bunch of steps in between. But I'm not going to bikeshed further if others think the patch here is the way to go. BR, Jani. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] first drm-intel-next for 3.7
Hi Dave, First -next pull for 3.7. Highlights: - hsw hdmi improvements (Paulo) - ips/rps locking rework and cleanups - rc6 on ilk by default again - hw context&dp&dpff support for hsw (Ben) - GET_PARAM_HAS_SEMAPHORES (Chris) - gen6+ pipe_control improvements (Chris) - set_cacheing ioctl and assorted support code (Chris) - cleanups around the busy/idle/pm code (Chris&me) - flushing_list removal, hopefully for good (Chris) - read_reg ioctl (Ben) - support the ns2501 dvo (Thomas Richter) - avoid the costly gen6+ "missed IRQ" workaround where we don't need a race-free seqno readback (Chris) - various bits&pieces, mostly early patches from the modeset rework branch As discussed on irc I'll send you a pull with 3.6-rc2 merged in, since there's a funny conflict with mainline. Wrt regressions nothing new popped up since my -fixes pull, and QA has been rather happy with testing this -next pull here. Yours, Daniel Aside: I've frobbed the shortlog to exclude everything in -rc2. The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to a22ddff8bedfe33eeb1330bbb7ef1fbe007a42c4: Merge tag 'v3.6-rc2' into drm-intel-next (2012-08-17 09:01:08 +0200) Ben Widawsky (4): drm/i915: add register read IOCTL drm/i915: Add contexts for HSW drm/i915: Macro to determine DPF support drm/i915: Expand DPF support to Haswell Chris Wilson (17): drm/i915: Cleanup context switching through do_switch() drm/i915: Return a mask of the active rings in the high word of busy_ioctl drm/i915: Allow late allocation of request for i915_add_request() drm/i915: Remove assertion over write domain after i915_gem_object_sync() drm/i915: Replace the pending_gpu_write flag with an explicit seqno drm/i915: Remove the defunct flushing list drm/i915: Remove the per-ring write list drm/i915: Remove explicit flush from i915_gem_object_flush_fence() drm/i915: Remove the explicit flush of the GPU write domain drm/i915: Clear the pending_gpu_fenced_access flag at the start of execbuffer drm/i915: Split i915_gem_flush_ring() into seperate invalidate/flush funcs drm/i915: Avoid concurrent access when marking the device as idle/busy drm/i915: Segregate memory domains in the GTT using coloring drm/i915: Export ability of changing cache levels to userspace drm/i915: Only apply the SNB pipe control w/a to gen6 drm/i915: Add I915_GEM_PARAM_HAS_SEMAPHORES drm/i915: Lazily apply the SNB+ seqno w/a Daniel Vetter (21): drm/i915: group ADPA #defines together drm/i915: simplify possible_clones computation drm/i915: add port parameter to intel_hdmi_init drm/i915: Reserve ioctl numbers for set/get_caching drm/i915: create VLV_DSIPLAY_BASE #define drm/i915: add inte_crt->adpa_reg drm/i915: Replace the complex flushing logic with simple invalidate/flush all drm/i915: Only set the down rps limit when at the loweset frequency drm/i915: rip out sanitize_pm again drm/i915: fixup desired rps frequency computation drm/i915: dump the device info drm/i915: properly guard ilk ips state drm/i915: fixup up debugfs rps state handling drm/i915: use mutex_lock_interruptible for debugfs files drm/i915: move all rps state into dev_priv->rps drm/i915: kill dev_priv->mchdev_lock drm/i915: DE_PCU_EVENT irq is ilk-only drm/i915: fix up ilk drps/ips locking drm/i915: enable rc6 on ilk again drm/i915: don't grab dev->struct_mutex for userspace forcewak Merge tag 'v3.6-rc2' into drm-intel-next Eugeni Dodonov (1): drm/i915: prevent possible pin leak on error path Paulo Zanoni (10): drm/i915: move common code to intel_dp_set_link_train drm/i915: add port field to struct intel_dp and use it drm/i915: fix pipe DDI mode select drm/i915: set the DDI sync polarity bits drm/i915: correctly set the DDI_FUNC_CTL bpc field drm/i915: completely reset the value of DDI_FUNC_CTL drm/i915: reindent Haswell register definitions drm/i915: add parentheses around PIXCLK_GATE definitions drm/i915: use the correct encoder type when comparing drm/i915: try harder to find WR PLL clock settings Shobhit Kumar (1): drm/i915: Move DP structs to shared location Thomas Richter (1): drm/i915: Support for ns2501-DVO drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/dvo.h |1 + drivers/gpu/drm/i915/dvo_ns2501.c | 582 drivers/gpu/drm/i915/i915_debugfs.c| 143 --- drivers/gpu/drm/i915/i915_dma.c| 26 +- drivers/gpu/drm/i915/
[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 Michel Dänzer changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #127 from Michel Dänzer 2012-08-17 07:26:52 UTC --- (In reply to comment #126) > I won't say for sure the vm problem is fixed, but if it's still there, latest > patches helped a lot since I was able to run more than twice as long as usual > without any problem. Great! Resolving this bug as fixed. Any other remaining issues, in particular Thomas' glamor issues, should be tracked in separate bug reports. -- 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 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #9 from Michel Dänzer 2012-08-17 07:28:50 UTC --- (In reply to comment #8) > Is there a way to use apitrace in combination with piglit? I'd like to trace > the problematic test. The first step would be to reproduce the problem by manually running the problematic test from the piglit/bin directory. Then you should be able to apitrace it just like any other app. -- 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 53630] New: compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 Bug #: 53630 Summary: compiz + glamor = screen corruptions Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v10la...@myway.de Created attachment 65668 --> https://bugs.freedesktop.org/attachment.cgi?id=65668 dmesg ouput while compiz loads I get screen corruptions when starting compiz while GLAMOR acceleration is enabled. The desktop shows random white bars at the desktop right after loading. These bars can be removed by refreshing the desktop (re-setting the desktop background in XFCE). While compiz loads the attached log shows up in dmesg. -- 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 53632] New: Radmon rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 Bug #: 53632 Summary: Radmon rendering corruptions Classification: Unclassified Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v10la...@myway.de I get random rendering corruptions in Minecraft with a CAYMAN GPU (radeon HD 6950). It seems like the wrong textures are selected, see: Good: http://img713.imageshack.us/img713/492/mcgood.png Bad: http://img96.imageshack.us/img96/6417/mcbad.png Also water seems to (randomly) choose the wrong texture in it's animation, resulting in flashing water. Also the game screen flashes blue sometimes. There are no error logs at all and this seems to be triggered by Michel Dänzers patches to fix bug #45018 (see comment #119 there) as it wasn't there before. Please note that this has nothing to do with GLAMOR acceleration (not used when the corruptions occur). -- 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 53632] Radmon rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 --- Comment #1 from Michel Dänzer 2012-08-17 08:28:09 UTC --- (In reply to comment #1) > Good: http://img713.imageshack.us/img713/492/mcgood.png > Bad: http://img96.imageshack.us/img96/6417/mcbad.png Please attach files here directly. > There are no error logs at all and this seems to be triggered by Michel > Dänzers > patches to fix bug #45018 (see comment #119 there) as it wasn't there before. Can you bisect which commit exactly triggered it? Do you have Jerome's kernel fix referenced in that report? -- 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: [RFC 0/5] Generic panel framework
Hi, On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote: > I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If Oookay, where to start... ;) A few cosmetic/general comments first. I find the file naming a bit strange. You have panel.c, which is the core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which is driver for r61517 panel... Perhaps something in this direction (in order): panel-core.c, mipi-dbi-bus.c, panel-r61517.c? And we probably end up with quite a lot of panel drivers, perhaps we should already divide these into separate directories, and then we wouldn't need to prefix each panel with "panel-" at all. --- Should we aim for DT only solution from the start? DT is the direction we are going, and I feel the older platform data stuff would be deprecated soon. --- Something missing from the intro is how this whole thing should be used. It doesn't help if we know how to turn on the panel, we also need to display something on it =). So I think some kind of diagram/example of how, say, drm would use this thing, and also how the SoC specific DBI bus driver would be done, would clarify things. --- We have discussed face to face about the different hardware setups and scenarios that we should support, but I'll list some of them here for others: 1) We need to support chains of external display chips and panels. A simple example is a chip that takes DSI in, and outputs DPI. In that case we'd have a chain of SoC -> DSI2DPI -> DPI panel. In final products I think two external devices is the maximum (at least I've never seen three devices in a row), but in theory and in development environments the chain can be arbitrarily long. Also the connections are not necessarily 1-to-1, but a device can take one input while it has two outputs, or a device can take two inputs. Now, I think two external devices is a must requirement. I'm not sure if supporting more is an important requirement. However, if we support two devices, it could be that it's trivial to change the framework to support n devices. 2) Panels and display chips are all but standard. They very often have their own sequences how to do things, have bugs, or implement some feature in slightly different way than some other panel. This is why the panel driver should be able to control or define the way things happen. As an example, Sharp LQ043T1DG01 panel (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with the following sequence: - Enable VCC and AVDD regulators - Wait min 50ms - Enable full video stream (pck, syncs, pixels) from SoC - Wait min 0.5ms - Set DISP GPIO, which turns on the display panel Here we could split the enabling of panel to two parts, prepare (in this case starts regulators and waits 50ms) and finish (wait 0.5ms and set DISP GPIO), and the upper layer would start the video stream in between. I realize this could be done with the PANEL_ENABLE_* levels in your RFC, but I don't think the concepts quite match: - PANEL_ENABLE_BLANK level is needed for "smart panels", as we need to configure them and send the initial frame at that operating level. With dummy panels there's really no such level, there's just one enable sequence that is always done right away. - I find waiting at the beginning of a function very ugly (what are we waiting for?) and we'd need that when changing the panel to PANEL_ENABLE_ON level. - It's still limited if the panel is a stranger one (see following example). Consider the following theoretical panel enable example, taken to absurd level just to show the general problem: - Enable regulators - Enable video stream - Wait 50ms - Disable video stream - Set enable GPIO - Enable video stream This one would be rather impossible with the upper layer handling the enabling of the video stream. Thus I see that the panel driver needs to control the sequences, and the Sharp panel driver's enable would look something like: regulator_enable(...); sleep(); dpi_enable_video(); sleep(); gpip_set(..); Note that even with this model we still need the PANEL_ENABLE levels you have. --- I'm not sure I understand the panel unload problem you mentioned. Nobody should have direct references to the panel functions, so there shouldn't be any automatic references that would prevent module unloading. So when the user does rmmod panel-mypanel, the panel driver's remove will be called. It'll unregister itself from the panel framework, which causes notifications and the display driver will stop using the panel. After that nobody has pointers to the panel, and it can safely be unloaded. It could cause some locking issues, though. First the panel's remove could take a lock, but the remove sequence would cause the display driver to call disable on the panel, which could again try to take the same lock... Tomi signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel
[Bug 53632] Radmon rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 --- Comment #2 from Thomas Rohloff 2012-08-17 08:40:26 UTC --- Created attachment 65672 --> https://bugs.freedesktop.org/attachment.cgi?id=65672 Good rendering -- 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 53632] Radmon rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 --- Comment #3 from Thomas Rohloff 2012-08-17 08:40:54 UTC --- Created attachment 65673 --> https://bugs.freedesktop.org/attachment.cgi?id=65673 Bad rendering -- 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 53632] Radmon rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 --- Comment #4 from Thomas Rohloff 2012-08-17 08:43:23 UTC --- (In reply to comment #1) > Please attach files here directly. Sorry, done. > Can you bisect which commit exactly triggered it? I'm not that good at bisecting (never did it) but I could try to remove your patches one by one. Would that help, too? > Do you have Jerome's kernel fix referenced in that report? No. It's a 3.5 kernel without (DRI related) patches. Do I need the kernel patch, too? -- 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 11/15] drm: Handle io prot correctly for MIPS
Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/drm_vm.c |2 +- drivers/gpu/drm/ttm/ttm_bo_util.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c index 961ee08..3f06166 100644 --- a/drivers/gpu/drm/drm_vm.c +++ b/drivers/gpu/drm/drm_vm.c @@ -62,7 +62,7 @@ static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma) tmp = pgprot_writecombine(tmp); else tmp = pgprot_noncached(tmp); -#elif defined(__sparc__) || defined(__arm__) +#elif defined(__sparc__) || defined(__arm__) || defined(__mips__) tmp = pgprot_noncached(tmp); #endif return tmp; diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index f8187ea..0df71ea 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -472,7 +472,7 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t tmp) else tmp = pgprot_noncached(tmp); #endif -#if defined(__sparc__) +#if defined(__sparc__) || defined(__mips__) if (!(caching_flags & TTM_PL_FLAG_CACHED)) tmp = pgprot_noncached(tmp); #endif -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53632] Radmon rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 --- Comment #5 from Michel Dänzer 2012-08-17 08:47:30 UTC --- (In reply to comment #4) > > Can you bisect which commit exactly triggered it? > I'm not that good at bisecting (never did it) but I could try to remove your > patches one by one. Would that help, too? Yes, that would be the poor man's way to isolate the commit. But you should really learn to bisect. :) > Do I need the kernel patch, too? Yes. -- 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: [RFC 3/5] video: panel: Add MIPI DBI bus support
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> +/*
> -
> + * Bus operations
> + */
> +
> +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
> +{
> + dev->bus->ops->write_command(dev->bus, cmd);
> +}
> +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> +
> +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long data)
> +{
> + dev->bus->ops->write_data(dev->bus, data);
> +}
> +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> +
> +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> +{
> + return dev->bus->ops->read_data(dev->bus);
> +}
> +EXPORT_SYMBOL_GPL(panel_dbi_read_data);
I'm not that familiar with how to implement bus drivers, can you
describe in pseudo code how the SoC's DBI driver would register these?
I think write/read data functions are a bit limited. Shouldn't they be
something like write_data(const u8 *buf, int size) and read_data(u8
*buf, int len)?
Something that's totally missing is configuring the DBI bus. There are a
bunch of timing related values that need to be configured. See
include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
specific, if I recall right most of the values match to the MIPI DBI
spec.
And this makes me wonder, you use DBI bus for SYS-80 panel. The busses
may look similar in operation, but are they really so similar when you
take into account the timings (and perhaps something else, it's been
years since I read the MIPI DBI spec)?
Then there's the start_transfer. This is something I'm not sure what is
the best way to handle it, but the same problems that I mentioned in the
previous post related to enable apply here also. For example, what if
the panel needs to be update in two parts? This is done in Nokia N9.
From panel's perspective, it'd be best to handle it somewhat like this
(although asynchronously, probably):
write_update_area(0, 0, xres, yres / 2);
write_memory_start()
start_pixel_transfer();
wait_transfer_done();
write_update_area(0, yres / 2, xres, yres / 2);
write_memory_start()
start_pixel_transfer();
Why I said I'm not sure about this is that it does complicate things, as
the actual pixel data often comes from the display subsystem hardware,
which should probably be controlled by the display driver.
I think there also needs to be some kind of transfer_done notifier, for
both the display driver and the panel driver. Although if the display
driver handles starting the actual pixel transfer, then it'll get the
transfer_done via whatever interrupt the SoC has.
Also as food for thought, videomode timings does not really make sense
for DBI panels, at least when you just consider the DBI side. There's
really just the resolution of the display, and then the DBI timings. No
pck, syncs, etc. Of course in the end there's the actual panel, which
does have these video timings. But often they cannot be configured, and
often you don't even know them as the specs don't tell them.
Tomi
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53632] Random rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 Andreas Boll changed: What|Removed |Added Summary|Radmon rendering|Random rendering |corruptions |corruptions -- 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 V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd
Hello,
On Fri, Aug 17, 2012 at 6:18 AM, Joonyoung Shim wrote:
>
> Hi Leela.
>
> 2012/8/16 Leela Krishna Amudala :
> > The name of the exynos drm fimd device is renamed to exynos-drm-fimd
> > and two device ids are created for exynos4-fb and exynos5-drm-fimd.
> > Also, added driver data for exynos5 to pick the fimd version at runtime
> > and
> > to choose the VIDTCON register offsets accordingly.
> >
> > Signed-off-by: Leela Krishna Amudala
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 56
> > +++---
> > 1 files changed, 51 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 24c0bd4..8379c59 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))
> >
> > +enum fimd_version_type {
> > + VERSION_8, /* FIMD_VERSION8 */
> > +};
> > +
> > +struct drm_fimd_driver_data {
>
> Don't use drm_ prefix for code consistency.
>
Ok, I'll remove the drm_prefix
> > + enum fimd_version_type fimd_ver;
>
> I don't prefer to check using version, it needs many if statement.
> Refer s3c-fb driver and how about use changed base address?
>
> struct fimd_driverdata {
>unsigned inttiming_base;
> };
>
> static struct fimd_driverdata exynos5_fimd_data = {
>.timing_base= 0x2,
> };
>
Ok, If I use the above structure as driver data for exynos5, then the
register write calls look this way
writel(val, ctx->regs + driver_data->timing_base + VIDTCON1);
[driver_data->timing_base = 0x2 in case of exynos5 and 0 in case
of exynos4]
and only one statement is enough for both exynos4 and exynos5.
I had put some effort for the patch set
http://lists.freedesktop.org/archives/dri-devel/2012-August/026076.html
that contains macro definitions for FIMD_V8_VIDCONX and is already
merged to kgene's for-next branch.
If I go with the approach that you suggested then these macros will not be used.
If other reviewers also accepted to use timing_base as driver data,
then will go for it other wise will keep the code same :) .
> > +};
> > +
> > +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
> > + .fimd_ver = VERSION_8,
> > +};
> > +
> > 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 drm_fimd_driver_data *drm_fimd_get_driver_data(
> > + struct platform_device *pdev)
> > +{
> > + return (struct drm_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,47 @@ 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 drm_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);
> > + if (driver_data->fimd_ver == VERSION_8)
> > + writel(ctx->vidcon1, ctx->regs + FIMD_V8_VIDCON1);
> > + else
> > + writel(ctx->vidcon1, ctx->regs + 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);
> > + if (driver_data->fimd_ver == VERSION_8)
> > + writel(val, ctx->regs + FIMD_V8_VIDTCON0);
> > + else
> > + writel(val, ctx->regs + 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);
> > + if (driver_data->fimd_ver == VERSION_8)
> > + writel(val, ctx->regs + FIMD_V8_VIDTCON1);
> > + else
> > + writel(val, ctx->regs + VIDTCON1);
> >
> > /* setup horizontal and vertical display size. */
> > val = VIDTCON2_LINEVAL(timing->yres - 1) |
> >VIDTCON2_HOZVAL(timing->xres - 1);
> > - writel(val, ctx->regs
Re: [PATCH V3 2/2] video: drm: exynos: Add device tree support
Hello,
On Fri, Aug 17, 2012 at 6:55 AM, Joonyoung Shim wrote:
> Hi,
>
> 2012/8/16 Leela Krishna Amudala :
>> Add device tree based discovery support for DRM-FIMD driver.
>>
>> Signed-off-by: Leela Krishna Amudala
>> ---
>> Documentation/devicetree/bindings/fb/drm-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/fb/drm-fimd.txt
>>
>> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
>> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
>> new file mode 100644
>> index 000..8ad8814
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/fb/drm-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-drm" for fimd using DRM frame
>> work.
>
> Just use "samsung,exynos5-fb" and add to support exynos4-fb
>
In the first version of this patch set I used "samsung,exynos5-fb",
but as per Kyungmin Park's suggestion changed it to exynos5-drm.
>> + - 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:
>> + - supports-mipi-panel: Specifies the lcd is mipi panel type
>
> How is this property used?
>
As this driver can be interfaced through MIPI or eDP, Arch side code
will check whether this property is available or not, if it is
available then it assumes mipi panel is connected and certain clock
rate will be set to fimd clock, otherwise assumes other panel is
connected and other clock rate will be set at arch side.
>> + - 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-drm";
>> + 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 8379c59..1753846 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;
>> };
>>
>> +sta
[Bug 53632] Random rendering corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53632 Thomas Rohloff changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #6 from Thomas Rohloff 2012-08-17 09:40:15 UTC --- (In reply to comment #5) > > Do I need the kernel patch, too? > > Yes. The patch seems to fix my issue. Sorry for the trouble. -- 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 00/13] updated exynos-drm-fixes
Hello all, This patch set fixes the following: . fixed page align - page align is done by exynos_drm_gem_create() so do not align in page unit at exynos_drm_gem_dumb_create(). . removed unnecessary dpms call - encoder's mode_set callback isn't specific to hardware so it doesn't need to call exynos_drm_encoder_dpms() . control display power at connector module - it doesn't need that display power is controlled by encoder's dpms so moves it into connector module so that the display power can be controlled by connector's dpms properly. . make sure that hardware overlay for fimd and hdmi is disabled - the values set to registers will be updated into real registers at vsync so dma operation could be malfunctioned when accessed to memory after gem buffer was released. this patch makes sure that hw overlay is disabled before the gem buffer is released. . check NV12M format specific to Exynos properly - this patch adds buf_cnt variable in exynos_drm_fb structure and that means a buffer count to drm framebuffer and also adds two functions to get/set the buffer count from/to exynos_drm_fb structure. if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count to drm framebuffer refering to mode_cmd->handles and offsets. but when booted, the buffer count will always be 1 because pixel format of console framebuffer is RGB format. . updated crtc to plane safely - if old_crtc isn't same as encoder->crtc then it means that user changed crtc id to another one so a plane to old_crtc should be disabled so that current plane can be updated safely and plane->crtc should be set to new crtc(encoder->crtc) And code clean like below: . separated fimd_power_on into some parts - separated fimd_power_on into fimd_activate and fimd_clock functions and fimd_activate function will call fimd_clock to control fimd power and vsync interrupt. . separated subdrv->probe call and encoder/connector creation - with this patch, exynos drm core module can take exception when some operation was failed properly. . changed context name of hdmi and mixer - changed ctx variable name in exynos_drm_hdmi_context structure to client because the use of ctx variable name makes it confused. . fixed build warning Thanks. Inki Dae (13): drm/exynos: added device object to subdrv's remove callback as argument drm/exynos: separated subdrv->probe call and encoder/connector creation. drm/exynos: fixed page align bug. drm/exynos: use empty function instead of drm_helper_connector_dpms drm/exynos: removed exynos_drm_encoder_dpms call drm/exynos: separeated fimd_power_on into some parts. drm/exynos: control display power at connector module. drm/exynos: make sure that hardware overlay for fimd is disabled drm/exynos: check NV12M format specific to Exynos properly drm/exynos: update crtc to plane safely drm/exynos: changed context name of hdmi and mixer drm/exynos: fixed build warning drm/exynos: make sure that hardware overlay for hdmi is disabled drivers/gpu/drm/exynos/exynos_drm_connector.c | 18 +- drivers/gpu/drm/exynos/exynos_drm_core.c | 93 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 19 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 92 +--- drivers/gpu/drm/exynos/exynos_drm_fb.c| 65 - drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 ++ drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 74 ++-- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 47 - drivers/gpu/drm/exynos/exynos_drm_hdmi.h |5 +- drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 12 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 21 +- 15 files changed, 349 insertions(+), 126 deletions(-) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/13] drm/exynos: added device object to subdrv's remove callback as argument
when remove callback of exynos_drm_subdrv is called, it could need
device object for sub driver to control things specific to hw such as
runtime pm.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h |2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e22704b..24c45d8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -266,7 +266,7 @@ struct exynos_drm_subdrv {
struct exynos_drm_manager *manager;
int (*probe)(struct drm_device *drm_dev, struct device *dev);
- void (*remove)(struct drm_device *dev);
+ void (*remove)(struct drm_device *drm_dev, struct device *dev);
int (*open)(struct drm_device *drm_dev, struct device *dev,
struct drm_file *file);
void (*close)(struct drm_device *drm_dev, struct device *dev,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b19cd93..47396e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -678,7 +678,7 @@ static int fimd_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
-static void fimd_subdrv_remove(struct drm_device *drm_dev)
+static void fimd_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 537027a..f900da0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -466,7 +466,7 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev,
struct device *dev)
return 0;
}
-static void vidi_subdrv_remove(struct drm_device *drm_dev)
+static void vidi_subdrv_remove(struct drm_device *drm_dev, struct device *dev)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/13] drm/exynos: separated subdrv->probe call and encoder/connector creation.
this patch separates sub driver's probe call and encoder/connector creation
so that exynos drm core module can take exception when some operation was
failed properly.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c | 93 +-
1 files changed, 65 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 84dd099..1c8d5fe 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -34,30 +34,15 @@
static LIST_HEAD(exynos_drm_subdrv_list);
-static int exynos_drm_subdrv_probe(struct drm_device *dev,
+static int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_subdrv *subdrv)
{
struct drm_encoder *encoder;
struct drm_connector *connector;
+ int ret;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
- if (subdrv->probe) {
- int ret;
-
- /*
-* this probe callback would be called by sub driver
-* after setting of all resources to this sub driver,
-* such as clock, irq and register map are done or by load()
-* of exynos drm driver.
-*
-* P.S. note that this driver is considered for modularization.
-*/
- ret = subdrv->probe(dev, subdrv->dev);
- if (ret)
- return ret;
- }
-
if (!subdrv->manager)
return 0;
@@ -78,24 +63,22 @@ static int exynos_drm_subdrv_probe(struct drm_device *dev,
connector = exynos_drm_connector_create(dev, encoder);
if (!connector) {
DRM_ERROR("failed to create connector\n");
- encoder->funcs->destroy(encoder);
- return -EFAULT;
+ ret = -EFAULT;
+ goto err_destroy_encoder;
}
subdrv->encoder = encoder;
subdrv->connector = connector;
return 0;
+
+err_destroy_encoder:
+ encoder->funcs->destroy(encoder);
+ return ret;
}
-static void exynos_drm_subdrv_remove(struct drm_device *dev,
- struct exynos_drm_subdrv *subdrv)
+static void exynos_drm_destroy_enc_conn(struct exynos_drm_subdrv *subdrv)
{
- DRM_DEBUG_DRIVER("%s\n", __FILE__);
-
- if (subdrv->remove)
- subdrv->remove(dev);
-
if (subdrv->encoder) {
struct drm_encoder *encoder = subdrv->encoder;
encoder->funcs->destroy(encoder);
@@ -109,9 +92,48 @@ static void exynos_drm_subdrv_remove(struct drm_device *dev,
}
}
+static int exynos_drm_subdrv_probe(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ if (subdrv->probe) {
+ int ret;
+
+ subdrv->drm_dev = dev;
+
+ /*
+* this probe callback would be called by sub driver
+* after setting of all resources to this sub driver,
+* such as clock, irq and register map are done or by load()
+* of exynos drm driver.
+*
+* P.S. note that this driver is considered for modularization.
+*/
+ ret = subdrv->probe(dev, subdrv->dev);
+ if (ret)
+ return ret;
+ }
+
+ if (!subdrv->manager)
+ return -EINVAL;
+
+ subdrv->manager->dev = subdrv->dev;
+
+ return 0;
+}
+
+static void exynos_drm_subdrv_remove(struct drm_device *dev,
+ struct exynos_drm_subdrv *subdrv)
+{
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+ if (subdrv->remove)
+ subdrv->remove(dev, subdrv->dev);
+}
+
int exynos_drm_device_register(struct drm_device *dev)
{
struct exynos_drm_subdrv *subdrv, *n;
+ unsigned int fine_cnt = 0;
int err;
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -120,14 +142,27 @@ int exynos_drm_device_register(struct drm_device *dev)
return -EINVAL;
list_for_each_entry_safe(subdrv, n, &exynos_drm_subdrv_list, list) {
- subdrv->drm_dev = dev;
err = exynos_drm_subdrv_probe(dev, subdrv);
if (err) {
DRM_DEBUG("exynos drm subdrv probe failed.\n");
list_del(&subdrv->list);
+ continue;
}
+
+ err = exynos_drm_create_enc_conn(dev, subdrv);
+ if (err) {
+ DRM_DEBUG("failed to create encoder and connector.\n");
+ exynos_drm_subdrv_remove(dev, subdrv);
+ list_del(&subdrv->list);
+ continue;
+ }
+
+ fine_cnt++;
}
+
[PATCH 03/13] drm/exynos: fixed page align bug.
do not align in page unit at dumb creation. the align is done by exynos_drm_gem_create() to be called commonly. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_gem.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c b/drivers/gpu/drm/exynos/exynos_drm_gem.c index da4e3ca..a38051c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c @@ -662,7 +662,7 @@ int exynos_drm_gem_dumb_create(struct drm_file *file_priv, */ args->pitch = args->width * ((args->bpp + 7) / 8); - args->size = PAGE_ALIGN(args->pitch * args->height); + args->size = args->pitch * args->height; exynos_gem_obj = exynos_drm_gem_create(dev, args->flags, args->size); if (IS_ERR(exynos_gem_obj)) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/13] drm/exynos: use empty function instead of drm_helper_connector_dpms
crtc and encoder's dpms callback will be called before connector's dpms
is called so drm_helper_connector_dpms doesn't need to be called.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index d956819..65acf0d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -226,6 +226,13 @@ static struct drm_connector_helper_funcs
exynos_connector_helper_funcs = {
.best_encoder = exynos_drm_best_encoder,
};
+static void exynos_drm_connector_dpms(struct drm_connector *connector, int
mode)
+{
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ /* drm framework doesn't check NULL. */
+}
+
static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
unsigned int max_width, unsigned int max_height)
{
@@ -285,7 +292,7 @@ static void exynos_drm_connector_destroy(struct
drm_connector *connector)
}
static struct drm_connector_funcs exynos_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = exynos_drm_connector_dpms,
.fill_modes = exynos_drm_connector_fill_modes,
.detect = exynos_drm_connector_detect,
.destroy= exynos_drm_connector_destroy,
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/13] drm/exynos: removed exynos_drm_encoder_dpms call
encoder's mode_set callback isn't specific to hardware so it doesn't
need to call exynos_drm_encoder_dpms().
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 2c037cd..3dae250 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -138,8 +138,6 @@ static void exynos_drm_encoder_mode_set(struct drm_encoder
*encoder,
DRM_DEBUG_KMS("%s\n", __FILE__);
- exynos_drm_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
-
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->encoder == encoder)
if (manager_ops && manager_ops->mode_set)
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/13] drm/exynos: separeated fimd_power_on into some parts.
this patch separetes fimd_power_on into fimd_activate and fimd_clock and
fimd_activate function will call fimd_clock to control fimd power and
vsync interrupt.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 60 --
1 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 47396e1..0ec9d86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -747,16 +747,10 @@ static void fimd_clear_win(struct fimd_context *ctx, int
win)
writel(val, ctx->regs + SHADOWCON);
}
-static int fimd_power_on(struct fimd_context *ctx, bool enable)
+static int fimd_clock(struct fimd_context *ctx, bool enable)
{
- struct exynos_drm_subdrv *subdrv = &ctx->subdrv;
- struct device *dev = subdrv->dev;
-
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (enable != false && enable != true)
- return -EINVAL;
-
if (enable) {
int ret;
@@ -769,18 +763,31 @@ static int fimd_power_on(struct fimd_context *ctx, bool
enable)
clk_disable(ctx->bus_clk);
return ret;
}
+ } else {
+ clk_disable(ctx->lcd_clk);
+ clk_disable(ctx->bus_clk);
+ }
- ctx->suspended = false;
+ return 0;
+}
+
+static int fimd_activate(struct fimd_context *ctx, bool enable)
+{
+ if (enable) {
+ int ret;
+ struct device *dev = ctx->subdrv.dev;
+
+ ret = fimd_clock(ctx, true);
+ if (ret < 0)
+ return ret;
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, &ctx->irq_flags))
fimd_enable_vblank(dev);
- fimd_apply(dev);
+ ctx->suspended = false;
} else {
- clk_disable(ctx->lcd_clk);
- clk_disable(ctx->bus_clk);
-
+ fimd_clock(ctx, false);
ctx->suspended = true;
}
@@ -930,15 +937,15 @@ static int fimd_suspend(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
- if (pm_runtime_suspended(dev))
- return 0;
-
/*
* do not use pm_runtime_suspend(). if pm_runtime_suspend() is
* called here, an error would be returned by that interface
* because the usage_count of pm runtime is more than 1.
*/
- return fimd_power_on(ctx, false);
+ if (!pm_runtime_suspended(dev))
+ return fimd_activate(ctx, false);
+
+ return 0;
}
static int fimd_resume(struct device *dev)
@@ -950,8 +957,21 @@ static int fimd_resume(struct device *dev)
* of pm runtime would still be 1 so in this case, fimd driver
* should be on directly not drawing on pm runtime interface.
*/
- if (!pm_runtime_suspended(dev))
- return fimd_power_on(ctx, true);
+ if (pm_runtime_suspended(dev)) {
+ int ret;
+
+ ret = fimd_activate(ctx, false);
+ if (ret < 0)
+ return ret;
+
+ /*
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
+*/
+ fimd_apply(dev);
+ }
return 0;
}
@@ -964,7 +984,7 @@ static int fimd_runtime_suspend(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, false);
+ return fimd_activate(ctx, false);
}
static int fimd_runtime_resume(struct device *dev)
@@ -973,7 +993,7 @@ static int fimd_runtime_resume(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
- return fimd_power_on(ctx, true);
+ return fimd_activate(ctx, true);
}
#endif
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/13] drm/exynos: control display power at connector module.
it doesn't need that display power is controlled by encoder's dpms so
moves it into connector module so that the display power can be controlled
by connector's dpms propely.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 11 ++-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 21 -
2 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 65acf0d..d2ac6ed 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -226,11 +226,20 @@ static struct drm_connector_helper_funcs
exynos_connector_helper_funcs = {
.best_encoder = exynos_drm_best_encoder,
};
+static void exynos_drm_display_power(struct drm_encoder *encoder, int mode)
+{
+ struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
+ struct exynos_drm_display_ops *display_ops = manager->display_ops;
+
+ if (display_ops && display_ops->power_on)
+ display_ops->power_on(manager->dev, mode);
+}
+
static void exynos_drm_connector_dpms(struct drm_connector *connector, int
mode)
{
DRM_DEBUG_KMS("%s\n", __FILE__);
- /* drm framework doesn't check NULL. */
+ exynos_drm_display_power(connector->encoder, mode);
}
static int exynos_drm_connector_fill_modes(struct drm_connector *connector,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 3dae250..7da5714 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -49,25 +49,6 @@ struct exynos_drm_encoder {
int dpms;
};
-static void exynos_drm_display_power(struct drm_encoder *encoder, int mode)
-{
- struct drm_device *dev = encoder->dev;
- struct drm_connector *connector;
- struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
-
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->encoder == encoder) {
- struct exynos_drm_display_ops *display_ops =
- manager->display_ops;
-
- DRM_DEBUG_KMS("connector[%d] dpms[%d]\n",
- connector->base.id, mode);
- if (display_ops && display_ops->power_on)
- display_ops->power_on(manager->dev, mode);
- }
- }
-}
-
static void exynos_drm_encoder_dpms(struct drm_encoder *encoder, int mode)
{
struct drm_device *dev = encoder->dev;
@@ -88,13 +69,11 @@ static void exynos_drm_encoder_dpms(struct drm_encoder
*encoder, int mode)
case DRM_MODE_DPMS_ON:
if (manager_ops && manager_ops->apply)
manager_ops->apply(manager->dev);
- exynos_drm_display_power(encoder, mode);
exynos_encoder->dpms = mode;
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
- exynos_drm_display_power(encoder, mode);
exynos_encoder->dpms = mode;
break;
default:
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/13] drm/exynos: make sure that hardware overlay for fimd is disabled
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 10 ++
drivers/gpu/drm/exynos/exynos_drm_fimd.c| 12
3 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 24c45d8..00e4bdc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -37,6 +37,20 @@
#define MAX_FB_BUFFER 4
#define DEFAULT_ZPOS -1
+#define _wait_for(COND, MS) ({ \
+ unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
+ int ret__ = 0; \
+ while (!(COND)) { \
+ if (time_after(jiffies, timeout__)) { \
+ ret__ = -ETIMEDOUT; \
+ break; \
+ } \
+ } \
+ ret__; \
+})
+
+#define wait_for(COND, MS) _wait_for(COND, MS)
+
struct drm_device;
struct exynos_drm_overlay;
struct drm_connector;
@@ -61,6 +75,8 @@ enum exynos_drm_output_type {
* @commit: apply hardware specific overlay data to registers.
* @enable: enable hardware specific overlay.
* @disable: disable hardware specific overlay.
+ * @wait_for_vblank: wait for vblank interrupt to make sure that
+ * dma transfer is completed.
*/
struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
@@ -68,6 +84,7 @@ struct exynos_drm_overlay_ops {
void (*commit)(struct device *subdrv_dev, int zpos);
void (*enable)(struct device *subdrv_dev, int zpos);
void (*disable)(struct device *subdrv_dev, int zpos);
+ void (*wait_for_vblank)(struct device *subdrv_dev);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 7da5714..a562a94 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -399,4 +399,14 @@ void exynos_drm_encoder_plane_disable(struct drm_encoder
*encoder, void *data)
if (overlay_ops && overlay_ops->disable)
overlay_ops->disable(manager->dev, zpos);
+
+ /*
+* wait for vblank interrupt
+* - with iommu, the dma operation could induce page fault
+* when accessed to memory after gem buffer was released so
+* make sure that the dma operation is completed before releasing
+* the gem bufer.
+*/
+ if (overlay_ops->wait_for_vblank)
+ overlay_ops->wait_for_vblank(manager->dev);
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0ec9d86..2378d80 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -570,10 +570,22 @@ static void fimd_win_disable(struct device *dev, int zpos)
win_data->enabled = false;
}
+static void fimd_wait_for_vblank(struct device *dev)
+{
+ struct fimd_context *ctx = get_fimd_context(dev);
+ int ret;
+
+ ret = wait_for((__raw_readl(ctx->regs + VIDCON1) &
+ VIDCON1_VSTATUS_BACKPORCH), 50);
+ if (ret < 0)
+ DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
static struct exynos_drm_overlay_ops fimd_overlay_ops = {
.mode_set = fimd_win_mode_set,
.commit = fimd_win_commit,
.disable = fimd_win_disable,
+ .wait_for_vblank = fimd_wait_for_vblank,
};
static struct exynos_drm_manager fimd_manager = {
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/13] drm/exynos: check NV12M format specific to Exynos properly
this patch adds buf_cnt variable in exynos_drm_fb structure and
that means a buffer count to drm framebuffer and also adds two
functions to get/set the buffer count from/to exynos_drm_fb structure.
if pixel format is not DRM_FORMAT_NV12MT then it gets a buffer count
to drm framebuffer refering to mode_cmd->handles and offsets.
but when booted, the buffer count will always be 1 because pixel
format of console framebuffer is RGB format.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 65 +++-
drivers/gpu/drm/exynos/exynos_drm_fb.h| 20 +++--
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |3 +
drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +-
4 files changed, 73 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 4ccfe43..2d1bc3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -41,10 +41,12 @@
* exynos specific framebuffer structure.
*
* @fb: drm framebuffer obejct.
+ * @buf_cnt: a buffer count to drm framebuffer.
* @exynos_gem_obj: array of exynos specific gem object containing a gem
object.
*/
struct exynos_drm_fb {
struct drm_framebuffer fb;
+ unsigned intbuf_cnt;
struct exynos_drm_gem_obj *exynos_gem_obj[MAX_FB_BUFFER];
};
@@ -101,6 +103,25 @@ static struct drm_framebuffer_funcs exynos_drm_fb_funcs = {
.dirty = exynos_drm_fb_dirty,
};
+void exynos_drm_fb_set_buf_cnt(struct drm_framebuffer *fb,
+ unsigned int cnt)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ exynos_fb->buf_cnt = cnt;
+}
+
+unsigned int exynos_drm_fb_get_buf_cnt(struct drm_framebuffer *fb)
+{
+ struct exynos_drm_fb *exynos_fb;
+
+ exynos_fb = to_exynos_fb(fb);
+
+ return exynos_fb->buf_cnt;
+}
+
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -127,6 +148,43 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
return &exynos_fb->fb;
}
+static u32 exynos_drm_format_num_buffers(struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ unsigned int cnt = 0;
+
+ if (mode_cmd->pixel_format == DRM_FORMAT_NV12MT)
+ return 2;
+
+ while (cnt != MAX_FB_BUFFER) {
+ if (!mode_cmd->handles[cnt])
+ break;
+ cnt++;
+ }
+
+ /*
+* check if NV12 or NV12M.
+*
+* NV12
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base1, offsets[1] = Y_size
+*
+* NV12M
+* handles[0] = base1, offsets[0] = 0
+* handles[1] = base2, offsets[1] = 0
+*/
+ if (cnt == 2) {
+ /*
+* in case of NV12 format, offsets[1] is not 0 and
+* handles[0] is same as handles[1].
+*/
+ if (mode_cmd->offsets[1] &&
+ mode_cmd->handles[0] == mode_cmd->handles[1])
+ cnt = 1;
+ }
+
+ return cnt;
+}
+
static struct drm_framebuffer *
exynos_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
struct drm_mode_fb_cmd2 *mode_cmd)
@@ -134,7 +192,6 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
struct drm_gem_object *obj;
struct drm_framebuffer *fb;
struct exynos_drm_fb *exynos_fb;
- int nr;
int i;
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -152,9 +209,11 @@ exynos_user_fb_create(struct drm_device *dev, struct
drm_file *file_priv,
}
exynos_fb = to_exynos_fb(fb);
- nr = exynos_drm_format_num_buffers(fb->pixel_format);
+ exynos_fb->buf_cnt = exynos_drm_format_num_buffers(mode_cmd);
+
+ DRM_DEBUG_KMS("buf_cnt = %d\n", exynos_fb->buf_cnt);
- for (i = 1; i < nr; i++) {
+ for (i = 1; i < exynos_fb->buf_cnt; i++) {
obj = drm_gem_object_lookup(dev, file_priv,
mode_cmd->handles[i]);
if (!obj) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.h
b/drivers/gpu/drm/exynos/exynos_drm_fb.h
index 5082375..96262e5 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
@@ -28,19 +28,6 @@
#ifndef _EXYNOS_DRM_FB_H_
#define _EXYNOS_DRM_FB_H
-static inline int exynos_drm_format_num_buffers(uint32_t format)
-{
- switch (format) {
- case DRM_FORMAT_NV12:
- case DRM_FORMAT_NV12MT:
- return 2;
- case DRM_FORMAT_YUV420:
- return 3;
- default:
- return 1;
- }
-}
-
struct drm_framebuffer *
exynos_drm_framebuffer_init(struct drm_device *dev,
[PATCH 10/13] drm/exynos: update crtc to plane safely
if old_crtc isn't same as encoder->crtc then it means that
user changed crtc id to another one so a plane to old_crtc
should be disabled so that current plane can be updated safely
and plane->crtc should be set to new crtc(encoder->crtc)
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 59 +-
1 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index a562a94..7bcace8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -44,6 +44,7 @@
* @dpms: store the encoder dpms value.
*/
struct exynos_drm_encoder {
+ struct drm_crtc *old_crtc;
struct drm_encoder drm_encoder;
struct exynos_drm_manager *manager;
int dpms;
@@ -106,22 +107,74 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder *encoder,
return true;
}
+static void disable_plane_to_crtc(struct drm_device *dev,
+ struct drm_crtc *old_crtc,
+ struct drm_crtc *new_crtc)
+{
+ struct drm_plane *plane;
+
+ /*
+* if old_crtc isn't same as encoder->crtc then it means that
+* user changed crtc id to another one so the plane to old_crtc
+* should be disabled and plane->crtc should be set to new_crtc
+* (encoder->crtc)
+*/
+ list_for_each_entry(plane, &dev->mode_config.plane_list, head) {
+ if (plane->crtc == old_crtc) {
+ /*
+* do not change below call order.
+*
+* plane->funcs->disable_plane call checks
+* if encoder->crtc is same as plane->crtc and if same
+* then overlay_ops->disable callback will be called
+* to diasble current hw overlay so plane->crtc should
+* have new_crtc because new_crtc was set to
+* encoder->crtc in advance.
+*/
+ plane->crtc = new_crtc;
+ plane->funcs->disable_plane(plane);
+ }
+ }
+}
+
static void exynos_drm_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_device *dev = encoder->dev;
struct drm_connector *connector;
- struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
- struct exynos_drm_manager_ops *manager_ops = manager->ops;
+ struct exynos_drm_manager *manager;
+ struct exynos_drm_manager_ops *manager_ops;
DRM_DEBUG_KMS("%s\n", __FILE__);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->encoder == encoder)
+ if (connector->encoder == encoder) {
+ struct exynos_drm_encoder *exynos_encoder;
+
+ exynos_encoder = to_exynos_encoder(encoder);
+
+ if (exynos_encoder->old_crtc != encoder->crtc &&
+ exynos_encoder->old_crtc) {
+
+ /*
+* disable a plane to old crtc and change
+* crtc of the plane to new one.
+*/
+ disable_plane_to_crtc(dev,
+ exynos_encoder->old_crtc,
+ encoder->crtc);
+ }
+
+ manager = exynos_drm_get_manager(encoder);
+ manager_ops = manager->ops;
+
if (manager_ops && manager_ops->mode_set)
manager_ops->mode_set(manager->dev,
adjusted_mode);
+
+ exynos_encoder->old_crtc = encoder->crtc;
+ }
}
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/13] drm/exynos: changed context name of hdmi and mixer
this patch changes ctx variable name in exynos_drm_hdmi_context
structure to client because the use of ctx variable makes it confused.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 38 +++---
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |4 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 12
drivers/gpu/drm/exynos/exynos_mixer.c|8 +++---
4 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3fdf0b6..bced38e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -64,7 +64,7 @@ static bool drm_hdmi_is_connected(struct device *dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->is_connected)
- return hdmi_ops->is_connected(ctx->hdmi_ctx->ctx);
+ return hdmi_ops->is_connected(ctx->hdmi_ctx->client);
return false;
}
@@ -77,8 +77,8 @@ static int drm_hdmi_get_edid(struct device *dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->get_edid)
- return hdmi_ops->get_edid(ctx->hdmi_ctx->ctx, connector, edid,
- len);
+ return hdmi_ops->get_edid(ctx->hdmi_ctx->client, connector,
+ edid, len);
return 0;
}
@@ -90,7 +90,7 @@ static int drm_hdmi_check_timing(struct device *dev, void
*timing)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->check_timing)
- return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
+ return hdmi_ops->check_timing(ctx->hdmi_ctx->client, timing);
return 0;
}
@@ -102,7 +102,7 @@ static int drm_hdmi_power_on(struct device *dev, int mode)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->power_on)
- return hdmi_ops->power_on(ctx->hdmi_ctx->ctx, mode);
+ return hdmi_ops->power_on(ctx->hdmi_ctx->client, mode);
return 0;
}
@@ -124,7 +124,7 @@ static int drm_hdmi_enable_vblank(struct device *subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (mixer_ops && mixer_ops->enable_vblank)
- return mixer_ops->enable_vblank(ctx->mixer_ctx->ctx,
+ return mixer_ops->enable_vblank(ctx->mixer_ctx->client,
manager->pipe);
return 0;
@@ -137,12 +137,12 @@ static void drm_hdmi_disable_vblank(struct device
*subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (mixer_ops && mixer_ops->disable_vblank)
- return mixer_ops->disable_vblank(ctx->mixer_ctx->ctx);
+ return mixer_ops->disable_vblank(ctx->mixer_ctx->client);
}
static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
- const struct drm_display_mode *mode,
+ struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
@@ -150,7 +150,7 @@ static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->mode_fixup)
- hdmi_ops->mode_fixup(ctx->hdmi_ctx->ctx, connector, mode,
+ hdmi_ops->mode_fixup(ctx->hdmi_ctx->client, connector, mode,
adjusted_mode);
}
@@ -161,7 +161,7 @@ static void drm_hdmi_mode_set(struct device *subdrv_dev,
void *mode)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->mode_set)
- hdmi_ops->mode_set(ctx->hdmi_ctx->ctx, mode);
+ hdmi_ops->mode_set(ctx->hdmi_ctx->client, mode);
}
static void drm_hdmi_get_max_resol(struct device *subdrv_dev,
@@ -172,7 +172,7 @@ static void drm_hdmi_get_max_resol(struct device
*subdrv_dev,
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->get_max_resol)
- hdmi_ops->get_max_resol(ctx->hdmi_ctx->ctx, width, height);
+ hdmi_ops->get_max_resol(ctx->hdmi_ctx->client, width, height);
}
static void drm_hdmi_commit(struct device *subdrv_dev)
@@ -182,7 +182,7 @@ static void drm_hdmi_commit(struct device *subdrv_dev)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (hdmi_ops && hdmi_ops->commit)
- hdmi_ops->commit(ctx->hdmi_ctx->ctx);
+ hdmi_ops->commit(ctx->hdmi_ctx->client);
}
static void drm_hdmi_dpms(struct device *subdrv_dev, int mode)
@@ -192,10 +192,10 @@ static void drm_hdmi_dpms(struct device *subdrv_dev, int
mode)
DRM_DEBUG_KMS("%s\n", __FILE__);
if (mixer_ops && mixer_ops->dpms)
- mixer_ops->dpms(ctx->mixer_ctx->ctx, mod
[PATCH 12/13] drm/exynos: fixed build warning
the argument of drm_hdmi_mode_fixup function, struct drm_display_mode
should be declared as const.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index bced38e..38250cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -142,7 +142,7 @@ static void drm_hdmi_disable_vblank(struct device
*subdrv_dev)
static void drm_hdmi_mode_fixup(struct device *subdrv_dev,
struct drm_connector *connector,
- struct drm_display_mode *mode,
+ const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct drm_hdmi_context *ctx = to_context(subdrv_dev);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/13] drm/exynos: make sure that hardware overlay for hdmi is disabled
the values set to registers will be updated into real registers
at vsync so dma operation could be malfunctioned when accessed
to memory after gem buffer was released. this patch makes sure
that hw overlay is disabled before the gem buffer is released.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 11 +++
drivers/gpu/drm/exynos/exynos_drm_hdmi.h |1 +
drivers/gpu/drm/exynos/exynos_mixer.c| 13 +
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 38250cb..6323cc8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -274,10 +274,21 @@ static void drm_mixer_disable(struct device *subdrv_dev,
int zpos)
ctx->enabled[win] = false;
}
+static void drm_mixer_wait_for_vblank(struct device *subdrv_dev)
+{
+ struct drm_hdmi_context *ctx = to_context(subdrv_dev);
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ if (mixer_ops && mixer_ops->wait_for_vblank)
+ mixer_ops->wait_for_vblank(ctx->mixer_ctx->client);
+}
+
static struct exynos_drm_overlay_ops drm_hdmi_overlay_ops = {
.mode_set = drm_mixer_mode_set,
.commit = drm_mixer_commit,
.disable = drm_mixer_disable,
+ .wait_for_vblank = drm_mixer_wait_for_vblank,
};
static struct exynos_drm_manager hdmi_manager = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 237434d..93e8a2b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -67,6 +67,7 @@ struct exynos_mixer_ops {
void (*dpms)(void *ctx, int mode);
/* overlay */
+ void (*wait_for_vblank)(void *ctx);
void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
void (*win_commit)(void *ctx, int zpos);
void (*win_disable)(void *ctx, int zpos);
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d3ff595..1ab5267 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -726,6 +726,18 @@ static void mixer_dpms(void *ctx, int mode)
}
}
+static void mixer_wait_for_vblank(void *ctx)
+{
+ struct mixer_context *mixer_ctx = ctx;
+ struct mixer_resources *res = &mixer_ctx->mixer_res;
+ int ret;
+
+ ret = wait_for((mixer_reg_read(res, MXR_INT_STATUS) &
+ MXR_INT_STATUS_VSYNC), 50);
+ if (ret < 0)
+ DRM_DEBUG_KMS("vblank wait timed out.\n");
+}
+
static void mixer_win_mode_set(void *ctx,
struct exynos_drm_overlay *overlay)
{
@@ -818,6 +830,7 @@ static struct exynos_mixer_ops mixer_ops = {
.dpms = mixer_dpms,
/* overlay */
+ .wait_for_vblank= mixer_wait_for_vblank,
.win_mode_set = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53630] compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 --- Comment #1 from Thomas Rohloff 2012-08-17 09:53:47 UTC --- Created attachment 65683 --> https://bugs.freedesktop.org/attachment.cgi?id=65683 Desktop without glamor (good rendering) -- 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 53630] compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 --- Comment #2 from Thomas Rohloff 2012-08-17 09:55:05 UTC --- Created attachment 65685 --> https://bugs.freedesktop.org/attachment.cgi?id=65685 Desktop with glamor (bad rendering) -- 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 53630] compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 --- Comment #3 from Thomas Rohloff 2012-08-17 09:58:29 UTC --- Created attachment 65687 --> https://bugs.freedesktop.org/attachment.cgi?id=65687 Compiz loading As you see here (and at the screenshots) the colors are wrong, too (red to blue, for example). I tried to get the same corruption I described earlier, but was unable to do so (well, it's basically the same but without the wrong colors). -- 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: [RFC 3/5] video: panel: Add MIPI DBI bus support
Hi Tomi,
Thank you for the review.
On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > +/*
> > -
> > + * Bus operations
> > + */
> > +
> > +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long
> > cmd) +{
> > + dev->bus->ops->write_command(dev->bus, cmd);
> > +}
> > +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> > +
> > +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
> > data) +{
> > + dev->bus->ops->write_data(dev->bus, data);
> > +}
> > +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> > +
> > +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> > +{
> > + return dev->bus->ops->read_data(dev->bus);
> > +}
> > +EXPORT_SYMBOL_GPL(panel_dbi_read_data);
>
> I'm not that familiar with how to implement bus drivers, can you
> describe in pseudo code how the SoC's DBI driver would register these?
Sure.
The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
.write_command = lcdc_dbi_write_command,
.write_data = lcdc_dbi_write_data,
.read_data = lcdc_dbi_read_data,
};
and a panel_dbi_bus instance, usually embedded in its private driver data
structure, and initialize it by setting its dev and ops fields:
ch->dbi_bus.dev = ch->lcdc->dev;
ch->dbi_bus.ops = &sh_mobile_lcdc_dbi_bus_ops;
In my current implementation, the panel_dbi_device is created in board code:
static struct panel_dbi_device migor_panel_device = {
.name = "r61505",
.id = 0,
.dev= {
.platform_data = &migor_panel_info,
},
};
A pointer to that structure is passed to the DBI master driver, which then
registers the device:
panel_dbi_device_register(dbi, &ch->dbi_bus);
With a DT-based solution the DBI core will expose a function to register DBI
devices from OF nodes.
The bus itself is currently not registered with the DBI code because there was
no need to.
> I think write/read data functions are a bit limited. Shouldn't they be
> something like write_data(const u8 *buf, int size) and read_data(u8
> *buf, int len)?
Good point. My hardware doesn't support multi-byte read/write operations
directly so I haven't thought about adding those.
Can your hardware group command + data writes in a single operation ? If so we
should expose that at the API level as well.
Is DBI limited to 8-bit data transfers for commands ? Pixels can be
transferred 16-bit at a time, commands might as well. While DCS only specifies
8-bit command/data, DBI panels that are not DCS compliant can use 16-bit
command/data (the R61505 panel, albeit a SYS-80 panel, does so).
> Something that's totally missing is configuring the DBI bus. There are a
> bunch of timing related values that need to be configured. See
> include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
> specific, if I recall right most of the values match to the MIPI DBI
> spec.
I've left that out currently, and thought about passing that information as
platform data to the DBI bus driver. That's the easiest solution, but I agree
that it's a hack. Panel should expose their timing requirements to the DBI
host. API wise that wouldn't be difficult (we only need to add timing
information to the panel platform data and add a function to the DBI API to
retrieve it), one of challenges might be to express it in a way that's both
universal enough and easy to use for DBI bus drivers.
> And this makes me wonder, you use DBI bus for SYS-80 panel. The busses
> may look similar in operation, but are they really so similar when you
> take into account the timings (and perhaps something else, it's been
> years since I read the MIPI DBI spec)?
I'll have to check all the details. SYS-80 is similar to DBI-B, but supports a
wider bus width of 18 bits. I think the interfaces are similar enough to use a
single bus implementation, possibly with quirks and/or options (see SCCB
support in I2C for instance, with flags to ignore acks, force a stop bit
generation, ...). We would duplicate lots of code if we had two different
implementations, and would prevent a DBI panel to be attached to a SYS-80 host
and vice-versa (the format is known to work).
> Then there's the start_transfer. This is something I'm not sure what is
> the best way to handle it, but the same problems that I mentioned in the
> previous post related to enable apply here also. For example, what if
> the panel needs to be update in two parts? This is done in Nokia N9.
> From panel's perspective, it'd be best to handle it somewhat like this
> (although asynchronously, probably):
>
> write_update_area(0, 0, xres, yres / 2);
> write_memory_start()
> start_pixel_transfer();
>
> wait_transfer_done();
>
> write_update_area(0,
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #48 from gy...@gmx.de 2012-08-17 10:09:17 UTC --- (In reply to comment #46) > Created attachment 65659 [details] [review] > fix for all kernels > > Here's the patch broken out which should apply to all recent kernels. for kernel 3.5rc7 i needed additional this part in radeon_bios.c: *** 32,37 --- 32,40 #include #include + #ifdef CONFIG_ACPI + #include + #endif /* * BIOS. */ -- 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 53630] compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 --- Comment #4 from Michel Dänzer 2012-08-17 10:10:45 UTC --- Does this still occur with the kernel fix from bug 45018? -- 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 53630] compiz + glamor = screen corruptions
https://bugs.freedesktop.org/show_bug.cgi?id=53630 --- Comment #5 from Thomas Rohloff 2012-08-17 10:25:00 UTC --- (In reply to comment #4) > Does this still occur with the kernel fix from bug 45018? Yes. -- 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: [RFC 3/5] video: panel: Add MIPI DBI bus support
On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the review.
>
> On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
> > On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > > +/*
> > > -
> > > + * Bus operations
> > > + */
> > > +
> > > +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long
> > > cmd) +{
> > > + dev->bus->ops->write_command(dev->bus, cmd);
> > > +}
> > > +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> > > +
> > > +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
> > > data) +{
> > > + dev->bus->ops->write_data(dev->bus, data);
> > > +}
> > > +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> > > +
> > > +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> > > +{
> > > + return dev->bus->ops->read_data(dev->bus);
> > > +}
> > > +EXPORT_SYMBOL_GPL(panel_dbi_read_data);
> >
> > I'm not that familiar with how to implement bus drivers, can you
> > describe in pseudo code how the SoC's DBI driver would register these?
>
> Sure.
>
> The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
>
> static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
> .write_command = lcdc_dbi_write_command,
> .write_data = lcdc_dbi_write_data,
> .read_data = lcdc_dbi_read_data,
> };
Thanks for the example, I think it cleared up things a bit.
As I mentioned earlier, I really think "panel" is not right here. While
the whole framework may be called panel framework, the bus drivers are
not panels, and we should support external chips also, which are not
panels either.
> > I think write/read data functions are a bit limited. Shouldn't they be
> > something like write_data(const u8 *buf, int size) and read_data(u8
> > *buf, int len)?
>
> Good point. My hardware doesn't support multi-byte read/write operations
> directly so I haven't thought about adding those.
OMAP HW doesn't support it either. Well, not quite true, as OMAP's
system DMA could be used to write a buffer to the DBI output. But that's
really the same as doing the write with a a loop with CPU.
But first, the data type should be byte, not unsigned long. How would
you write 8 bits or 16 bits with your API? And second, if the function
takes just u8, you'd need lots of calls to do simple writes.
> Can your hardware group command + data writes in a single operation ? If so
> we
> should expose that at the API level as well.
No it can't. But with DCS that is a common operation, so we could have
some helpers to send command + data with one call. Then again, I'd hope
to have DCS somehow as a separate library, which would then use
DBI/DSI/whatnot to actually send the data.
I'm not quite sure how easy that is because of the differences between
the busses.
> Is DBI limited to 8-bit data transfers for commands ? Pixels can be
> transferred 16-bit at a time, commands might as well. While DCS only
> specifies
> 8-bit command/data, DBI panels that are not DCS compliant can use 16-bit
> command/data (the R61505 panel, albeit a SYS-80 panel, does so).
I have to say I don't remember much about DBI =). Looking at OMAP's
driver, which was made for omap2 and hasn't been much updated since, I
see that there are 4 modes, 8/9/12/16 bits. I think that defines how
many of the parallel data lines are used.
However, I don't think that matters for the panel driver when it wants
to send data. The panel driver should just call dbi_write(buf, buf_len),
and the dbi driver would send the data in the buffer according to the
bus width.
Also note that some chips need to change the bus width on the fly. The
chip used on N800 wants configuration to be done with 8-bits, and pixel
transfers with 16-bits. Who knows why...
So I think this, and generally most of the configuration, should be
somewhat dynamic, so that the panel driver can change them when it
needs.
> > Something that's totally missing is configuring the DBI bus. There are a
> > bunch of timing related values that need to be configured. See
> > include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
> > specific, if I recall right most of the values match to the MIPI DBI
> > spec.
>
> I've left that out currently, and thought about passing that information as
> platform data to the DBI bus driver. That's the easiest solution, but I agree
> that it's a hack. Panel should expose their timing requirements to the DBI
> host. API wise that wouldn't be difficult (we only need to add timing
> information to the panel platform data and add a function to the DBI API to
> retrieve it), one of challenges might be to express it in a way that's both
> universal enough and easy to use for DBI bus drivers.
As I pointed above, I think the panel driver shouldn't expose it, but
the panel driver should somehow set it. Or at least allowed to change it
in some manner. This is actually
[Bug 30052] [BISECTED]Fails to start X with intel+Ati video, whith modeset=1
https://bugzilla.kernel.org/show_bug.cgi?id=30052 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Summary|Fails to start X with |[BISECTED]Fails to start X |intel+Ati video, whith |with intel+Ati video, whith |modeset=1 |modeset=1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30102] [RADEON:KMS:RS780:CP] ring test failed
https://bugzilla.kernel.org/show_bug.cgi?id=30102 Alan changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lxorguk.ukuu.org.uk Resolution||OBSOLETE --- Comment #4 from Alan 2012-08-17 10:58:28 --- If this is still seen with a modern kernel (3.2+ etc) please update/re-open -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/5] Generic panel framework
Hi Tomi, Thanks a lot for the review. On Friday 17 August 2012 11:38:14 Tomi Valkeinen wrote: > On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote: > > I will appreciate all reviews, comments, criticisms, ideas, remarks, ... > > If > > Oookay, where to start... ;) > > A few cosmetic/general comments first. > > I find the file naming a bit strange. You have panel.c, which is the > core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which > is driver for r61517 panel... > > Perhaps something in this direction (in order): panel-core.c, > mipi-dbi-bus.c, panel-r61517.c? That looks good to me. I'll then rename panel_dbi_* to mipi_dbi_*. > And we probably end up with quite a lot of panel drivers, perhaps we should > already divide these into separate directories, and then we wouldn't need to > prefix each panel with "panel-" at all. What kind of directory structure do you have in mind ? Panels are already isolated in drivers/video/panel/ so we could already ditch the panel- prefix in drivers. Would you also create include/video/panel/ ? > --- > > Should we aim for DT only solution from the start? DT is the direction we > are going, and I feel the older platform data stuff would be deprecated > soon. Don't forget about non-ARM architectures :-/ We need panel drivers for SH as well, which doesn't use DT. I don't think that would be a big issue, a DT- compliant solution should be easy to use through board code and platform data as well. > --- > > Something missing from the intro is how this whole thing should be used. > It doesn't help if we know how to turn on the panel, we also need to > display something on it =). So I think some kind of diagram/example of > how, say, drm would use this thing, and also how the SoC specific DBI > bus driver would be done, would clarify things. Of course. If I had all that information already I would have shared it :-) This is really a first RFC, my goal is to make sure that I'm going in the right direction. > --- > > We have discussed face to face about the different hardware setups and > scenarios that we should support, but I'll list some of them here for > others: > > 1) We need to support chains of external display chips and panels. A > simple example is a chip that takes DSI in, and outputs DPI. In that > case we'd have a chain of SoC -> DSI2DPI -> DPI panel. > > In final products I think two external devices is the maximum (at least > I've never seen three devices in a row), but in theory and in > development environments the chain can be arbitrarily long. Also the > connections are not necessarily 1-to-1, but a device can take one input > while it has two outputs, or a device can take two inputs. > > Now, I think two external devices is a must requirement. I'm not sure if > supporting more is an important requirement. However, if we support two > devices, it could be that it's trivial to change the framework to > support n devices. > > 2) Panels and display chips are all but standard. They very often have > their own sequences how to do things, have bugs, or implement some > feature in slightly different way than some other panel. This is why the > panel driver should be able to control or define the way things happen. > > As an example, Sharp LQ043T1DG01 panel > (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with > the following sequence: > > - Enable VCC and AVDD regulators > - Wait min 50ms > - Enable full video stream (pck, syncs, pixels) from SoC > - Wait min 0.5ms > - Set DISP GPIO, which turns on the display panel > > Here we could split the enabling of panel to two parts, prepare (in this > case starts regulators and waits 50ms) and finish (wait 0.5ms and set > DISP GPIO), and the upper layer would start the video stream in between. > > I realize this could be done with the PANEL_ENABLE_* levels in your RFC, > but I don't think the concepts quite match: > > - PANEL_ENABLE_BLANK level is needed for "smart panels", as we need to > configure them and send the initial frame at that operating level. With > dummy panels there's really no such level, there's just one enable > sequence that is always done right away. > > - I find waiting at the beginning of a function very ugly (what are we > waiting for?) and we'd need that when changing the panel to > PANEL_ENABLE_ON level. > > - It's still limited if the panel is a stranger one (see following > example). > > Consider the following theoretical panel enable example, taken to absurd > level just to show the general problem: > > - Enable regulators > - Enable video stream > - Wait 50ms > - Disable video stream > - Set enable GPIO > - Enable video stream > > This one would be rather impossible with the upper layer handling the > enabling of the video stream. Thus I see that the panel driver needs to > control the sequences, and the Sharp panel driver's enable would look > something like: > > regulator_enable(...); > sleep(); > dpi_enable_video(
Re: [RFC 0/5] Generic panel framework
On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: > What kind of directory structure do you have in mind ? Panels are already > isolated in drivers/video/panel/ so we could already ditch the panel- prefix > in drivers. The same directory also contains files for the framework and buses. But perhaps there's no need for additional directories if the amount of non-panel files is small. And you can easily see from the name that they are not panel drivers (e.g. mipi_dbi_bus.c). > Would you also create include/video/panel/ ? Perhaps that would be good. Well, having all the files prefixed with panel- is not bad as such, but just feel extra. > > --- > > > > Should we aim for DT only solution from the start? DT is the direction we > > are going, and I feel the older platform data stuff would be deprecated > > soon. > > Don't forget about non-ARM architectures :-/ We need panel drivers for SH as > well, which doesn't use DT. I don't think that would be a big issue, a DT- > compliant solution should be easy to use through board code and platform data > as well. I didn't forget about them as I didn't even think about them ;). I somehow had the impression that other architectures would also use DT, sooner or later. I could be mistaken, though. And true, it's not a big issue to support both DT and non-DT versions, but I've been porting omap stuff for DT and keeping the old platform data stuff also there, and it just feels burdensome. For very simple panels it's easy, but when you've passing lots of parameters the code starts to get longer. > > This one would be rather impossible with the upper layer handling the > > enabling of the video stream. Thus I see that the panel driver needs to > > control the sequences, and the Sharp panel driver's enable would look > > something like: > > > > regulator_enable(...); > > sleep(); > > dpi_enable_video(); > > sleep(); > > gpip_set(..); > > I have to admit I have no better solution to propose at the moment, even if I > don't really like making the panel control the video stream. When several > devices will be present in the chain all of them might have similar annoying > requirements, and my feeling is that the resulting code will be quite messy. > At the end of the day the only way to really find out is to write an > implementation. If we have a chain of devices, and each device uses the bus interface from the previous device in the chain, there shouldn't be a problem. In that model each device can handle the task however is best for it. I think the problems come from the divided control we'll have. I mean, if the panel driver would decide itself what to send to its output, and it would provide the data (think of an i2c device), this would be very simple. And it actually is for things like configuration data etc, but not so for video stream. > > It could cause some locking issues, though. First the panel's remove > > could take a lock, but the remove sequence would cause the display > > driver to call disable on the panel, which could again try to take the > > same lock... > > We have two possible ways of calling panel operations, either directly (panel- > >bus->ops->enable(...)) or indirectly (panel_enable(...)). > > The former is what V4L2 currently does with subdevs, and requires display > drivers to hold a reference to the panel. The later can do without a direct > reference only if we use a global lock, which is something I would like to Wouldn't panel_enable() just do the same panel->bus->ops->enable() anyway, and both require a panel reference? I don't see the difference. > avoid. A panel-wide lock wouldn't work, as the access function would need to > take the lock on a panel instance that can be removed at any time. Can't this be handled with some kind of get/put refcounting? If there's a ref, it can't be removed. Generally about locks, if we define that panel ops may only be called exclusively, does it simplify things? I think we can make such requirements, as there should be only one display framework that handles the panel. Then we don't need locking for things like enable/disable. Of course we need to be careful about things where calls come from "outside" the display framework. I guess one such thing is rmmod, but if that causes a notification to the display framework, which again handles locking, it shouldn't be a problem. Another thing to be careful about is if the panel internally uses irqs, workqueues, sysfs files or such. In that case it needs to handle locking. Tomi signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 3/5] video: panel: Add MIPI DBI bus support
Hi Tomi,
On Friday 17 August 2012 13:51:49 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
> > On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
> > > On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
> > > > +/*
> > > > --
> > > > ---
> > > > + * Bus operations
> > > > + */
> > > > +
> > > > +void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned
> > > > long
> > > > cmd) +{
> > > > + dev->bus->ops->write_command(dev->bus, cmd);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(panel_dbi_write_command);
> > > > +
> > > > +void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
> > > > data) +{
> > > > + dev->bus->ops->write_data(dev->bus, data);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(panel_dbi_write_data);
> > > > +
> > > > +unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
> > > > +{
> > > > + return dev->bus->ops->read_data(dev->bus);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(panel_dbi_read_data);
> > >
> > > I'm not that familiar with how to implement bus drivers, can you
> > > describe in pseudo code how the SoC's DBI driver would register these?
> >
> > Sure.
> >
> > The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
> >
> > static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
> >
> > .write_command = lcdc_dbi_write_command,
> > .write_data = lcdc_dbi_write_data,
> > .read_data = lcdc_dbi_read_data,
> >
> > };
>
> Thanks for the example, I think it cleared up things a bit.
>
> As I mentioned earlier, I really think "panel" is not right here. While
> the whole framework may be called panel framework, the bus drivers are
> not panels, and we should support external chips also, which are not
> panels either.
I agree. I've renamed panel_dbi_* to mipi_dbi_*.
> > > I think write/read data functions are a bit limited. Shouldn't they be
> > > something like write_data(const u8 *buf, int size) and read_data(u8
> > > *buf, int len)?
> >
> > Good point. My hardware doesn't support multi-byte read/write operations
> > directly so I haven't thought about adding those.
>
> OMAP HW doesn't support it either. Well, not quite true, as OMAP's
> system DMA could be used to write a buffer to the DBI output. But that's
> really the same as doing the write with a a loop with CPU.
>
> But first, the data type should be byte, not unsigned long. How would
> you write 8 bits or 16 bits with your API?
u8 and u16 both fit in an unsigned long :-) Please see below.
> And second, if the function takes just u8, you'd need lots of calls to do
> simple writes.
I agree, an array write function is a good idea.
> > Can your hardware group command + data writes in a single operation ? If
> > so we should expose that at the API level as well.
>
> No it can't. But with DCS that is a common operation, so we could have
> some helpers to send command + data with one call.
Agreed.
> Then again, I'd hope to have DCS somehow as a separate library, which would
> then use DBI/DSI/whatnot to actually send the data.
>
> I'm not quite sure how easy that is because of the differences between
> the busses.
>
> > Is DBI limited to 8-bit data transfers for commands ? Pixels can be
> > transferred 16-bit at a time, commands might as well. While DCS only
> > specifies 8-bit command/data, DBI panels that are not DCS compliant can
> > use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel, does
> > so).
>
> I have to say I don't remember much about DBI =). Looking at OMAP's
> driver, which was made for omap2 and hasn't been much updated since, I
> see that there are 4 modes, 8/9/12/16 bits. I think that defines how
> many of the parallel data lines are used.
SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored when
transferring instructions and data other than pixels (for pixels the 18-bits
bus width can be used to transfer RGB666 in a single clock cycle).
See page 87 of
http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
> However, I don't think that matters for the panel driver when it wants
> to send data. The panel driver should just call dbi_write(buf, buf_len),
> and the dbi driver would send the data in the buffer according to the
> bus width.
According to the DCS specification, commands and parameters are transferred
using 8-bit data. Non-DCS panels can however use wider commands and parameters
(all commands and parameters are 16-bits wide for the R61505 for instance).
We can add an API to switch the DBI bus width on the fly. For Renesas hardware
this would "just" require shifting bits around to output the 8-bit or 16-bit
commands on the right data lines (the R61505 uses D17-D9 in 8-bit mode, while
the DCS specification mentions D7-D0) based on how the panel is connected and
on which lines the panel expects data.
As commands can be expressed
Re: [RFC 3/5] video: panel: Add MIPI DBI bus support
On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
> > But first, the data type should be byte, not unsigned long. How would
> > you write 8 bits or 16 bits with your API?
>
> u8 and u16 both fit in an unsigned long :-) Please see below.
Ah, I see, so the driver would just discard 24 bits or 16 bits from the
ulong. I somehow thought that if you have 8 bit bus, and you call the
write with ulong, 4 bytes will be written.
> > Then again, I'd hope to have DCS somehow as a separate library, which would
> > then use DBI/DSI/whatnot to actually send the data.
> >
> > I'm not quite sure how easy that is because of the differences between
> > the busses.
> >
> > > Is DBI limited to 8-bit data transfers for commands ? Pixels can be
> > > transferred 16-bit at a time, commands might as well. While DCS only
> > > specifies 8-bit command/data, DBI panels that are not DCS compliant can
> > > use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel, does
> > > so).
> >
> > I have to say I don't remember much about DBI =). Looking at OMAP's
> > driver, which was made for omap2 and hasn't been much updated since, I
> > see that there are 4 modes, 8/9/12/16 bits. I think that defines how
> > many of the parallel data lines are used.
>
> SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored when
> transferring instructions and data other than pixels (for pixels the 18-bits
> bus width can be used to transfer RGB666 in a single clock cycle).
>
> See page 87 of
> http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
>
> > However, I don't think that matters for the panel driver when it wants
> > to send data. The panel driver should just call dbi_write(buf, buf_len),
> > and the dbi driver would send the data in the buffer according to the
> > bus width.
>
> According to the DCS specification, commands and parameters are transferred
> using 8-bit data. Non-DCS panels can however use wider commands and
> parameters
> (all commands and parameters are 16-bits wide for the R61505 for instance).
>
> We can add an API to switch the DBI bus width on the fly. For Renesas
> hardware
> this would "just" require shifting bits around to output the 8-bit or 16-bit
> commands on the right data lines (the R61505 uses D17-D9 in 8-bit mode, while
> the DCS specification mentions D7-D0) based on how the panel is connected and
> on which lines the panel expects data.
>
> As commands can be expressed on either 8 or 16 bits I would use a 16 type for
> them.
I won't put my head on the block, but I don't think DBI has any
restriction on the size of the command. A "command" just means a data
transfer while keeping the D/CX line low, and "data" when the line is
high. Similar transfers for n bytes can be done in both modes.
> For parameters, we can either express everything as u8 * in the DBI bus
> operations, or use a union similar to i2c_smbus_data
>
> union i2c_smbus_data {
> __u8 byte;
> __u16 word;
> __u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for length */
>/* and one more for user-space compatibility */
> };
There's no DBI_BLOCK_MAX, so at least identical union won't work. I
think it's simplest to have u8 * function as a base, and then a few
helpers to write the most common datatypes.
So we could have on the lowest level something like:
dbi_write_command(u8 *buf, size_t size);
dbi_write_data(u8 *buf, size_t size);
And possible helpers:
dbi_write_data(u8 *cmd_buf, size_t cmd_size, u8 *data_buf, size_t
data_size);
dbi_write_dcs(u8 cmd, u8 *data, size_t size);
And variations:
dbi_write_dcs_0(u8 cmd);
dbi_write_dcs_1(u8 cmd, u8 data);
etc. So a simple helper to send 16 bits would be:
dbi_write_data(u16 data)
{
// or are the bytes the other way around...
u8 buf[2] = { data & 0xff, (data >> 8) & 0xff };
return dbi_write_data(buf, 2);
}
> Helper functions would be available to perform 8-bit, 16-bit or n*8 bits
> transfers.
>
> Would that work for your use cases ?
>
> > Also note that some chips need to change the bus width on the fly. The
> > chip used on N800 wants configuration to be done with 8-bits, and pixel
> > transfers with 16-bits. Who knows why...
>
> On which data lines is configuration performed ? D7-D0 ?
I guess so, but does it matter? All the bus driver needs to know is how
to send 8/16/.. bit data. On OMAP we just write the data to a 32 bit
register, and the HW takes the lowest n bits. Do the bits represent the
data lines directly on Renesans?
The omap driver actually only implements 8 and 16 bit modes, not the 9
and 12 bit modes. I'm not sure what kind of shifting is needed for
those.
> > > We might just need to provide fake timings. Video mode timings are at the
> > > core of display support in all drivers so we can't just get rid of them.
> > > The h/v front/back porch and sync won't be used by display drivers for
> > > DBI/DSI panels anyway.
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 Alex Deucher changed: What|Removed |Added Attachment #65659|0 |1 is obsolete|| --- Comment #49 from Alex Deucher 2012-08-17 13:09:02 UTC --- Created attachment 65692 --> https://bugs.freedesktop.org/attachment.cgi?id=65692 upstream 1/2 This set of stable patches will apply cleanly. -- 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 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #50 from Alex Deucher 2012-08-17 13:09:32 UTC --- Created attachment 65693 --> https://bugs.freedesktop.org/attachment.cgi?id=65693 upstream 2/2 Second patch. -- 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/udl: dpms off the crtc when disabled.
On Thu, Aug 16, 2012 at 10:55 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This turns off the crtc when its been disabled,
> fixes it not turning off properly the whole time.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/udl/udl_modeset.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index f5dd89e..9159d48 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -354,8 +354,7 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
>
> static void udl_crtc_disable(struct drm_crtc *crtc)
> {
> -
> -
> + udl_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
> }
>
> static void udl_crtc_destroy(struct drm_crtc *crtc)
> --
> 1.7.11.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v4
On Thu, Aug 16, 2012 at 7:13 PM, Greg KH wrote: > On Mon, Aug 06, 2012 at 12:56:04PM -0400, j.gli...@gmail.com wrote: >> From: Jerome Glisse >> >> Virtual address need to be fenced to know when we can safely remove it. >> This patch also properly clear the pagetable. Previously it was >> serouisly broken. >> >> v2: For to update pagetable when unbinding bo (don't bailout if >> bo_va->valid is true). >> v3: Fix compilation warnings >> v4: We need a special version for 3.5 because the locking scheme >> is different btw 3.5 and 3.6. There is no longer cs mutex in >> 3.6 instead there is a global vm mutex. >> >> This version is for stable 3.5 only. > > Is the version that fixes this problem in the 3.6 tree, already in > Linus's tree? If so, what is the git commit id? If not, I need to wait > until it gets in there, so please tell me when it does so. Yes: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e43b5ec05afdc232be25aa481315035c1888d389 Please apply to stable. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #26 from Kunal 2012-08-17 13:54:43 UTC --- (In reply to comment #25) > You might try the 5 patches starting with this one: > http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html On top of previous patche(s) (by Jerome)? or as separate set? -- 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: [RFC 3/5] video: panel: Add MIPI DBI bus support
Hi Tomi,
On Friday 17 August 2012 16:06:30 Tomi Valkeinen wrote:
> On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
> > > But first, the data type should be byte, not unsigned long. How would
> > > you write 8 bits or 16 bits with your API?
> >
> > u8 and u16 both fit in an unsigned long :-) Please see below.
>
> Ah, I see, so the driver would just discard 24 bits or 16 bits from the
> ulong.
That's right.
> I somehow thought that if you have 8 bit bus, and you call the write with
> ulong, 4 bytes will be written.
>
> > > Then again, I'd hope to have DCS somehow as a separate library, which
> > > would then use DBI/DSI/whatnot to actually send the data.
> > >
> > > I'm not quite sure how easy that is because of the differences between
> > > the busses.
> > >
> > > > Is DBI limited to 8-bit data transfers for commands ? Pixels can be
> > > > transferred 16-bit at a time, commands might as well. While DCS only
> > > > specifies 8-bit command/data, DBI panels that are not DCS compliant
> > > > can use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel,
> > > > does so).
> > >
> > > I have to say I don't remember much about DBI =). Looking at OMAP's
> > > driver, which was made for omap2 and hasn't been much updated since, I
> > > see that there are 4 modes, 8/9/12/16 bits. I think that defines how
> > > many of the parallel data lines are used.
> >
> > SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored
> > when transferring instructions and data other than pixels (for pixels the
> > 18-bits bus width can be used to transfer RGB666 in a single clock cycle).
> >
> > See page 87 of
> > http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
> >
> > > However, I don't think that matters for the panel driver when it wants
> > > to send data. The panel driver should just call dbi_write(buf, buf_len),
> > > and the dbi driver would send the data in the buffer according to the
> > > bus width.
> >
> > According to the DCS specification, commands and parameters are
> > transferred using 8-bit data. Non-DCS panels can however use wider
> > commands and parameters (all commands and parameters are 16-bits wide for
> > the R61505 for instance).
> >
> > We can add an API to switch the DBI bus width on the fly. For Renesas
> > hardware this would "just" require shifting bits around to output the
> > 8-bit or 16-bit commands on the right data lines (the R61505 uses D17-D9
> > in 8-bit mode, while the DCS specification mentions D7-D0) based on how
> > the panel is connected and on which lines the panel expects data.
> >
> > As commands can be expressed on either 8 or 16 bits I would use a 16 type
> > for them.
>
> I won't put my head on the block, but I don't think DBI has any
> restriction on the size of the command. A "command" just means a data
> transfer while keeping the D/CX line low, and "data" when the line is
> high. Similar transfers for n bytes can be done in both modes.
Right. I'll see if the API could be simplified by having a single write
callback function with a data/command parameter.
> > For parameters, we can either express everything as u8 * in the DBI bus
> > operations, or use a union similar to i2c_smbus_data
> >
> > union i2c_smbus_data {
> >
> > __u8 byte;
> > __u16 word;
> > __u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for
> > length */
> >
> >/* and one more for user-space
> >compatibility */
> >
> > };
>
> There's no DBI_BLOCK_MAX, so at least identical union won't work. I
> think it's simplest to have u8 * function as a base, and then a few
> helpers to write the most common datatypes.
OK, that sounds good to me.
> So we could have on the lowest level something like:
>
> dbi_write_command(u8 *buf, size_t size);
> dbi_write_data(u8 *buf, size_t size);
>
> And possible helpers:
>
> dbi_write_data(u8 *cmd_buf, size_t cmd_size, u8 *data_buf, size_t
> data_size);
>
> dbi_write_dcs(u8 cmd, u8 *data, size_t size);
>
> And variations:
>
> dbi_write_dcs_0(u8 cmd);
> dbi_write_dcs_1(u8 cmd, u8 data);
>
> etc. So a simple helper to send 16 bits would be:
>
> dbi_write_data(u16 data)
> {
> // or are the bytes the other way around...
> u8 buf[2] = { data & 0xff, (data >> 8) & 0xff };
> return dbi_write_data(buf, 2);
> }
>
> > Helper functions would be available to perform 8-bit, 16-bit or n*8 bits
> > transfers.
> >
> > Would that work for your use cases ?
> >
> > > Also note that some chips need to change the bus width on the fly. The
> > > chip used on N800 wants configuration to be done with 8-bits, and pixel
> > > transfers with 16-bits. Who knows why...
> >
> > On which data lines is configuration performed ? D7-D0 ?
>
> I guess so, but does it matter? All the bus driver needs to know is how
> to send 8/16/.. bit data. On OMAP we just write the data to a 32 bit
> register, and t
[PATCH] drm: Remove two unused fields from struct drm_display_mode
From: Damien Lespiau
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_modes.c |3 ---
include/drm/drm_crtc.h |2 --
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index b7adb4a..28637c1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -706,9 +706,6 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p, int
adjust_flags)
p->crtc_vblank_end = max(p->crtc_vsync_end, p->crtc_vtotal);
p->crtc_hblank_start = min(p->crtc_hsync_start, p->crtc_hdisplay);
p->crtc_hblank_end = max(p->crtc_hsync_end, p->crtc_htotal);
-
- p->crtc_hadjusted = false;
- p->crtc_vadjusted = false;
}
EXPORT_SYMBOL(drm_mode_set_crtcinfo);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a1a0386..ced3625 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -166,8 +166,6 @@ struct drm_display_mode {
int crtc_vsync_start;
int crtc_vsync_end;
int crtc_vtotal;
- int crtc_hadjusted;
- int crtc_vadjusted;
/* Driver private mode info */
int private_size;
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #27 from Alex Deucher 2012-08-17 14:21:26 UTC --- (In reply to comment #26) > (In reply to comment #25) > > You might try the 5 patches starting with this one: > > http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html > > On top of previous patche(s) (by Jerome)? or as separate set? They apply on top of his patches. -- 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: [Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote:
@@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
drm_i915_private *dev_priv)
*/
static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc,
unsigned int *pipe_bpp,
-struct drm_display_mode *mode)
+struct drm_display_mode *mode,
+int max_fdi_bpp)
There's some kernel-doc for this function, maybe add a @max_fdi_bpp there?
> @@ -3800,6 +3801,15 @@ static bool intel_choose_pipe_bpp_dither(struct
> drm_crtc *crtc,
> display_bpc = 6;
> }
>
> + if (display_bpc * 3 > max_fdi_bpp) {
> + if (max_fdi_bpp < 24)
> + display_bpc = 6;
> + else if (max_fdi_bpp < 30)
> + display_bpc = 8;
> + else if (max_fdi_bpp < 36)
> + display_bpc = 10;
> + DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
> + }
This chunk is being moved around in a later patch in the series,
merging the two patches in one looks like a good idea?
> + /* If the other FDI link is using too many lanes, we can't have
> +* any
> +*/
> + if (other_intel_crtc->fdi_lanes > 2)
> + return 0;
> +
> + /* When both are running, we only get 2 lanes at most
> +*/
> + return 2;
> +}
I guess this does not cover the case of pipe B using 3 lanes meaning
pipe C can use 1?
> @@ -4672,7 +4731,18 @@ static int ironlake_crtc_mode_set(struct drm_crtc
> *crtc,
>according to current link config */
> if (is_cpu_edp) {
> intel_edp_link_config(edp_encoder, &lane, &link_bw);
> + max_fdi_bpp = 0;
> + max_lane = lane;
> } else {
> + u32 fdi_bw;
> +
> + /* [e]DP over FDI requires target mode clock
> + instead of link clock */
> + if (is_dp)
> + target_clock = mode->clock;
> + else
> + target_clock = adjusted_mode->clock;
> +
This duplicates the code just that is just a few lines away, instead
how about moving the logic to set target_clock up in front of this
whole if()?
> /* FDI is a binary signal running at ~2.7GHz, encoding
> * each output octet as 10 bits. The actual frequency
> * is stored as a divider into a 100MHz clock, and the
> @@ -4681,6 +4751,18 @@ static int ironlake_crtc_mode_set(struct drm_crtc
> *crtc,
> * is:
> */
> link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
> +
> + max_lane = 4;
> + if (IS_IVYBRIDGE(dev))
> + max_lane = ivb_fdi_max_lanes(crtc);
> +
> + /*
> +* Compute the available FDI bandwidth, use that
> +* to compute the maximum supported BPP
> +*/
> + fdi_bw = link_bw * max_lane * 19 / 20;
> + max_fdi_bpp = fdi_bw / target_clock;
> + DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n",
> max_lane, max_fdi_bpp);
> }
This chunk is also reworked in a later commit in this series.
--
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: limit printk when facing bad edid
On Fri, Aug 17, 2012 at 3:01 AM, Jani Nikula wrote: > On Thu, 16 Aug 2012, Jerome Glisse wrote: >> On Thu, Aug 16, 2012 at 11:13 AM, Jani Nikula >> wrote: >>> >>> There's a bug [1] where the faster GMBUS transmissions fail with some >>> CRTs, and the fix [2] is to fallback to GPIO bit-banging upon errors. As >>> noted in the bug, the fix still leaves plenty of EDID dumps in dmesg, so >>> some measures to reduce the EDID error messages would be most welcome. >>> >>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881 >>> [2] http://thread.gmane.org/gmane.linux.kernel/1332810/focus=1341912 >>> >>> On Tue, 14 Aug 2012, Jerome Glisse wrote: On Tue, Aug 14, 2012 at 10:54 AM, Adam Jackson wrote: > On 8/9/12 11:25 AM, j.gli...@gmail.com wrote: >> >> From: Jerome Glisse >> >> Limit printing bad edid information at one time per connector. >> Connector that are connected to a bad monitor/kvm will likely >> stay connected to the same bad monitor/kvm and it makes no >> sense to keep printing the bad edid message. >>> >>> Do I understand correctly that bad_edid_counter is only reset when you >>> reboot or reload the module? So if you have a laptop that you connect to >>> the monitor at home, the monitor at the office, the projector in the >>> meeting room, and to a TV somewhere else, etc, the message about bad >>> EDID will only printed once? I don't think that's good. But please do >>> correct me if I'm wrong. >> >> I wanted to reset the counter any time the connector is connected to >> something with good edid but i did not do that in the end. I can do a >> patch on top if you think it would be nicer. That way only thing with >> bad edid will be printed once and assuming you don't repeatly >> alternate btw good and bad edid device you would not get spam. > > IMHO this is, with or without the additional patch, overengineering the > logic to print out error messages. > > For me, as a developer, this would be annoying because, to debug an EDID > issue, I'd have to reload the module, connect to something with "good" > EDID in between, or patch this out, to repeat a problem. I might have to > ask a tester or a bug reporter to do the same. > > Also, in the referenced bug, the first problem with GMBUS would disable > error messages, and the fallback retry with GPIO bit-banging would no > longer produce messages even if that failed too. If you set drm.debug=4 my patch will keep printing bad edid and possibly spam your log. So it's not harder for developer. I restricted the spamming to when some one is asking for debug. >> >> >> Signed-off-by: Jerome Glisse > > > I guess. I don't see why we don't just move it into DRM_DEBUG_KMS if > we're > going to suppress it, but this does what it says on the box. > > Reviewed-by: Adam Jackson > > - ajax > I think there is still value in getting at least once the bad edid. >>> >>> I think the raw edid dumps should be DEBUG level no matter what. Perhaps >>> some of the other messages could use WARNING/DEBUG too. And with that, >>> and my comment above, I not sure there really needs to be all that logic >>> to count errors and act differently further on. >>> >> >> No, i do think we want bad edid as normal log at least once per >> connector and we definitely don't want to spam bomb the log messages. > > Well, at least we agree on silencing the dmesg here. ;) > > I'd be happy with very simply adjusting the loglevel of the messages, so > that I can also very simply adjust the amount of messages I get. Or ask > a bug reported to do drm.debug=0xe instead of trying to ensure they > follow a bunch of steps in between. But I'm not going to bikeshed > further if others think the patch here is the way to go. > The patch aim was mostly with server where we dont want to spam bomb error log but where we still want to be able to get bad edid without having to ask for a reboot which on server is very much appreciated. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge
"Lespiau, Damien" writes: > On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote: > > @@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct > drm_i915_private *dev_priv) > */ > static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc, > unsigned int *pipe_bpp, > -struct drm_display_mode *mode) > +struct drm_display_mode *mode, > +int max_fdi_bpp) > > There's some kernel-doc for this function, maybe add a @max_fdi_bpp > there? Will do > This chunk is being moved around in a later patch in the series, > merging the two patches in one looks like a good idea? Or at least move this into its final position in this patch. > I guess this does not cover the case of pipe B using 3 lanes meaning > pipe C can use 1? It didn't look like that was a supported mode from the docs. > This duplicates the code just that is just a few lines away, instead > how about moving the logic to set target_clock up in front of this > whole if()? It's not the same, it's the inverse -- computing bpp from lanes+clock clock instead of computing lanes from bpp+clock. But, yeah, it would be nice to have these merged somehow. I couldn't figure out a good way though. > This chunk is also reworked in a later commit in this series. I'll see if I can't avoid that as it's confusing. Thanks for your review! -- keith.pack...@intel.com pgpUeyeGIkhdL.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote:
> @@ -3845,8 +3836,20 @@ static bool intel_choose_pipe_bpp_dither(struct
> drm_crtc *crtc,
>
> display_bpc = min(display_bpc, bpc);
>
> - DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d)\n",
> - bpc, display_bpc);
> + display_bpc = 6;
It seems that you are overriding display_bpc unconditionally here,
some left over from debugging?
> + if (display_bpc * 3 > max_fdi_bpp) {
> + if (max_fdi_bpp < 24)
> + display_bpc = 6;
> + else if (max_fdi_bpp < 30)
> + display_bpc = 8;
> + else if (max_fdi_bpp < 36)
> + display_bpc = 10;
> + DRM_DEBUG_KMS("Dithering FDI to %dbpc\n", display_bpc);
> + }
> +
> + DRM_DEBUG_KMS("setting pipe bpc to %d (max display bpc %d)
> (max_fdi_bpp %d)\n",
> + bpc, display_bpc, max_fdi_bpp);
>
> *pipe_bpp = display_bpc * 3;
"setting pipe bpc to %d", bpc and *pipe_bpp = display_bpc, looks like
a bogus debug message to me.
> @@ -4763,9 +4765,12 @@ static int ironlake_crtc_mode_set(struct drm_crtc
> *crtc,
> * Compute the available FDI bandwidth, use that
> * to compute the maximum supported BPP
> */
> - fdi_bw = link_bw * max_lane * 19 / 20;
> - max_fdi_bpp = fdi_bw / target_clock;
> - DRM_DEBUG_KMS("max lane %d yields max fdi bpp %d\n",
> max_lane, max_fdi_bpp);
> + fdi_bw = (link_bw * 8) * max_lane;
> + pps = target_clock * 21 / 20;
> +
> + max_fdi_bpp = fdi_bw / pps;
> + DRM_DEBUG_KMS("link_bw %d max_lane %d fdi_bw %u pps %u
> max_fdi_bpp %d\n",
> + link_bw, max_lane, fdi_bw, pps, max_fdi_bpp);
> }
While I understood the first computation of max_fdi_bpp in patch 2 of
this series, I have to confess you lost me there. Would you mind
clarifying this?
--
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge
On Fri, Aug 17, 2012 at 4:00 PM, Keith Packard wrote: >> I guess this does not cover the case of pipe B using 3 lanes meaning >> pipe C can use 1? > > It didn't look like that was a supported mode from the docs. Ah yes, found it now "FDI B maximum port width is 4 lanes when FDI C is disabled, 2 lanes when FDI C is enabled." >> This duplicates the code just that is just a few lines away, instead >> how about moving the logic to set target_clock up in front of this >> whole if()? > > It's not the same, it's the inverse -- computing bpp from lanes+clock > clock instead of computing lanes from bpp+clock. But, yeah, it would be > nice to have these merged somehow. I couldn't figure out a good way though. I meant the > + if (is_dp) > + target_clock = mode->clock; > + else > + target_clock = adjusted_mode->clock; Just after that else block you have /* [e]DP over FDI requires target mode clock instead of link clock. */ if (edp_encoder) target_clock = intel_edp_target_clock(edp_encoder, mode); else if (is_dp) target_clock = mode->clock; else target_clock = adjusted_mode->clock; Those look strangely similar to me. The later could be moved up. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear FDI_RX_IIR before training
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote: > Just a bit of cleanup; it appears to have no effect. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/intel_display.c |7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) Clearing the locking bit in FDI_RX_IIR looks like a good move and waiting between tries can't hurt, looks good to me. Reviewed-by: Damien Lespiau -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote:
> These should probably all look like
>
> enabled |= (1 << pipe)
>
> so that the intent is clear...
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_pm.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 94aabca..1a84425 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -1815,7 +1815,7 @@ static void sandybridge_update_wm(struct drm_device
> *dev)
> DRM_DEBUG_KMS("FIFO watermarks For pipe C -"
> " plane %d, cursor: %d\n",
> plane_wm, cursor_wm);
> - enabled |= 3;
> + enabled |= 4;
> }
Looks like a very good catch!
Reviewed-by: Damien Lespiau
--
Damien
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote: > Doesn't make sense to disable in the other order. > > Signed-off-by: Keith Packard > --- > drivers/gpu/drm/i915/intel_display.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) I can't see anything in the docs about an order requirement for those. Not sure why the other way does not make sense. Somehow disabling TX before RX makes some sense to me (TX enabled without a ready RX looks weird?, no data should flow as the pipe is shutdown at that point anyway). Maybe it just does not matter? Another detail is that disabling the PLLs seem to have an order in the disabling sequence, TX, then RX. I. Disable CPU FDI Transmitter PLL II. Disable PCH FDI Receiver PLL -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)
Adding Matthew in case he as any ideas.
On Thu, Aug 16, 2012 at 3:51 PM, Alex Deucher wrote:
> On Thu, Aug 16, 2012 at 3:40 PM, David Lamparter wrote:
>> On Thu, Aug 16, 2012 at 03:13:46PM -0400, alexdeuc...@gmail.com wrote:
>>> From: David L
>> From: David Lamparter
>>
>> There are still two rough edges left in here, I didn't get around to
>> clean it up, other stuff came up -- sorry...
>>
>>> This is required for pure UEFI systems. The vbios is stored
>>> in ACPI rather than at the legacy vga location.
>>>
>>> Fixes:
>>> https://bugs.freedesktop.org/show_bug.cgi?id=26891
>>>
>>> V2: fix #ifdefs as per Greg's comments
>>>
>>> Signed-off-by: Alex Deucher
>>> Cc: sta...@vger.kernel.org
>>> ---
>> [...]
>>> + struct acpi_table_header *hdr;
>>> + /* acpi_get_table_with_size is not exported :( */
>>> + acpi_size tbl_size = 0x7fff;
>>
>> I was using acpi_get_table_with_size, but that needs an export, with
>> 0x7fff all the tests below are kinda useless because they always
>> succeed. I think it'd be useful to keep the length checks in case some
>> vendor breaks their ACPI tables, so this needs an EXPORT_SYMBOL.
>
> I guess we could leave it as is for now for -fixes and then switch it
> use use the new exported symbol for -next? Is it ok to export a new
> symbol for -fixes?
>
>>
>>> + UEFI_ACPI_VFCT *vfct;
>>> + GOP_VBIOS_CONTENT *vbios;
>>> + VFCT_IMAGE_HEADER *vhdr;
>>> +
>>> + if (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
>>> + return false;
>>> + if (tbl_size < sizeof(UEFI_ACPI_VFCT)) {
>>> + DRM_ERROR("ACPI VFCT table present but broken (too short
>>> #1)\n");
>>> + goto out_unmap;
>>> + }
>>> +
>>> + vfct = (UEFI_ACPI_VFCT *)hdr;
>>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) > tbl_size) {
>>> + DRM_ERROR("ACPI VFCT table present but broken (too short
>>> #2)\n");
>>> + goto out_unmap;
>>> + }
>>> +
>>> + vbios = (GOP_VBIOS_CONTENT *)((char *)hdr + vfct->VBIOSImageOffset);
>>> + vhdr = &vbios->VbiosHeader;
>>> + DRM_INFO("ACPI VFCT contains a BIOS for %02x:%02x.%d %04x:%04x, size
>>> %d\n",
>>> + vhdr->PCIBus, vhdr->PCIDevice, vhdr->PCIFunction,
>>> + vhdr->VendorID, vhdr->DeviceID, vhdr->ImageLength);
>>> +
>>> + if (vhdr->PCIBus != rdev->pdev->bus->number ||
>>> + vhdr->PCIDevice != PCI_SLOT(rdev->pdev->devfn) ||
>>> + vhdr->PCIFunction != PCI_FUNC(rdev->pdev->devfn) ||
>>> + vhdr->VendorID != rdev->pdev->vendor ||
>>> + vhdr->DeviceID != rdev->pdev->device) {
>>> + DRM_INFO("ACPI VFCT table is not for this card\n");
>>> + goto out_unmap;
>>> + };
>>> +
>>> + if (vfct->VBIOSImageOffset + sizeof(VFCT_IMAGE_HEADER) +
>>> vhdr->ImageLength > tbl_size) {
>>> + DRM_ERROR("ACPI VFCT image truncated\n");
>>> + goto out_unmap;
>>> + }
>>> +
>>> + rdev->bios = kmemdup(&vbios->VbiosContent, vhdr->ImageLength,
>>> GFP_KERNEL);
>>> + ret = !!rdev->bios;
>>> +
>>> +out_unmap:
>>> + /* uh, no idea what to do here... */
>>
>> So, er, I had no clue how to clean up the return value of acpi_get_table
>> - does this actually need to be cleaned up? Or do you just get a
>> pointer straight to the "real" ACPI table?
>
> Not sure on that. Anyone know more about the acpi code?
>
> Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: implement ACPI VFCT vbios fetch (v2)
On Fri, Aug 17, 2012 at 12:56:31PM -0400, Alex Deucher wrote: > > I guess we could leave it as is for now for -fixes and then switch it > > use use the new exported symbol for -next? Is it ok to export a new > > symbol for -fixes? I don't see why not, providing the ACPI people are happy with it. > >> So, er, I had no clue how to clean up the return value of acpi_get_table > >> - does this actually need to be cleaned up? Or do you just get a > >> pointer straight to the "real" ACPI table? > > > > Not sure on that. Anyone know more about the acpi code? Not sure what you're asking here - acpi_get_table returns acpi_status, not a pointer. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training
On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote: > @@ -2324,6 +2324,8 @@ static void intel_fdi_normal_train(struct drm_crtc > *crtc) > temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE; > } > I915_WRITE(reg, temp); > + POSTING_READ(reg); > + udelay(100); The docs don't mention a delay between writing the TX and RX training patterns, the POSTING_READ() seems like a good idea. > reg = FDI_RX_CTL(pipe); > temp = I915_READ(reg); > @@ -2334,16 +2336,15 @@ static void intel_fdi_normal_train(struct drm_crtc > *crtc) > temp &= ~FDI_LINK_TRAIN_NONE; > temp |= FDI_LINK_TRAIN_NONE; > } > + /* IVB wants error correction enabled */ > + if (IS_IVYBRIDGE(dev)) > + temp |= FDI_FS_ERRC_ENABLE | FDI_FE_ERRC_ENABLE; > + > I915_WRITE(reg, temp | FDI_RX_ENHANCE_FRAME_ENABLE); > > /* wait one idle pattern time */ > POSTING_READ(reg); > udelay(1000); > - > - /* IVB wants error correction enabled */ > - if (IS_IVYBRIDGE(dev)) > - I915_WRITE(reg, I915_READ(reg) | FDI_FS_ERRC_ENABLE | > - FDI_FE_ERRC_ENABLE); > } > > static void cpt_phase_pointer_enable(struct drm_device *dev, int pipe) Reviewed-by: Damien Lespiau -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #28 from Kunal 2012-08-17 18:10:08 UTC --- (In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #25) > > > You might try the 5 patches starting with this one: > > > http://lists.freedesktop.org/archives/dri-devel/2012-August/026498.html > > > > On top of previous patche(s) (by Jerome)? or as separate set? > > They apply on top of his patches. No luck :( It's still the same after applying those patches and rebuilding the kernel. Attaching the xorg log and dmesg log after this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #29 from Kunal 2012-08-17 18:11:08 UTC --- Created attachment 65703 --> https://bugs.freedesktop.org/attachment.cgi?id=65703 dmesg output as of 17th Aug., 2012. dmesg output with the new kernel. -- 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 42373] Radeon HD 6450 (NI CAICOS) screen corruption on boot
https://bugs.freedesktop.org/show_bug.cgi?id=42373 --- Comment #30 from Kunal 2012-08-17 18:11:43 UTC --- Created attachment 65704 --> https://bugs.freedesktop.org/attachment.cgi?id=65704 xorg log as of 17th Aug, 2012 xorg log for the same. -- 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: avoid turning off spread spectrum for used pll
From: Jerome Glisse
If spread spectrum is enabled and in use for a given pll we
should not turn it off as it will lead to turning off display
for crtc that use the pll (this behavior was observed on chelsea
edp).
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_crtc.c | 25 +
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index c6fcb5b..cb18813 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -444,11 +444,28 @@ union atom_enable_ss {
static void atombios_crtc_program_ss(struct radeon_device *rdev,
int enable,
int pll_id,
+int crtc_id,
struct radeon_atom_ss *ss)
{
+ unsigned i;
int index = GetIndexIntoMasterTable(COMMAND,
EnableSpreadSpectrumOnPPLL);
union atom_enable_ss args;
+ if (!enable) {
+ for (i = 0; i < 6; i++) {
+ if (rdev->mode_info.crtcs[i] &&
+ rdev->mode_info.crtcs[i]->enabled &&
+ i != crtc_id &&
+ pll_id == rdev->mode_info.crtcs[i]->pll_id) {
+ /* one other crtc is using this pll don't turn
+* off spread spectrum as it might turn off
+* display on active crtc
+*/
+ return;
+ }
+ }
+ }
+
memset(&args, 0, sizeof(args));
if (ASIC_IS_DCE5(rdev)) {
@@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc,
struct drm_display_mode
radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock,
&fb_div, &frac_fb_div,
&ref_div, &post_div);
- atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, &ss);
+ atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
radeon_crtc->crtc_id, &ss);
atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id,
radeon_crtc->pll_id,
encoder_mode, radeon_encoder->encoder_id,
mode->clock,
@@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc,
struct drm_display_mode
ss.step = step_size;
}
- atombios_crtc_program_ss(rdev, ATOM_ENABLE,
radeon_crtc->pll_id, &ss);
+ atombios_crtc_program_ss(rdev, ATOM_ENABLE,
radeon_crtc->pll_id, radeon_crtc->crtc_id, &ss);
}
}
@@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct radeon_device
*rdev)
ASIC_INTERNAL_SS_ON_DCPLL,
rdev->clock.default_dispclk);
if (ss_enabled)
- atombios_crtc_program_ss(rdev, ATOM_DISABLE,
ATOM_DCPLL, &ss);
+ atombios_crtc_program_ss(rdev, ATOM_DISABLE,
ATOM_DCPLL, -1, &ss);
/* XXX: DCE5, make sure voltage, dispclk is high enough */
atombios_crtc_set_disp_eng_pll(rdev,
rdev->clock.default_dispclk);
if (ss_enabled)
- atombios_crtc_program_ss(rdev, ATOM_ENABLE, ATOM_DCPLL,
&ss);
+ atombios_crtc_program_ss(rdev, ATOM_ENABLE, ATOM_DCPLL,
-1, &ss);
}
}
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: avoid turning off spread spectrum for used pll
On Fri, Aug 17, 2012 at 2:40 PM, wrote:
> From: Jerome Glisse
>
> If spread spectrum is enabled and in use for a given pll we
> should not turn it off as it will lead to turning off display
> for crtc that use the pll (this behavior was observed on chelsea
> edp).
>
> Signed-off-by: Jerome Glisse
Looks good. I think an alternative would be to just always enable SS
for DP/eDP rather than checking the DPCD since all DP connections run
on the same PLL. IIRC, that's what the closed driver does.
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/atombios_crtc.c | 25 +
> 1 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index c6fcb5b..cb18813 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -444,11 +444,28 @@ union atom_enable_ss {
> static void atombios_crtc_program_ss(struct radeon_device *rdev,
> int enable,
> int pll_id,
> +int crtc_id,
> struct radeon_atom_ss *ss)
> {
> + unsigned i;
> int index = GetIndexIntoMasterTable(COMMAND,
> EnableSpreadSpectrumOnPPLL);
> union atom_enable_ss args;
>
> + if (!enable) {
> + for (i = 0; i < 6; i++) {
> + if (rdev->mode_info.crtcs[i] &&
> + rdev->mode_info.crtcs[i]->enabled &&
> + i != crtc_id &&
> + pll_id == rdev->mode_info.crtcs[i]->pll_id) {
> + /* one other crtc is using this pll don't turn
> +* off spread spectrum as it might turn off
> +* display on active crtc
> +*/
> + return;
> + }
> + }
> + }
> +
> memset(&args, 0, sizeof(args));
>
> if (ASIC_IS_DCE5(rdev)) {
> @@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc
> *crtc, struct drm_display_mode
> radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock,
> &fb_div, &frac_fb_div,
> &ref_div, &post_div);
>
> - atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
> &ss);
> + atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
> radeon_crtc->crtc_id, &ss);
>
> atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id,
> radeon_crtc->pll_id,
> encoder_mode, radeon_encoder->encoder_id,
> mode->clock,
> @@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc
> *crtc, struct drm_display_mode
> ss.step = step_size;
> }
>
> - atombios_crtc_program_ss(rdev, ATOM_ENABLE,
> radeon_crtc->pll_id, &ss);
> + atombios_crtc_program_ss(rdev, ATOM_ENABLE,
> radeon_crtc->pll_id, radeon_crtc->crtc_id, &ss);
> }
> }
>
> @@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct
> radeon_device *rdev)
>
> ASIC_INTERNAL_SS_ON_DCPLL,
>
> rdev->clock.default_dispclk);
> if (ss_enabled)
> - atombios_crtc_program_ss(rdev, ATOM_DISABLE,
> ATOM_DCPLL, &ss);
> + atombios_crtc_program_ss(rdev, ATOM_DISABLE,
> ATOM_DCPLL, -1, &ss);
> /* XXX: DCE5, make sure voltage, dispclk is high enough */
> atombios_crtc_set_disp_eng_pll(rdev,
> rdev->clock.default_dispclk);
> if (ss_enabled)
> - atombios_crtc_program_ss(rdev, ATOM_ENABLE,
> ATOM_DCPLL, &ss);
> + atombios_crtc_program_ss(rdev, ATOM_ENABLE,
> ATOM_DCPLL, -1, &ss);
> }
>
> }
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: avoid turning off spread spectrum for used pll
On Fri, Aug 17, 2012 at 2:54 PM, Alex Deucher wrote: > On Fri, Aug 17, 2012 at 2:40 PM, wrote: >> From: Jerome Glisse >> >> If spread spectrum is enabled and in use for a given pll we >> should not turn it off as it will lead to turning off display >> for crtc that use the pll (this behavior was observed on chelsea >> edp). >> >> Signed-off-by: Jerome Glisse > > Looks good. I think an alternative would be to just always enable SS > for DP/eDP rather than checking the DPCD since all DP connections run > on the same PLL. On discrete cards anyway. APUs are a little different, but the same idea holds. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black
https://bugs.freedesktop.org/show_bug.cgi?id=43829 Alex Deucher changed: What|Removed |Added CC||kphilli...@gmail.com --- Comment #8 from Alex Deucher 2012-08-17 21:08:36 UTC --- *** Bug 53657 has been marked as a duplicate of this bug. *** -- 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: avoid turning off spread spectrum for used pll
On Fri, Aug 17, 2012 at 2:54 PM, Alex Deucher wrote:
> On Fri, Aug 17, 2012 at 2:40 PM, wrote:
>> From: Jerome Glisse
>>
>> If spread spectrum is enabled and in use for a given pll we
>> should not turn it off as it will lead to turning off display
>> for crtc that use the pll (this behavior was observed on chelsea
>> edp).
>>
>> Signed-off-by: Jerome Glisse
>
> Looks good. I think an alternative would be to just always enable SS
> for DP/eDP rather than checking the DPCD since all DP connections run
> on the same PLL. IIRC, that's what the closed driver does.
>
> Reviewed-by: Alex Deucher
Forgot cc stable
>
>> ---
>> drivers/gpu/drm/radeon/atombios_crtc.c | 25 +
>> 1 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index c6fcb5b..cb18813 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -444,11 +444,28 @@ union atom_enable_ss {
>> static void atombios_crtc_program_ss(struct radeon_device *rdev,
>> int enable,
>> int pll_id,
>> +int crtc_id,
>> struct radeon_atom_ss *ss)
>> {
>> + unsigned i;
>> int index = GetIndexIntoMasterTable(COMMAND,
>> EnableSpreadSpectrumOnPPLL);
>> union atom_enable_ss args;
>>
>> + if (!enable) {
>> + for (i = 0; i < 6; i++) {
>> + if (rdev->mode_info.crtcs[i] &&
>> + rdev->mode_info.crtcs[i]->enabled &&
>> + i != crtc_id &&
>> + pll_id == rdev->mode_info.crtcs[i]->pll_id) {
>> + /* one other crtc is using this pll don't
>> turn
>> +* off spread spectrum as it might turn off
>> +* display on active crtc
>> +*/
>> + return;
>> + }
>> + }
>> + }
>> +
>> memset(&args, 0, sizeof(args));
>>
>> if (ASIC_IS_DCE5(rdev)) {
>> @@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc
>> *crtc, struct drm_display_mode
>> radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock,
>> &fb_div, &frac_fb_div,
>> &ref_div, &post_div);
>>
>> - atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
>> &ss);
>> + atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id,
>> radeon_crtc->crtc_id, &ss);
>>
>> atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id,
>> radeon_crtc->pll_id,
>> encoder_mode, radeon_encoder->encoder_id,
>> mode->clock,
>> @@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc
>> *crtc, struct drm_display_mode
>> ss.step = step_size;
>> }
>>
>> - atombios_crtc_program_ss(rdev, ATOM_ENABLE,
>> radeon_crtc->pll_id, &ss);
>> + atombios_crtc_program_ss(rdev, ATOM_ENABLE,
>> radeon_crtc->pll_id, radeon_crtc->crtc_id, &ss);
>> }
>> }
>>
>> @@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct
>> radeon_device *rdev)
>>
>> ASIC_INTERNAL_SS_ON_DCPLL,
>>
>> rdev->clock.default_dispclk);
>> if (ss_enabled)
>> - atombios_crtc_program_ss(rdev, ATOM_DISABLE,
>> ATOM_DCPLL, &ss);
>> + atombios_crtc_program_ss(rdev, ATOM_DISABLE,
>> ATOM_DCPLL, -1, &ss);
>> /* XXX: DCE5, make sure voltage, dispclk is high enough */
>> atombios_crtc_set_disp_eng_pll(rdev,
>> rdev->clock.default_dispclk);
>> if (ss_enabled)
>> - atombios_crtc_program_ss(rdev, ATOM_ENABLE,
>> ATOM_DCPLL, &ss);
>> + atombios_crtc_program_ss(rdev, ATOM_ENABLE,
>> ATOM_DCPLL, -1, &ss);
>> }
>>
>> }
>> --
>> 1.7.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > for , we have verified cases on inteldrmfb, radeondrmfb, and > cirrusdrmfb. > > This is the last message displayed before the system hangs. This seems > to be hitting a large number of users in Fedora, though certainly not > everyone. This started happening with the 3.5 updates, and is still an > issue. It appears to be a race condition, because various things have > allowed boot to continue for some users, though there is no clear work > around. Has anyone else run across this? Any ideas. For more > background we have the following bugs: > > inteldrmfb: > https://bugzilla.redhat.com/show_bug.cgi?id=843826 > > radeondrmfb: > https://bugzilla.redhat.com/show_bug.cgi?id=845745 > > cirrusdrmfb : > https://bugzilla.redhat.com/show_bug.cgi?id=843860 > > It should be noted that the conflicting fb hw usage message is not new, > it has been around for a while, but this is the last message seen before > the hang. Hi, (adding dri-devel mailing list) I started seeing this problem on 3.5-rc6. AFAICT, the system is not actually hung, it's just that no output is showing up on the real (physical) output device (display) -- it's going somewhere else (or to the bit bucket). -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM/V4L2 buffer sharing
Hi Mauro, On Friday 17 August 2012 19:03:47 Mauro Carvalho Chehab wrote: > Em 17-08-2012 18:01, Sylwester Nawrocki escreveu: > > On 08/15/2012 11:09 PM, Laurent Pinchart wrote: > >> On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: > >>> On 08/15/2012 12:06 AM, Laurent Pinchart wrote: > On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: > > On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: > >> This one requires more testing: > >> > >> May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API > >> > >>http://patchwork.linuxtv.org/patch/11268 Sylwester > >>Nawrocki > >> > >> > > > > Hmm, this is not valid any more. Tomasz just posted a new patch series > > that adds DMABUF importer and exporter feature altogether. > > > > [PATCHv8 00/26] Integration of videobuf2 with DMABUF > > > > I guess we need someone else to submit test patches for other H/W than > > just Samsung SoCs. I'm not sure if we've got enough resources to port > > this to other hardware. We have been using these features internally > > for some time already. It's been 2 kernel releases and I can see only > > Ack tags from Laurent on Tomasz's patch series, hence it seems there > > is no wide interest in DMABUF support in V4L2 and this patch series is > > probably going to stay in a fridge for another few kernel releases. > > What would be required to push it to v3.7 ? > >>> > >>> Mauro requested more test coverage on that, which is understood since > >>> this is a fairly important API enhancement and the V4L2 video overlay > >>> API replacement. > >>> > >>> We need DMABUF support added at some webcam driver and a DRM driver with > >>> prime support (or some V4L2 output driver), I guess it would be best to > >>> have that in a PC environment. It looks like i915/radeon/nouveau drivers > >>> already have prime support. > >> > >> uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can > >> easily test that, except that I have no idea how to export buffers on > >> the i915 side when X is running. Have you looked into that ? > > > > All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop > > with i915 driver, but in the running system drmModeGetResources() just > > fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some > > light on this. > > Likely, you need to run with root permission to use it, or to write an Xorg > driver. > > It is probably easier to get the V4L driver there, that uses the > VIDIOC_OVERLAY stuff, and make it work via DMABUF: > http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/ That won't really help for our test cases. I want to capture from a UVC device using DMABUF import directly to the i915 DRM device using DRM export. In order to do so I will need to get hold of GEM objects that I can use to display the data, possibly through the OpenGL API. I'm looking for help on that last point, I can easily handle the UVC capture code myself. > In order to test it, xawtv has already the code needed to talk with the v4l > plugin. > > What the plugin does is to export the video board as a XV extension, > accessible via xawtv. It currently talks with the display card also via XV, > but I believe it won't be hard to port it to work with DMABUF. > > As the interface between xawtv and the v4l plugin is just Xv, changing the > code there from VIDIOC_OVERLAY to DMABUF should be trivial. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: > On 08/17/2012 03:25 PM, Justin M. Forbes wrote: > >> for , we have verified cases on inteldrmfb, radeondrmfb, and >> cirrusdrmfb. >> >> This is the last message displayed before the system hangs. This seems >> to be hitting a large number of users in Fedora, though certainly not >> everyone. This started happening with the 3.5 updates, and is still an >> issue. It appears to be a race condition, because various things have >> allowed boot to continue for some users, though there is no clear work >> around. Has anyone else run across this? Any ideas. For more >> background we have the following bugs: >> >> inteldrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >> >> radeondrmfb: >> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >> >> cirrusdrmfb : >> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >> >> It should be noted that the conflicting fb hw usage message is not new, >> it has been around for a while, but this is the last message seen before >> the hang. > > > Hi, (adding dri-devel mailing list) > > > I started seeing this problem on 3.5-rc6. > > AFAICT, the system is not actually hung, it's just that no output > is showing up on the real (physical) output device (display) -- it's > going somewhere else (or to the bit bucket). > Can we bisect this at all? I worry the intel one will bisect to where we moved the conflict resolution earlier, but I'd like to see if applying that patch earlier causes the issue, since radeon has it. I haven't reproduced this on any hw I own, I also can't get it under qemu. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: >> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >> >>> for , we have verified cases on inteldrmfb, radeondrmfb, and >>> cirrusdrmfb. >>> >>> This is the last message displayed before the system hangs. This seems >>> to be hitting a large number of users in Fedora, though certainly not >>> everyone. This started happening with the 3.5 updates, and is still an >>> issue. It appears to be a race condition, because various things have >>> allowed boot to continue for some users, though there is no clear work >>> around. Has anyone else run across this? Any ideas. For more >>> background we have the following bugs: >>> >>> inteldrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=843826 >>> >>> radeondrmfb: >>> https://bugzilla.redhat.com/show_bug.cgi?id=845745 >>> >>> cirrusdrmfb : >>> https://bugzilla.redhat.com/show_bug.cgi?id=843860 >>> >>> It should be noted that the conflicting fb hw usage message is not new, >>> it has been around for a while, but this is the last message seen before >>> the hang. >> >> >> Hi, (adding dri-devel mailing list) >> >> >> I started seeing this problem on 3.5-rc6. >> >> AFAICT, the system is not actually hung, it's just that no output >> is showing up on the real (physical) output device (display) -- it's >> going somewhere else (or to the bit bucket). >> > > Can we bisect this at all? > > I worry the intel one will bisect to where we moved the conflict > resolution earlier, but I'd like to see if applying that patch earlier > causes the issue, since radeon has it. > > I haven't reproduced this on any hw I own, I also can't get it under qemu. I'm also wondering whether this grub2 related in some way, grub2 is starting to mess with the graphics adapter pointlessly. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.5.x boot hang after conflicting fb hw usage vs VESA VGA - removing generic driver
On 08/17/2012 03:55 PM, Dave Airlie wrote: > On Sat, Aug 18, 2012 at 8:54 AM, Dave Airlie wrote: >> On Sat, Aug 18, 2012 at 8:28 AM, Randy Dunlap wrote: >>> On 08/17/2012 03:25 PM, Justin M. Forbes wrote: >>> for , we have verified cases on inteldrmfb, radeondrmfb, and cirrusdrmfb. This is the last message displayed before the system hangs. This seems to be hitting a large number of users in Fedora, though certainly not everyone. This started happening with the 3.5 updates, and is still an issue. It appears to be a race condition, because various things have allowed boot to continue for some users, though there is no clear work around. Has anyone else run across this? Any ideas. For more background we have the following bugs: inteldrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=843826 radeondrmfb: https://bugzilla.redhat.com/show_bug.cgi?id=845745 cirrusdrmfb : https://bugzilla.redhat.com/show_bug.cgi?id=843860 It should be noted that the conflicting fb hw usage message is not new, it has been around for a while, but this is the last message seen before the hang. >>> >>> >>> Hi, (adding dri-devel mailing list) >>> >>> >>> I started seeing this problem on 3.5-rc6. >>> >>> AFAICT, the system is not actually hung, it's just that no output >>> is showing up on the real (physical) output device (display) -- it's >>> going somewhere else (or to the bit bucket). >>> >> >> Can we bisect this at all? I'll try. >> I worry the intel one will bisect to where we moved the conflict >> resolution earlier, but I'd like to see if applying that patch earlier >> causes the issue, since radeon has it. >> >> I haven't reproduced this on any hw I own, I also can't get it under qemu. > > I'm also wondering whether this grub2 related in some way, grub2 is > starting to mess with the graphics adapter pointlessly. I'm using lilo, not grub. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX
"Lespiau, Damien" writes: > I can't see anything in the docs about an order requirement for those. Right, the docs don't say anything, which is a bit disconcerting. > Not sure why the other way does not make sense. Somehow disabling TX > before RX makes some sense to me (TX enabled without a ready RX looks > weird?, no data should flow as the pipe is shutdown at that point > anyway). Maybe it just does not matter? And here I figured disabling RX before TX made more sense -- otherwise the receiver wouldn't be seeing anything. In other areas of the driver, we're careful to disable receivers before senders (disable CRTC before PLL, etc). > Another detail is that disabling the PLLs seem to have an order in the > disabling sequence, TX, then RX. > > I. Disable CPU FDI Transmitter PLL > II. Disable PCH FDI Receiver PLL That ordering doesn't matter as the FDI receiver and transmitter are both disabled by that point, so they aren't talking at all. -- keith.pack...@intel.com pgpImGWgX3AWa.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/5] Generic panel framework
Hi Tomi, On Friday 17 August 2012 14:42:31 Tomi Valkeinen wrote: > On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: > > What kind of directory structure do you have in mind ? Panels are already > > isolated in drivers/video/panel/ so we could already ditch the panel- > > prefix in drivers. > > The same directory also contains files for the framework and buses. But > perhaps there's no need for additional directories if the amount of > non-panel files is small. And you can easily see from the name that they > are not panel drivers (e.g. mipi_dbi_bus.c). I don't expect the directory to contain many non-panel files, so let's keep it as-is for now. mipi-dbi-bus might not belong to include/video/panel/ though, as it can be used for non-panel devices (at least in theory). The future mipi-dsi-bus certainly will. > > Would you also create include/video/panel/ ? > > Perhaps that would be good. Well, having all the files prefixed with > panel- is not bad as such, but just feel extra. > > > > --- > > > > > > Should we aim for DT only solution from the start? DT is the direction > > > we are going, and I feel the older platform data stuff would be > > > deprecated soon. > > > > Don't forget about non-ARM architectures :-/ We need panel drivers for SH > > as well, which doesn't use DT. I don't think that would be a big issue, a > > DT- compliant solution should be easy to use through board code and > > platform data as well. > > I didn't forget about them as I didn't even think about them ;). I > somehow had the impression that other architectures would also use DT, > sooner or later. I could be mistaken, though. > > And true, it's not a big issue to support both DT and non-DT versions, > but I've been porting omap stuff for DT and keeping the old platform > data stuff also there, and it just feels burdensome. For very simple > panels it's easy, but when you've passing lots of parameters the code > starts to get longer. > > > > This one would be rather impossible with the upper layer handling the > > > enabling of the video stream. Thus I see that the panel driver needs to > > > control the sequences, and the Sharp panel driver's enable would look > > > something like: > > > > > > regulator_enable(...); > > > sleep(); > > > dpi_enable_video(); > > > sleep(); > > > gpip_set(..); > > > > I have to admit I have no better solution to propose at the moment, even > > if I don't really like making the panel control the video stream. When > > several devices will be present in the chain all of them might have > > similar annoying requirements, and my feeling is that the resulting code > > will be quite messy. At the end of the day the only way to really find > > out is to write an implementation. > > If we have a chain of devices, and each device uses the bus interface > from the previous device in the chain, there shouldn't be a problem. In > that model each device can handle the task however is best for it. > > I think the problems come from the divided control we'll have. I mean, > if the panel driver would decide itself what to send to its output, and > it would provide the data (think of an i2c device), this would be very > simple. And it actually is for things like configuration data etc, but > not so for video stream. Would you be able to send incremental patches on top of v2 to implement the solution you have in mind ? It would be neat if you could also implement mipi- dsi-bus for the OMAP DSS and test the code with a real device :-) > > > It could cause some locking issues, though. First the panel's remove > > > could take a lock, but the remove sequence would cause the display > > > driver to call disable on the panel, which could again try to take the > > > same lock... > > > > We have two possible ways of calling panel operations, either directly > > (panel->bus->ops->enable(...)) or indirectly (panel_enable(...)). > > > > The former is what V4L2 currently does with subdevs, and requires display > > drivers to hold a reference to the panel. The later can do without a > > direct reference only if we use a global lock, which is something I would > > like to > > Wouldn't panel_enable() just do the same panel->bus->ops->enable() > anyway, and both require a panel reference? I don't see the difference. Indeed, you're right. I'm not sure what I was thinking about. > > avoid. A panel-wide lock wouldn't work, as the access function would need > > to take the lock on a panel instance that can be removed at any time. > > Can't this be handled with some kind of get/put refcounting? If there's > a ref, it can't be removed. Trouble will come when the display driver will hold a reference to the panel, and the panel will hold a reference to the display driver (for instance because the display driver provides the DBI/DSI bus, or because it provides a clock used by the panel). > Generally about locks, if we define that panel ops may only be called > exclusively, does it simplify things? I t
[Bug 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #10 from Alexandre Demers 2012-08-18 05:08:00 UTC --- Well, it seems running it through qapitrace doesn't lock. But running only this single test in a terminal does. One thing though: when using qapitrace and looking up state, framebuffer under surfaces is pretty much garbage whatever stage I look at. I don't know if this is expected fom depthstencil-render-miplevels 146 s=z24_s8_d=z32f_s8. -- 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 53111] [bisected] lockups since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=53111 --- Comment #11 from Alexandre Demers 2012-08-18 05:09:01 UTC --- Created attachment 65723 --> https://bugs.freedesktop.org/attachment.cgi?id=65723 apitrace -- 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 V3 1/2] drm/exynos: add platform_device_id table and driver data for exynos5 drm fimd
Hi Leela.
2012/8/16 Leela Krishna Amudala :
> The name of the exynos drm fimd device is renamed to exynos-drm-fimd
> and two device ids are created for exynos4-fb and exynos5-drm-fimd.
> Also, added driver data for exynos5 to pick the fimd version at runtime and
> to choose the VIDTCON register offsets accordingly.
>
> Signed-off-by: Leela Krishna Amudala
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 56
> +++---
> 1 files changed, 51 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 24c0bd4..8379c59 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))
>
> +enum fimd_version_type {
> + VERSION_8, /* FIMD_VERSION8 */
> +};
> +
> +struct drm_fimd_driver_data {
Don't use drm_ prefix for code consistency.
> + enum fimd_version_type fimd_ver;
I don't prefer to check using version, it needs many if statement.
Refer s3c-fb driver and how about use changed base address?
struct fimd_driverdata {
unsigned inttiming_base;
};
static struct fimd_driverdata exynos5_fimd_data = {
.timing_base= 0x2,
};
> +};
> +
> +struct drm_fimd_driver_data exynos5_drm_fimd_driver_data = {
> + .fimd_ver = VERSION_8,
> +};
> +
> 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 drm_fimd_driver_data *drm_fimd_get_driver_data(
> + struct platform_device *pdev)
> +{
> + return (struct drm_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,47 @@ 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 drm_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);
> + if (driver_data->fimd_ver == VERSION_8)
> + writel(ctx->vidcon1, ctx->regs + FIMD_V8_VIDCON1);
> + else
> + writel(ctx->vidcon1, ctx->regs + 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);
> + if (driver_data->fimd_ver == VERSION_8)
> + writel(val, ctx->regs + FIMD_V8_VIDTCON0);
> + else
> + writel(val, ctx->regs + 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);
> + if (driver_data->fimd_ver == VERSION_8)
> + writel(val, ctx->regs + FIMD_V8_VIDTCON1);
> + else
> + writel(val, ctx->regs + VIDTCON1);
>
> /* setup horizontal and vertical display size. */
> val = VIDTCON2_LINEVAL(timing->yres - 1) |
>VIDTCON2_HOZVAL(timing->xres - 1);
> - writel(val, ctx->regs + VIDTCON2);
> + if (driver_data->fimd_ver == VERSION_8)
> + writel(val, ctx->regs + FIMD_V8_VIDTCON2);
> + else
> + writel(val, ctx->regs + VIDTCON2);
>
> /* setup clock source, clock divider, enable dma. */
> val = ctx->vidcon0;
> @@ -982,6 +1016,17 @@ static int fimd_runtime_resume(struct device *dev)
> }
> #endif
>
> +static struct platform_device_id exynos_drm_fimd_driver_ids[] = {
Just use "fimd_driver_ids".
> + {
> + .name = "exynos4-fb",
> + }, {
> + .name = "exynos5-drm-fimd",
I think this name should be "exynos5-fb" because exynos5 fb driver and
clock-exynos5 also use "exynos5-fb".
> + .driver_data= (unsigned
> long)&exynos5_drm_fimd_driver_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(platform, exynos_drm_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_su
[RFC 1/5] video: Add generic display panel core
Signed-off-by: Laurent Pinchart
---
drivers/video/Kconfig|1 +
drivers/video/Makefile |1 +
drivers/video/panel/Kconfig |4 +
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel.c | 269 ++
include/video/panel.h| 111 +
6 files changed, 387 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/panel/Kconfig
create mode 100644 drivers/video/panel/Makefile
create mode 100644 drivers/video/panel/panel.c
create mode 100644 include/video/panel.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..2cc394e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2448,6 +2448,7 @@ source "drivers/video/omap/Kconfig"
source "drivers/video/omap2/Kconfig"
source "drivers/video/exynos/Kconfig"
source "drivers/video/backlight/Kconfig"
+source "drivers/video/panel/Kconfig"
if VT
source "drivers/video/console/Kconfig"
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..577240c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -14,6 +14,7 @@ fb-objs := $(fb-y)
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
obj-y+= backlight/
+obj-y+= panel/
obj-$(CONFIG_EXYNOS_VIDEO) += exynos/
diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
new file mode 100644
index 000..26b1787
--- /dev/null
+++ b/drivers/video/panel/Kconfig
@@ -0,0 +1,4 @@
+menuconfig DISPLAY_PANEL
+ tristate "Display Panel"
+ ---help---
+ Support for display panels for graphics devices.
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
new file mode 100644
index 000..cf5c5e2
--- /dev/null
+++ b/drivers/video/panel/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DISPLAY_PANEL) += panel.o
diff --git a/drivers/video/panel/panel.c b/drivers/video/panel/panel.c
new file mode 100644
index 000..cfca804
--- /dev/null
+++ b/drivers/video/panel/panel.c
@@ -0,0 +1,269 @@
+/*
+ * Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static LIST_HEAD(panel_list);
+static LIST_HEAD(panel_notifiers);
+static DEFINE_MUTEX(panel_mutex);
+
+/**
+ * panel_enable - Set the panel operation mode
+ * @panel: The panel
+ * @enable: Panel operation mode
+ *
+ * - PANEL_ENABLE_OFF turns the panel off completely, possibly including its
+ * power supplies. Communication with a panel in that mode is not possible.
+ * - PANEL_ENABLE_BLANK turns the panel on but keep the output blanked. Full
+ * communication with the panel is supported, including pixel data transfer.
+ * - PANEL_ENABLE_ON turns the whole panel on, including the output.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int panel_enable(struct panel *panel, enum panel_enable_mode enable)
+{
+ int ret;
+
+ if (panel->enable == enable)
+ return 0;
+
+ if (!panel->ops || !panel->ops->enable)
+ return 0;
+
+ ret = panel->ops->enable(panel, enable);
+ if (ret < 0)
+ return ret;
+
+ panel->enable = enable;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(panel_enable);
+
+/**
+ * panel_start_transfer - Start frame transfer
+ * @panel: The panel
+ *
+ * Make the panel ready to receive pixel data and start frame transfer. This
+ * operation can only be called if the panel is in BLANK or ON mode.
+ *
+ * Return 0 on success or a negative error code otherwise.
+ */
+int panel_start_transfer(struct panel *panel)
+{
+ if (!panel->ops || !panel->ops->start_transfer)
+ return 0;
+
+ return panel->ops->start_transfer(panel);
+}
+
+/**
+ * panel_get_modes - Get video modes supported by the panel
+ * @panel: The panel
+ * @modes: Pointer to an array of modes
+ *
+ * Fill the modes argument with a pointer to an array of video modes. The array
+ * is owned by the panel.
+ *
+ * Return the number of supported modes on success (including 0 if no mode is
+ * supported) or a negative error code otherwise.
+ */
+int panel_get_modes(struct panel *panel, const struct fb_videomode **modes)
+{
+ if (!panel->ops || !panel->ops->get_modes)
+ return 0;
+
+ return panel->ops->get_modes(panel, modes);
+}
+EXPORT_SYMBOL_GPL(panel_get_modes);
+
+static void panel_release(struct kref *ref)
+{
+ struct panel *panel = container_of(ref, struct panel, ref);
+
+ if (panel->release)
+ panel->release(panel);
+}
+
+/**
+ * panel_get - get a reference to a panel
+ * @panel: the panel
+ *
+ * Re
[RFC 0/5] Generic panel framework
Hi everybody, While working on DT bindings for the Renesas Mobile SoC display controller (a.k.a. LCDC) I quickly realized that display panel implementation based on board code callbacks would need to be replaced by a driver-based panel framework. Several driver-based panel support solution already exist in the kernel. - The LCD device class is implemented in drivers/video/backlight/lcd.c and exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV API for historical reason, uses board code callback for reset and power management, and doesn't include support for standard features available in today's "smart panels". - OMAP2+ based systems use custom panel drivers available in drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display controller) specific APIs. - Similarly, Exynos based systems use custom panel drivers available in drivers/video/exynos. Only a single driver (s6e8ax0) is currently available. That driver is based on Exynos display controller specific APIs and on the LCD device class API. I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus Lorentzon (working on panel support for ST/Linaro), and we agreed that a generic panel framework for display devices is needed. These patches implement a first proof of concept. One of the main reasons for creating a new panel framework instead of adding missing features to the LCD framework is to avoid being tied to the FBDEV framework. Panels will be used by DRM drivers as well, and their API should thus be subsystem-agnostic. Note that the panel framework used the fb_videomode structure in its API, this will be replaced by a common video mode structure shared across subsystems (there's only so many hours per day). Panels, as used in these patches, are defined as physical devices combining a matrix of pixels and a controller capable of driving that matrix. Panel physical devices are registered as children of the control bus the panel controller is connected to (depending on the panel type, we can find platform devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ... devices). The generic panel framework matches registered panel devices with panel drivers and call the panel drivers probe method, as done by other device classes in the kernel. The driver probe() method is responsible for instantiating a struct panel instance and registering it with the generic panel framework. Display drivers are panel consumers. They register a panel notifier with the framework, which then calls the notifier when a matching panel is registered. The reason for this asynchronous mode of operation, compared to how drivers acquire regulator or clock resources, is that the panel can use resources provided by the display driver. For instance a panel can be a child of the DBI or DSI bus controlled by the display device, or use a clock provided by that device. We can't defer the display device probe until the panel is registered and also defer the panel device probe until the display is registered. As most display drivers need to handle output devices hotplug (HDMI monitors for instance), handling panel through a notification system seemed to be the easiest solution. Note that this brings a different issue after registration, as display and panel drivers would take a reference to each other. Those circular references would make driver unloading impossible. I haven't found a good solution for that problem yet (hence the RFC state of those patches), and I would appreciate your input here. This might also be a hint that the framework design is wrong to start with. I guess I can't get everything right on the first try ;-) Getting hold of the panel is the most complex part. Once done, display drivers can call abstract operations provided by panel drivers to control the panel operation. These patches implement three of those operations (enable, start transfer and get modes). More operations will be needed, and those three operations will likely get modified during review. Most of the panels on devices I own are dumb panels with no control bus, and are thus not the best candidates to design a framework that needs to take complex panels' needs into account. In addition to the generic panel core, I've implemented MIPI DBI (Display Bus Interface, a parallel bus for panels that supports read/write transfers of commands and data) bus support, as well as three panel drivers (dummy panels with no control bus, and Renesas R61505- and R61517-based panels, both using DBI as their control bus). Only the dummy panel driver has been tested as I lack hardware for the two other drivers. I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If you can find a clever way to solve the cyclic references issue described above I'll buy you a beer at the next conference we will both attend. If you think the proposed solution is too complex, or too simple, I'm all ears. I personally alrea
[RFC 2/5] video: panel: Add dummy panel support
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig | 11
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel-dummy.c | 103 +
include/video/panel-dummy.h | 25 +
4 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/panel/panel-dummy.c
create mode 100644 include/video/panel-dummy.h
diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 26b1787..36fb9ca 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -2,3 +2,14 @@ menuconfig DISPLAY_PANEL
tristate "Display Panel"
---help---
Support for display panels for graphics devices.
+
+if DISPLAY_PANEL
+
+config DISPLAY_PANEL_DUMMY
+ tristate "Dummy Display Panel"
+ ---help---
+ Support dummy panels with no control bus.
+
+ If you are in doubt, say N.
+
+endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index cf5c5e2..9fc05c2 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_DISPLAY_PANEL) += panel.o
+obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
diff --git a/drivers/video/panel/panel-dummy.c
b/drivers/video/panel/panel-dummy.c
new file mode 100644
index 000..9ba1447
--- /dev/null
+++ b/drivers/video/panel/panel-dummy.c
@@ -0,0 +1,103 @@
+/*
+ * Dummy Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+
+struct panel_dummy {
+ struct panel panel;
+ const struct panel_dummy_platform_data *pdata;
+};
+
+#define to_panel_dummy(p) container_of(p, struct panel_dummy, panel)
+
+static int panel_dummy_get_modes(struct panel *p,
+const struct fb_videomode **modes)
+{
+ struct panel_dummy *panel = to_panel_dummy(p);
+
+ *modes = panel->pdata->mode;
+ return 1;
+}
+
+static const struct panel_ops panel_dummy_ops = {
+ .get_modes = panel_dummy_get_modes,
+};
+
+static void panel_dummy_release(struct panel *p)
+{
+ struct panel_dummy *panel = to_panel_dummy(p);
+
+ kfree(panel);
+}
+
+static int panel_dummy_remove(struct platform_device *pdev)
+{
+ struct panel_dummy *panel = platform_get_drvdata(pdev);
+
+ platform_set_drvdata(pdev, NULL);
+ panel_unregister(&panel->panel);
+
+ return 0;
+}
+
+static int __devinit panel_dummy_probe(struct platform_device *pdev)
+{
+ const struct panel_dummy_platform_data *pdata = pdev->dev.platform_data;
+ struct panel_dummy *panel;
+ int ret;
+
+ if (pdata == NULL)
+ return -ENODEV;
+
+ panel = kzalloc(sizeof(*panel), GFP_KERNEL);
+ if (panel == NULL)
+ return -ENOMEM;
+
+ panel->pdata = pdata;
+ panel->panel.dev = &pdev->dev;
+ panel->panel.release = panel_dummy_release;
+ panel->panel.ops = &panel_dummy_ops;
+ panel->panel.width = pdata->width;
+ panel->panel.height = pdata->height;
+
+ ret = panel_register(&panel->panel);
+ if (ret < 0) {
+ kfree(panel);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, panel);
+
+ return 0;
+}
+
+static const struct dev_pm_ops panel_dummy_dev_pm_ops = {
+};
+
+static struct platform_driver panel_dummy_driver = {
+ .probe = panel_dummy_probe,
+ .remove = panel_dummy_remove,
+ .driver = {
+ .name = "panel_dummy",
+ .owner = THIS_MODULE,
+ .pm = &panel_dummy_dev_pm_ops,
+ },
+};
+
+module_platform_driver(panel_dummy_driver);
+
+MODULE_AUTHOR("Laurent Pinchart ");
+MODULE_DESCRIPTION("Dummy Display Panel");
+MODULE_LICENSE("GPL");
diff --git a/include/video/panel-dummy.h b/include/video/panel-dummy.h
new file mode 100644
index 000..558a297
--- /dev/null
+++ b/include/video/panel-dummy.h
@@ -0,0 +1,25 @@
+/*
+ * Dummy Display Panel
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __PANEL_DUMMY_H__
+#define __PANEL_DUMMY_H__
+
+#include
+#include
+
+struct panel_dummy_platform_data {
+ unsigned long width;/* Panel width in mm */
+ unsigned long height; /* Panel height in mm */
+ const struct fb_videomode *mode;
+};
+
+#endif /* __PANEL_DUMMY_H__ */
--
1.7.8.6
[RFC 3/5] video: panel: Add MIPI DBI bus support
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig |4 +
drivers/video/panel/Makefile|1 +
drivers/video/panel/panel-dbi.c | 217 +++
include/video/panel-dbi.h | 92 +
4 files changed, 314 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/panel/panel-dbi.c
create mode 100644 include/video/panel-dbi.h
diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 36fb9ca..fd0b3cf 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -12,4 +12,8 @@ config DISPLAY_PANEL_DUMMY
If you are in doubt, say N.
+config DISPLAY_PANEL_DBI
+ tristate
+ default n
+
endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index 9fc05c2..2ab0520 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_DISPLAY_PANEL) += panel.o
obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
+obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
diff --git a/drivers/video/panel/panel-dbi.c b/drivers/video/panel/panel-dbi.c
new file mode 100644
index 000..0511997
--- /dev/null
+++ b/drivers/video/panel/panel-dbi.c
@@ -0,0 +1,217 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
-
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long cmd)
+{
+ dev->bus->ops->write_command(dev->bus, cmd);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_command);
+
+void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long data)
+{
+ dev->bus->ops->write_data(dev->bus, data);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_data);
+
+unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
+{
+ return dev->bus->ops->read_data(dev->bus);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_read_data);
+
+/*
-
+ * Bus type
+ */
+
+static const struct panel_dbi_device_id *
+panel_dbi_match_id(const struct panel_dbi_device_id *id,
+ struct panel_dbi_device *dev)
+{
+ while (id->name[0]) {
+ if (strcmp(dev->name, id->name) == 0) {
+ dev->id_entry = id;
+ return id;
+ }
+ id++;
+ }
+ return NULL;
+}
+
+static int panel_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+ struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+ struct panel_dbi_driver *drv = to_panel_dbi_driver(_drv);
+
+ if (drv->id_table)
+ return panel_dbi_match_id(drv->id_table, dev) != NULL;
+
+ return (strcmp(dev->name, _drv->name) == 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+char *buf)
+{
+ struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+ int len = snprintf(buf, PAGE_SIZE, PANEL_DBI_MODULE_PREFIX "%s\n",
+ dev->name);
+
+ return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute panel_dbi_dev_attrs[] = {
+ __ATTR_RO(modalias),
+ __ATTR_NULL,
+};
+
+static int panel_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
+{
+ struct panel_dbi_device *dev = to_panel_dbi_device(_dev);
+
+ add_uevent_var(env, "MODALIAS=%s%s", PANEL_DBI_MODULE_PREFIX,
+ dev->name);
+ return 0;
+}
+
+static const struct dev_pm_ops panel_dbi_dev_pm_ops = {
+ .runtime_suspend = pm_generic_runtime_suspend,
+ .runtime_resume = pm_generic_runtime_resume,
+ .runtime_idle = pm_generic_runtime_idle,
+ .suspend = pm_generic_suspend,
+ .resume = pm_generic_resume,
+ .freeze = pm_generic_freeze,
+ .thaw = pm_generic_thaw,
+ .poweroff = pm_generic_poweroff,
+ .restore = pm_generic_restore,
+};
+
+static struct bus_type panel_dbi_bus_type = {
+ .name = "mipi-dbi",
+ .dev_attrs = panel_dbi_dev_attrs,
+ .match = panel_dbi_match,
+ .uevent = panel_dbi_uevent,
+ .pm = &panel_dbi_dev_pm_ops,
+};
+
+/*
-
+ * Device and driver (un)registration
+ */
+
+/**
+ * panel_dbi_device_register - register a DBI device
+ * @dev: DBI device we're registering
+ */
+int panel_dbi_device_register(struct panel_dbi_device *dev,
+ struct
[RFC 4/5] video: panel: Add R61505 panel support
The R61505 is a SYS-80 bus panel controller from Renesas. Signed-off-by: Laurent Pinchart --- drivers/video/panel/Kconfig|9 + drivers/video/panel/Makefile |1 + drivers/video/panel/panel-r61505.c | 520 include/video/panel-r61505.h | 27 ++ 4 files changed, 557 insertions(+), 0 deletions(-) create mode 100644 drivers/video/panel/panel-r61505.c create mode 100644 include/video/panel-r61505.h diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig index fd0b3cf..12d7712 100644 --- a/drivers/video/panel/Kconfig +++ b/drivers/video/panel/Kconfig @@ -16,4 +16,13 @@ config DISPLAY_PANEL_DBI tristate default n +config DISPLAY_PANEL_R61505 + tristate "Renesas R61505-based Display Panel" + select DISPLAY_PANEL_DBI + ---help--- + Support panels based on the Renesas R61505 panel controller. + Those panels are controlled through a MIPI DBI interface. + + If you are in doubt, say N. + endif # DISPLAY_PANEL diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile index 2ab0520..e4fb9fe 100644 --- a/drivers/video/panel/Makefile +++ b/drivers/video/panel/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_DISPLAY_PANEL) += panel.o obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o +obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o diff --git a/drivers/video/panel/panel-r61505.c b/drivers/video/panel/panel-r61505.c new file mode 100644 index 000..e09455e --- /dev/null +++ b/drivers/video/panel/panel-r61505.c @@ -0,0 +1,520 @@ +/* + * Renesas R61505-based Display Panels + * + * Copyright (C) 2012 Renesas Solutions Corp. + * Based on SuperH MigoR Quarter VGA LCD Panel + * Copyright (C) 2008 Magnus Damm + * Based on lcd_powertip.c from Kenati Technologies Pvt Ltd. + * Copyright (c) 2007 Ujjwal Pande + * + * Contacts: Laurent Pinchart + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +#define R61505_DEVICE_CODE 0x +#define R61505_DEVICE_CODE_VALUE 0x1505 +#define R61505_DRIVER_OUTPUT_CONTROL 0x0001 +#define R61505_DRIVER_OUTPUT_CONTROL_SM(1 << 10) +#define R61505_DRIVER_OUTPUT_CONTROL_SS(1 << 8) +#define R61505_LCD_WAVEFORM0x0002 +#define R61505_LCD_WAVEFORM_BC0(1 << 9) +#define R61505_LCD_WAVEFORM_EOR(1 << 8) +#define R61505_ENTRY_MODE 0x0003 +#define R61505_ENTRY_MODE_TRIREG (1 << 15) +#define R61505_ENTRY_MODE_DFM (1 << 14) +#define R61505_ENTRY_MODE_BGR (1 << 12) +#define R61505_ENTRY_MODE_HWM (1 << 9) +#define R61505_ENTRY_MODE_ORG (1 << 7) +#define R61505_ENTRY_MODE_ID1 (1 << 5) +#define R61505_ENTRY_MODE_ID0 (1 << 4) +#define R61505_ENTRY_MODE_AM (1 << 3) +#define R61505_RESIZE_CONTROL 0x0004 +#define R61505_RESIZE_CONTROL_RCV(n) (((n) & 3) << 8) +#define R61505_RESIZE_CONTROL_RCH(n) (((n) & 3) << 4) +#define R61505_RESIZE_CONTROL_RSZ_4(3 << 0) +#define R61505_RESIZE_CONTROL_RSZ_2(1 << 0) +#define R61505_RESIZE_CONTROL_RSZ_1(0 << 0) +#define R61505_DISPLAY_CONTROL10x0007 +#define R61505_DISPLAY_CONTROL1_PTDE1 (1 << 13) +#define R61505_DISPLAY_CONTROL1_PTDE0 (1 << 12) +#define R61505_DISPLAY_CONTROL1_BASEE (1 << 8) +#define R61505_DISPLAY_CONTROL1_VON(1 << 6) +#define R61505_DISPLAY_CONTROL1_GON(1 << 5) +#define R61505_DISPLAY_CONTROL1_DTE(1 << 4) +#define R61505_DISPLAY_CONTROL1_COL(1 << 3) +#define R61505_DISPLAY_CONTROL1_D1 (1 << 1) +#define R61505_DISPLAY_CONTROL1_D0 (1 << 0) +#define R61505_DISPLAY_CONTROL20x0008 +#define R61505_DISPLAY_CONTROL2_FP(n) (((n) & 0xf) << 8) +#define R61505_DISPLAY_CONTROL2_BP(n) (((n) & 0xf) << 0) +#define R61505_DISPLAY_CONTROL30x0009 +#define R61505_DISPLAY_CONTROL3_PTS(n) (((n) & 7) << 8) +#define R61505_DISPLAY_CONTROL3_PTG(n) (((n) & 3) << 3) +#define R61505_DISPLAY_CONTROL3_ICS(n) (((n) & 0xf) << 0) +#define R61505_DISPLAY_CONTROL40x000a +#define R61505_DISPLAY_CONTROL4_FMARKOE(1 << 3) +#define R61505_DISPLAY_CONTROL4_FMI_6 (5 << 0) +#define R61505_DISPLAY_CONTROL4_FMI_4 (3 << 0) +#define R61505_DISPLAY_CONTROL4_FMI_2 (1 << 0) +#define R61505_DISPLAY_CONTROL4_FMI_1 (0 << 0) +#define
[RFC 5/5] video: panel: Add R61517 panel support
The R61517 is a MIPI DBI panel controller from Renesas.
Signed-off-by: Laurent Pinchart
---
drivers/video/panel/Kconfig|9 +
drivers/video/panel/Makefile |1 +
drivers/video/panel/panel-r61517.c | 408
include/video/panel-r61517.h | 28 +++
4 files changed, 446 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/panel/panel-r61517.c
create mode 100644 include/video/panel-r61517.h
diff --git a/drivers/video/panel/Kconfig b/drivers/video/panel/Kconfig
index 12d7712..bd643be 100644
--- a/drivers/video/panel/Kconfig
+++ b/drivers/video/panel/Kconfig
@@ -25,4 +25,13 @@ config DISPLAY_PANEL_R61505
If you are in doubt, say N.
+config DISPLAY_PANEL_R61517
+ tristate "Renesas R61517-based Display Panel"
+ select DISPLAY_PANEL_DBI
+ ---help---
+ Support panels based on the Renesas R61517 panel controller.
+ Those panels are controlled through a MIPI DBI interface.
+
+ If you are in doubt, say N.
+
endif # DISPLAY_PANEL
diff --git a/drivers/video/panel/Makefile b/drivers/video/panel/Makefile
index e4fb9fe..3c11d26 100644
--- a/drivers/video/panel/Makefile
+++ b/drivers/video/panel/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_DISPLAY_PANEL) += panel.o
obj-$(CONFIG_DISPLAY_PANEL_DUMMY) += panel-dummy.o
obj-$(CONFIG_DISPLAY_PANEL_DBI) += panel-dbi.o
obj-$(CONFIG_DISPLAY_PANEL_R61505) += panel-r61505.o
+obj-$(CONFIG_DISPLAY_PANEL_R61517) += panel-r61517.o
diff --git a/drivers/video/panel/panel-r61517.c
b/drivers/video/panel/panel-r61517.c
new file mode 100644
index 000..6e8d933
--- /dev/null
+++ b/drivers/video/panel/panel-r61517.c
@@ -0,0 +1,408 @@
+/*
+ * Renesas R61517-based Display Panels
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ * Based on KFR2R09 LCD panel support
+ * Copyright (C) 2009 Magnus Damm
+ * Register settings based on the out-of-tree t33fb.c driver
+ * Copyright (C) 2008 Lineo Solutions, Inc.
+ *
+ * Contacts: Laurent Pinchart
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+struct r61517 {
+ struct panel panel;
+ struct panel_dbi_device *dbi;
+ const struct panel_r61517_platform_data *pdata;
+};
+
+#define to_panel(p)container_of(p, struct r61517, panel)
+
+/*
-
+ * Read, write and reset
+ */
+
+static void r61517_write_command(struct r61517 *panel, u16 reg)
+{
+ panel_dbi_write_command(panel->dbi, reg);
+}
+
+static void r61517_write_data(struct r61517 *panel, u16 data)
+{
+ panel_dbi_write_data(panel->dbi, data);
+}
+
+static void r61517_write(struct r61517 *panel, u16 reg, u16 data)
+{
+ panel_dbi_write_command(panel->dbi, reg);
+ panel_dbi_write_data(panel->dbi, data);
+}
+
+static u16 r61517_read_data(struct r61517 *panel)
+{
+ return panel_dbi_read_data(panel->dbi);
+}
+
+static void __r61517_write_array(struct r61517 *panel, const u8 *data,
+unsigned int len)
+{
+ unsigned int i;
+
+ for (i = 0; i < len; ++i)
+ r61517_write_data(panel, data[i]);
+}
+
+#define r61517_write_array(p, a) \
+ __r61517_write_array(p, a, ARRAY_SIZE(a))
+
+static void r61517_reset(struct r61517 *panel)
+{
+ gpio_set_value(panel->pdata->protect, 0); /* PROTECT/ -> L */
+ gpio_set_value(panel->pdata->reset, 0); /* LCD_RST/ -> L */
+ gpio_set_value(panel->pdata->protect, 1); /* PROTECT/ -> H */
+ usleep_range(1100, 1200);
+ gpio_set_value(panel->pdata->reset, 1); /* LCD_RST/ -> H */
+ usleep_range(10, 100);
+ gpio_set_value(panel->pdata->protect, 0); /* PROTECT/ -> L */
+ msleep(20);
+}
+
+/*
-
+ * Configuration
+ */
+
+static const u8 data_frame_if[] = {
+ 0x02, /* WEMODE: 1=cont, 0=one-shot */
+ 0x00, 0x00,
+ 0x00, /* EPF, DFM */
+ 0x02, /* RIM[1] : 1 (18bpp) */
+};
+
+static const u8 data_panel[] = {
+ 0x0b,
+ 0x63, /* 400 lines */
+ 0x04, 0x00, 0x00, 0x04, 0x11, 0x00, 0x00,
+};
+
+static const u8 data_timing[] = {
+ 0x00, 0x00, 0x13, 0x08, 0x08,
+};
+
+static const u8 data_timing_src[] = {
+ 0x11, 0x01, 0x00, 0x01,
+};
+
+static const u8 data_gamma[] = {
+ 0x01, 0x02, 0x08, 0x23, 0x03, 0x0c, 0x00, 0x06, 0x00, 0x00,
+ 0x01, 0x00, 0x0c, 0x23, 0x03, 0x08, 0x02, 0x06, 0x00, 0x00,
+};
+
+static const u8 data_power[] = {
+ 0x07, 0xc5, 0xdc, 0x02, 0x33, 0x0a,
+};
+
+static unsigned long r61517_read_device_code(struct r61517 *panel)
+{
+ /* access protect OFF */
+ r61517_write(panel, 0xb0, 0x00);
+
[PATCH V3 2/2] video: drm: exynos: Add device tree support
Hi,
2012/8/16 Leela Krishna Amudala :
> Add device tree based discovery support for DRM-FIMD driver.
>
> Signed-off-by: Leela Krishna Amudala
> ---
> Documentation/devicetree/bindings/fb/drm-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/fb/drm-fimd.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/drm-fimd.txt
> b/Documentation/devicetree/bindings/fb/drm-fimd.txt
> new file mode 100644
> index 000..8ad8814
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/drm-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-drm" for fimd using DRM frame work.
Just use "samsung,exynos5-fb" and add to support exynos4-fb
> + - 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:
> + - supports-mipi-panel: Specifies the lcd is mipi panel type
How is this property used?
> + - 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-drm";
> + 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 8379c59..1753846 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 drm_fimd_dt_match[];
> +
Please remove drm_ prefix over all.
> static inline struct drm_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_node(drm_fimd_dt_match, pdev->dev.of_node);
Use of_match_ptr().
> + return (struct drm_fimd_driver_data *)match->data;
> + }
> +#endif
> return (struct drm_fimd_driver_data *)
> platform_get_device_id(pdev)->driver_data;
> }
> @@ -821,12 +831,79 @@ static int
[PATCH] drm/udl: dpms off the crtc when disabled.
From: Dave Airlie
This turns off the crtc when its been disabled,
fixes it not turning off properly the whole time.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_modeset.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index f5dd89e..9159d48 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -354,8 +354,7 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
static void udl_crtc_disable(struct drm_crtc *crtc)
{
-
-
+ udl_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
}
static void udl_crtc_destroy(struct drm_crtc *crtc)
--
1.7.11.2
