[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #71 from Andy Furniss --- (In reply to comment #70) > Andy, does current master work on your rv790 and Unigine ? Yes, Heaven 3.0 is working for me on master. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/f2e13524/attachment.html>
Re: [PATCH v2 2/4] drm/exynos: add support for exynos5420 mixer
On 2013년 06월 19일 15:50, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
This patch can be merged after merging "[PATCH 1/4] drm/exynos: rename
compatible strings for hdmi subsystem".
Best Regards,
- Seung-Woo Kim
> ---
> .../devicetree/bindings/video/exynos_mixer.txt |1 +
> drivers/gpu/drm/exynos/exynos_mixer.c | 49
> +++-
> drivers/gpu/drm/exynos/regs-mixer.h|7 +++
> 3 files changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index a8b063f..c64ddc1 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -4,6 +4,7 @@ Required properties:
> - compatible: value should be:
> 1) "samsung,exynos4210-mixer"
> 2) "samsung,exynos5250-mixer"
> + 3) "samsung,exynos5420-mixer"
>
> - reg: physical base address of the mixer and length of memory mapped
> region.
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2fe6d33..d51ff36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
> enum mixer_version_id {
> MXR_VER_0_0_0_16,
> MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
> };
>
> struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> MXR_CFG_SCAN_PROGRASSIVE);
>
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>
> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
> }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
> *ctx, int win)
> /* setup geometry */
> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
> val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> mixer_cfg_layer(ctx, win, true);
>
> /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> mixer_layer_update(ctx);
>
> mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
> {
> + struct mixer_context *mixer_ctx = ctx;
> u32 w, h;
>
> w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
> drm_display_mode *mode)
> mode->hdisplay, mode->vdisplay, mode->vrefresh,
> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
> exynos_d
[PATCH] drm/prime: support to cache mapping
The drm prime also can support it like GEM CMA supports to cache
mapping. It doesn't allow multiple mappings for one attachment.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/drm_prime.c | 54 +
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..ac48038 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -62,15 +62,29 @@ struct drm_prime_member {
struct dma_buf *dma_buf;
uint32_t handle;
};
+
+struct drm_prime_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+};
+
static int drm_prime_add_buf_handle(struct drm_prime_file_private
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
static int drm_gem_map_attach(struct dma_buf *dma_buf,
struct device *target_dev,
struct dma_buf_attachment *attach)
{
+ struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
+ prime_attach = kzalloc(sizeof(*prime_attach), GFP_KERNEL);
+ if (!prime_attach)
+ return -ENOMEM;
+
+ prime_attach->dir = DMA_NONE;
+ attach->priv = prime_attach;
+
if (!dev->driver->gem_prime_pin)
return 0;
@@ -80,25 +94,59 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
static void drm_gem_map_detach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
{
+ struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
struct drm_device *dev = obj->dev;
+ struct sg_table *sgt;
if (dev->driver->gem_prime_unpin)
dev->driver->gem_prime_unpin(obj);
+
+ if (!prime_attach)
+ return;
+
+ sgt = prime_attach->sgt;
+
+ if (prime_attach->dir != DMA_NONE)
+ dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents,
+ prime_attach->dir);
+
+ sg_free_table(sgt);
+ kfree(sgt);
+ kfree(prime_attach);
+ attach->priv = NULL;
}
static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
+ struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
struct sg_table *sgt;
+ if (WARN_ON(dir == DMA_NONE || !prime_attach))
+ return ERR_PTR(-EINVAL);
+
+ /* return the cached mapping when possible */
+ if (prime_attach->dir == dir)
+ return prime_attach->sgt;
+
+ /*
+* two mappings with different directions for the same attachment are
+* not allowed
+*/
+ if (WARN_ON(prime_attach->dir != DMA_NONE))
+ return ERR_PTR(-EBUSY);
+
mutex_lock(&obj->dev->struct_mutex);
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
- if (!IS_ERR_OR_NULL(sgt))
+ if (!IS_ERR_OR_NULL(sgt)) {
dma_map_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+ prime_attach->sgt = sgt;
+ prime_attach->dir = dir;
+ }
mutex_unlock(&obj->dev->struct_mutex);
return sgt;
@@ -107,9 +155,7 @@ static struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sgt, enum dma_data_direction dir)
{
- dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
- sg_free_table(sgt);
- kfree(sgt);
+ /* nothing to be done here */
}
static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420
Applied.
Thanks,
Inki Dae
> -Original Message-
> From: 김승우 [mailto:sw0312@samsung.com]
> Sent: Wednesday, June 19, 2013 2:34 PM
> To: Rahul Sharma
> Cc: linux-samsung-...@vger.kernel.org; devicetree-
disc...@lists.ozlabs.org;
> dri-devel@lists.freedesktop.org; kgene@samsung.com;
> inki@samsung.com; jo...@samsung.com; r.sh.o...@gmail.com; Seung-Woo
> Kim
> Subject: Re: [PATCH 3/4] drm/exynos: fix interlace resolutions for
> exynos5420
>
> Hi Rahul,
>
> This patch looks good to me.
>
> On 2013년 06월 18일 21:49, Rahul Sharma wrote:
> > Modified code for calculating hdmi IP register values from drm timing
> > values. The modification is based on the inputs from hw team and
> specifically
> > proposed for 1440x576i and 1440x480i. But same changes holds good for
> other
> > interlaced resolutions also.
> >
> > Signed-off-by: Rahul Sharma
>
> Acked-by: Seung-Woo Kim
>
> > ---
> > drivers/gpu/drm/exynos/exynos_hdmi.c | 14 --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > index 8752171..2f807d5 100644
> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > (m->vsync_start - m->vdisplay) / 2);
> > hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
> > hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) /
> 2);
> > - hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
> > - ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
> > + hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay /
> 2);
> > hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
> > hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) +
> 7);
> > hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) +
> 2);
> > @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > (m->htotal / 2) + (m->hsync_start - m->hdisplay));
> > hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
> > hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
> > - hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
> > + hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
> > + hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
> > + hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
> > + hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
> > hdmi_set_reg(tg->vact_st3, 2, 0x0);
> > hdmi_set_reg(tg->vact_st4, 2, 0x0);
> > } else {
> > @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
> > hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
> > hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
> > + hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> > + hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value
> */
> > + hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value
> */
> > }
> >
> > /* Following values & calculations are same irrespective of mode
> type */
> > @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> > hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
> > hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
> > hdmi_set_reg(tg->vsync, 2, 0x1);
> > - hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
> > - hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
> > - hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> > hdmi_set_reg(tg->tg_3d, 1, 0x0);
> > }
> >
> >
>
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Lucas Stach [mailto:l.st...@pengutronix.de] > Sent: Tuesday, June 18, 2013 6:47 PM > To: Inki Dae > Cc: 'Russell King - ARM Linux'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI > mailing list'; 'myungjoo.ham'; 'YoungJun Cho'; linux-arm- > ker...@lists.infradead.org; linux-me...@vger.kernel.org > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: > [...] > > > > > a display device driver. It shouldn't be used within a single driver > > > as a means of passing buffers between userspace and kernel space. > > > > What I try to do is not really such ugly thing. What I try to do is to > > notify that, when CPU tries to access a buffer , to kernel side through > > dmabuf interface. So it's not really to send the buffer to kernel. > > > > Thanks, > > Inki Dae > > > The most basic question about why you are trying to implement this sort > of thing in the dma_buf framework still stands. > > Once you imported a dma_buf into your DRM driver it's a GEM object and > you can and should use the native DRM ioctls to prepare/end a CPU access > to this BO. Then internally to your driver you can use the dma_buf > reservation/fence stuff to provide the necessary cross-device sync. > I don't really want that is used only for DRM drivers. We really need it for all other DMA devices; i.e., v4l2 based drivers. That is what I try to do. And my approach uses reservation to use dma-buf resources but not dma fence stuff anymore. However, I'm looking into Radeon DRM driver for why we need dma fence stuff, and how we can use it if needed. Thanks, Inki Dae > Regards, > Lucas > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
Hi Rahul,
It looks good, at least, to me.
Best Regards,
- Seung-Woo Kim
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
> This patch renames the combatible strings for hdmi, mixer, ddc
> and hdmiphy. It follows the convention of using compatible string
> which represent the SoC in which the IP was added for the first
> time.
>
> Signed-off-by: Rahul Sharma
> ---
> Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
> Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
> Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
> Documentation/devicetree/bindings/video/exynos_mixer.txt |7 +--
> drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
> drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
> drivers/gpu/drm/exynos/exynos_mixer.c | 12
> ++--
> 8 files changed, 26 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 589edee..2ac01ca 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -1,7 +1,9 @@
> Device-Tree bindings for drm hdmi driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmi".
> +- compatible: value should be one among the following:
> + 1) "samsung,exynos4210-hdmi"
> + 2) "samsung,exynos4212-hdmi"
> - reg: physical base address of the hdmi and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -15,7 +17,7 @@ Required properties:
> Example:
>
> hdmi {
> - compatible = "samsung,exynos5-hdmi";
> + compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 0xf 1 3>;
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> index fa166d9..c1bd2ea 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
> @@ -1,12 +1,12 @@
> Device-Tree bindings for hdmiddc driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiddc".
> +- compatible: value should be "samsung,exynos4210-hdmiddc".
> - reg: I2C address of the hdmiddc device.
>
> Example:
>
> hdmiddc {
> - compatible = "samsung,exynos5-hdmiddc";
> + compatible = "samsung,exynos4210-hdmiddc";
> reg = <0x50>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 858f4f9..e59d793 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -1,12 +1,14 @@
> Device-Tree bindings for hdmiphy driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-hdmiphy".
> +- compatible: value should be
> + 1) "samsung,exynos4210-hdmiphy".
> + 2) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
>
> Example:
>
> hdmiphy {
> - compatible = "samsung,exynos5-hdmiphy";
> + compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> };
> diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> index 9b2ea03..a8b063f 100644
> --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
> @@ -1,7 +1,10 @@
> Device-Tree bindings for mixer driver
>
> Required properties:
> -- compatible: value should be "samsung,exynos5-mixer".
> +- compatible: value should be:
> + 1) "samsung,exynos4210-mixer"
> + 2) "samsung,exynos5250-mixer"
> +
> - reg: physical base address of the mixer and length of memory mapped
> region.
> - interrupts: interrupt number to the cpu.
> @@ -9,7 +12,7 @@ Required properties:
> Example:
>
> mixer {
> - compatible = "samsung,exynos5-mixer";
> + compatible = "samsung,exynos5250-mixer";
> reg = <0x1445 0x1>;
> interrupts = <0 94 0>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
> b/drivers/gpu/drm/exynos/exynos_ddc.c
> index 4e9b5ba..1a0cca1 100644
> --- a/drivers/gpu/drm/exynos/exynos_ddc.c
> +++ b/drivers/gpu/drm/exynos/exynos_ddc.c
> @@ -51,7 +51,7 @@ static struct i2c_device_id ddc_idtable[] = {
> #ifdef CONFIG_OF
> static struct of_device_id hdmiddc_match_types[] = {
> {
> - .compatible = "samsung,exynos5-hdmiddc",
Re: [PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420
Hi Rahul,
This patch looks good to me.
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
> Modified code for calculating hdmi IP register values from drm timing
> values. The modification is based on the inputs from hw team and specifically
> proposed for 1440x576i and 1440x480i. But same changes holds good for other
> interlaced resolutions also.
>
> Signed-off-by: Rahul Sharma
Acked-by: Seung-Woo Kim
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 8752171..2f807d5 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> (m->vsync_start - m->vdisplay) / 2);
> hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
> hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) / 2);
> - hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
> - ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
> + hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay / 2);
> hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
> hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) + 7);
> hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) + 2);
> @@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> (m->htotal / 2) + (m->hsync_start - m->hdisplay));
> hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
> hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
> - hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
> + hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
> + hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
> + hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
> + hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
> hdmi_set_reg(tg->vact_st3, 2, 0x0);
> hdmi_set_reg(tg->vact_st4, 2, 0x0);
> } else {
> @@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
> hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
> hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
> + hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> + hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> + hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> }
>
> /* Following values & calculations are same irrespective of mode type */
> @@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context
> *hdata,
> hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
> hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
> hdmi_set_reg(tg->vsync, 2, 0x1);
> - hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
> - hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
> - hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
> hdmi_set_reg(tg->tg_3d, 1, 0x0);
> }
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] idr: Rework idr_preload()
The old idr_preload() used percpu buffers - since the
bitmap/radix/whatever tree only grew by fixed sized nodes, it only had
to ensure there was a node available in the percpu buffer and disable
preemption. This conveniently meant that you didn't have to pass the idr
you were going to allocate from to it.
With the new ida implementation, that doesn't work anymore - the new ida
code grows its bitmap tree by reallocating the entire thing in power of
two increments. Doh.
So we need a slightly different trick. Note that if all allocations from
an idr start by calling idr_prealloc() and disabling premption, at
most nr_cpus() allocations can happen before someone calls
idr_prealloc() again.
So, we just change idr_prealloc() to resize the ida bitmap tree if
there's less than num_possible_cpus() ids available - conveniently, we
already track the number of allocated ids, and the total number of ids
we can have allocated is just nr_leaf_nodes * BITS_PER_LONG. Easy.
This does require a fairly trivial interface change - we now have to
pass the idr we're going to allocate from (and the starting id we're
going to pass to idr_allocate_range()) to idr_prealloc(), so this patch
updates all the callers.
Signed-off-by: Kent Overstreet
Cc: Andrew Morton
Cc: Tejun Heo
Cc: Stefan Richter
Cc: David Airlie
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Steve Wise
Cc: Hoang-Nam Nguyen
Cc: Christoph Raisch
Cc: Mike Marciniszyn
Cc: Doug Gilbert
Cc: "James E.J. Bottomley"
Cc: Christine Caulfield
Cc: David Teigland
Cc: Trond Myklebust
Cc: John McCutchan
Cc: Robert Love
Cc: Eric Paris
Cc: Dave Airlie
Cc: Thomas Hellstrom
Cc: Brian Paul
Cc: Maarten Lankhorst
Cc: Dmitry Torokhov
Cc: Erez Shitrit
Cc: Al Viro
Cc: Haggai Eran
Cc: Jack Morgenstein
Cc: Wolfram Sang
Cc: Greg Kroah-Hartman
Cc: Davidlohr Bueso
Cc: Rik van Riel
Cc: Michel Lespinasse
Cc: linux1394-de...@lists.sourceforge.net
Cc: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: cluster-de...@redhat.com
Cc: linux-...@vger.kernel.org
---
drivers/firewire/core-cdev.c | 2 +-
drivers/gpu/drm/drm_gem.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/infiniband/core/cm.c | 7 +---
drivers/infiniband/core/sa_query.c | 2 +-
drivers/infiniband/core/uverbs_cmd.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch.h | 2 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 2 +-
drivers/infiniband/hw/ehca/ehca_cq.c | 2 +-
drivers/infiniband/hw/ehca/ehca_qp.c | 2 +-
drivers/infiniband/hw/ipath/ipath_driver.c | 2 +-
drivers/infiniband/hw/mlx4/cm.c| 2 +-
drivers/infiniband/hw/qib/qib_init.c | 2 +-
drivers/scsi/sg.c | 2 +-
fs/dlm/lock.c | 2 +-
fs/dlm/recover.c | 2 +-
fs/nfs/nfs4client.c| 2 +-
fs/notify/inotify/inotify_user.c | 2 +-
include/linux/idr.h| 37 +
ipc/util.c | 4 +-
lib/idr.c | 66 ++
21 files changed, 91 insertions(+), 59 deletions(-)
diff --git a/drivers/firewire/core-cdev.c b/drivers/firewire/core-cdev.c
index 436debf..3c70fbc 100644
--- a/drivers/firewire/core-cdev.c
+++ b/drivers/firewire/core-cdev.c
@@ -490,7 +490,7 @@ static int add_client_resource(struct client *client,
int ret;
if (preload)
- idr_preload(gfp_mask);
+ idr_preload(&client->resource_idr, 0, gfp_mask);
spin_lock_irqsave(&client->lock, flags);
if (client->in_shutdown)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1c897b9..cf50894 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,7 +273,7 @@ drm_gem_handle_create(struct drm_file *file_priv,
* Get the user-visible handle using idr. Preload and perform
* allocation under our spinlock.
*/
- idr_preload(GFP_KERNEL);
+ idr_preload(&file_priv->object_idr, 1, GFP_KERNEL);
spin_lock(&file_priv->table_lock);
ret = idr_alloc_range(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
@@ -449,7 +449,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
if (obj == NULL)
return -ENOENT;
- idr_preload(GFP_KERNEL);
+ idr_preload(&dev->object_name_idr, 1, GFP_KERNEL);
spin_lock(&dev->object_name_lock);
if (!obj->name) {
ret = idr_alloc_range(&dev->object_name_idr, obj, 1, 0,
GFP_NOWAIT);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index ccbaed1..9f00706 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -177,7 +177,7 @@ int vmw_reso
[PATCH 09/10] idr: Remove unneeded idr locking, idr_preload() usage
Our new idr implementation does its own locking, instead of forcing it
onto the callers like the old implementation.
Many of the existing idr users need locking for more than just
idr_alloc()/idr_remove()/idr_find() - they're taking refcounts and such
under their locks and we can't touch those.
But a significant number of users had locks that protected nothing more
than the idr data structures itself - those we can get rid of.
Note that we have to be careful when removing locks; in some places,
locks appear to only be protecting idr_alloc()/idr_remove() calls but
they're also used by other code that needs to ensure the idr isn't
modified while it's doing something else - so ideally we want to delete
the lock that protected the idr, or else we have to carefully audit all
the other places it's used.
There's also a fair number of places where things were being done under
the idr lock unnecessarily; drivers/dca/dca-sysfs.c is a good example.
dca->id is set to the id idr_alloc() returns under the lock - but
there's no idr_find() calls under the lock, and dca->id isn't touched in
the idr_remove() paths. So the lock can be safely deleted.
The really nice thing about deleting this unnecessary locking is that it
lets us trivially delete a lot of now unnecessary idr_preload() - with
idr doing its own locking, we can pass GFP_KERNEL to idr_alloc() just
fine.
Signed-off-by: Kent Overstreet
Cc: Andrew Morton
Cc: Tejun Heo
Cc: David Airlie
Cc: Tom Tucker
Cc: Steve Wise
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Alasdair Kergon
Cc: dm-de...@redhat.com
Cc: Samuel Ortiz
Cc: Alex Dubov
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Chris Ball
Cc: "James E.J. Bottomley"
Cc: Willem Riede
Cc: "Kai Mäkisara"
Cc: "Nicholas A. Bellinger"
Cc: Li Zefan
Cc: Vlad Yasevich
Cc: Neil Horman
Cc: "David S. Miller"
Cc: Dave Airlie
Cc: Alon Levy
Cc: Guennadi Liakhovetski
Cc: Christoph Hellwig
Cc: linux-ker...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: osst-us...@lists.sourceforge.net
Cc: target-de...@vger.kernel.org
Cc: contain...@lists.linux-foundation.org
Cc: cgro...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: net...@vger.kernel.org
---
drivers/dca/dca-sysfs.c | 18 +++---
drivers/gpu/drm/qxl/qxl_cmd.c | 4 +---
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_kms.c | 1 -
drivers/gpu/drm/qxl/qxl_release.c | 19 +--
drivers/infiniband/hw/amso1100/c2.h | 1 -
drivers/infiniband/hw/amso1100/c2_qp.c| 20 ++--
drivers/md/dm.c | 22 --
drivers/memstick/core/memstick.c | 17 +++--
drivers/mfd/rtsx_pcr.c| 13 +++--
drivers/misc/c2port/core.c| 11 +--
drivers/misc/tifm_core.c | 15 +++
drivers/mmc/core/host.c | 13 ++---
drivers/scsi/ch.c | 14 ++
drivers/scsi/st.c | 13 +
drivers/target/iscsi/iscsi_target.c | 17 -
drivers/target/iscsi/iscsi_target.h | 1 -
drivers/target/iscsi/iscsi_target_login.c | 12 ++--
include/linux/cgroup.h| 1 -
include/net/sctp/sctp.h | 1 -
kernel/cgroup.c | 9 +
kernel/workqueue.c| 15 ++-
net/9p/util.c | 15 +--
net/sctp/associola.c | 14 ++
net/sctp/protocol.c | 1 -
net/sctp/socket.c | 2 --
26 files changed, 42 insertions(+), 228 deletions(-)
diff --git a/drivers/dca/dca-sysfs.c b/drivers/dca/dca-sysfs.c
index effda66..6be5fbd 100644
--- a/drivers/dca/dca-sysfs.c
+++ b/drivers/dca/dca-sysfs.c
@@ -31,7 +31,6 @@
static struct class *dca_class;
static struct idr dca_idr;
-static spinlock_t dca_idr_lock;
int dca_sysfs_add_req(struct dca_provider *dca, struct device *dev, int slot)
{
@@ -55,23 +54,15 @@ int dca_sysfs_add_provider(struct dca_provider *dca, struct
device *dev)
struct device *cd;
int ret;
- idr_preload(GFP_KERNEL);
- spin_lock(&dca_idr_lock);
-
- ret = idr_alloc(&dca_idr, dca, GFP_NOWAIT);
- if (ret >= 0)
- dca->id = ret;
-
- spin_unlock(&dca_idr_lock);
- idr_preload_end();
+ ret = idr_alloc(&dca_idr, dca, GFP_KERNEL);
if (ret < 0)
return ret;
+ dca->id = ret;
+
cd = device_create(dca_class, dev, MKDEV(0, 0), NULL, "dca%d", dca->id);
if (IS_ERR(cd)) {
- spin_lock(&dca_idr_lock);
idr_remove(&dca_idr, dca->id);
- spin_unlock(&dca_idr_lock);
[PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT
The preferred_bpp value in currently hard-coded to 16.
This causes color corruption on the am335x-evm lcd panel which
requires 32 bpp instead. This changes attempts to use the configured
bpp value from the DT or built-in panel-info struct.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 12 +++-
drivers/gpu/drm/tilcdc/tilcdc_drv.h|1 +
drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 ++
drivers/gpu/drm/tilcdc/tilcdc_slave.c |2 ++
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |2 ++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 2b5461b..f2a6528 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -157,7 +157,9 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
struct platform_device *pdev = dev->platformdev;
struct device_node *node = pdev->dev.of_node;
struct tilcdc_drm_private *priv;
+ struct tilcdc_module *mod;
struct resource *res;
+ u32 bpp = 0;
int ret;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
@@ -256,7 +258,15 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
platform_set_drvdata(pdev, dev);
- priv->fbdev = drm_fbdev_cma_init(dev, 16,
+
+ list_for_each_entry(mod, &module_list, list) {
+ DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
+ bpp = mod->preferred_bpp;
+ if (bpp > 0)
+ break;
+ }
+
+ priv->fbdev = drm_fbdev_cma_init(dev, bpp,
dev->mode_config.num_crtc,
dev->mode_config.num_connector);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 8242b5a..0906843 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -89,6 +89,7 @@ struct tilcdc_module {
const char *name;
struct list_head list;
const struct tilcdc_module_ops *funcs;
+ unsigned int preferred_bpp;
};
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 0917665..86c6732 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -393,6 +393,8 @@ static int panel_probe(struct platform_device *pdev)
goto fail;
}
+ mod->preferred_bpp = panel_mod->info->bpp;
+
panel_mod->backlight = of_find_backlight_by_node(node);
if (panel_mod->backlight)
dev_info(&pdev->dev, "found backlight\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index db1d2fc..8bf4fd1 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -323,6 +323,8 @@ static int slave_probe(struct platform_device *pdev)
goto fail;
}
+ mod->preferred_bpp = slave_info.bpp;
+
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(&pdev->dev, "could not get i2c bus node\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index a36788f..925c7cd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -354,6 +354,8 @@ static int tfp410_probe(struct platform_device *pdev)
goto fail;
}
+ mod->preferred_bpp = dvi_info.bpp;
+
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(&pdev->dev, "could not get i2c bus node\n");
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] radeon: Fix a false positive lockup after 10s of inactivity
On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski wrote: > On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote: >> Andy can you test (without your patch) and see if it helps with your issue : >> http://people.freedesktop.org/~glisse/0001-drm-radeon-update-lockup-tracking-when-scheduling-in.patch > > Testing now. I'll report back in a couple of days. > 3.9.4 plus this patch has been completely stable for several days now. Tested-by: Andy Lutomirski Can you send this to Linux and -stable? Thanks, Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem
On 06/18/13 14:09, Rahul Sharma wrote: Hi Mr. Kukjin, Kindly consider the following patches for review and integration. (+ Mike) Rahul, basically, looks good to me but I'm waiting for Mike's ack on this series... regards, Rahul Sharma. On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K wrote: Hi, Tested this series on snow board and is working fine. Tested-by: Arun Kumar K Arun, thanks for your test. - Kukjin Regards Arun On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma wrote: Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. Arun Kumar K (1): clk/exynos5250: Fix HDMI clock number in documentation Rahul Sharma (4): clk/exynos5250: add mout_hdmi mux clock for hdmi clk/exynos5250: add sclk_hdmiphy in the list of special clocks clk/exynos5250: add clock for tv sysmmu clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- drivers/clk/samsung/clk-exynos5250.c | 18 +- 2 files changed, 24 insertions(+), 6 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider
sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5420.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 59cf177..edd0696 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata =
{
DIV(none, "dout_fimd1", "mout_fimd1", DIV_DISP10, 0, 4),
DIV(none, "dout_mipi1", "mout_mipi1", DIV_DISP10, 16, 8),
DIV(none, "dout_dp1", "mout_dp1", DIV_DISP10, 24, 4),
- DIV(none, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
+ DIV(sclk_pixel, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
/* Audio Block */
DIV(none, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
@@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata
= {
GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
GATE(sclk_hdmi, "sclk_hdmi", "mout_hdmi",
GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_pixel, "sclk_pixel", "dout_hdmi_pixel",
+ GATE(none, "sclk_pixel", "dout_hdmi_pixel",
GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp1, "sclk_dp1", "dout_dp1",
GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] clk/exynos5420: add hdmi mux to change parents in hdmi driver
hdmi driver needs to change the parent of hdmi clock
to pixel clock or hdmiphy clock, based on the stability
of hdmiphy. This patch is exposing the mux for changing
the parent.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
drivers/clk/samsung/clk-exynos5420.c |5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index f0b1ce0..c7a319d 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -182,6 +182,11 @@ clock which they consume.
g3d 501
smmu_tv 502
+ Mux ID
+
+
+ mout_hdmi1024
+
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x1001 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 193d25e..59cf177 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,6 +111,9 @@ enum exynos5420_clks {
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
+ /* mux clocks */
+ mout_hdmi = 1024,
+
nr_clks,
};
@@ -371,7 +374,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata =
{
MUX(none, "mout_mipi1", group2_p, SRC_DISP10, 16, 3),
MUX(none, "mout_dp1", group2_p, SRC_DISP10, 20, 3),
MUX(none, "mout_pixel", group2_p, SRC_DISP10, 24, 3),
- MUX(none, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
+ MUX(mout_hdmi, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
/* MAU Block */
MUX(none, "mout_maudio0", maudio0_p, SRC_MAU, 28, 3),
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] clk/exynos5420: fix the order of parents of hdmi mux
Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e8be481..193d25e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -257,7 +257,7 @@ PNAME(audio2_p) = { "fin_pll", "cdclk2", "sclk_dpll",
"sclk_mpll",
"sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
PNAME(spdif_p) = { "fin_pll", "dout_audio0", "dout_audio1", "dout_audio2",
"spdif_extclk", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(hdmi_p) = { "sclk_hdmiphy", "dout_hdmi_pixel" };
+PNAME(hdmi_p) = { "dout_hdmi_pixel", "sclk_hdmiphy" };
PNAME(maudio0_p) = { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
"sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] clk/exynos5420: add gate clock for tv sysmmu
Adding sysmmu clock for tv for exynos5420.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 596a368..f0b1ce0 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -180,6 +180,7 @@ clock which they consume.
fimc_lite3 495
aclk_g3d 500
g3d 501
+ smmu_tv 502
Example 1: An example of a clock controller node is listed below.
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 0945435..e8be481 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -109,7 +109,7 @@ enum exynos5420_clks {
aclk300_gscl = 460, smmu_gscl0, smmu_gscl1, gscl_wa, gscl_wb, gscl0,
gscl1, clk_3aa, aclk266_g2d = 470, sss, slim_sss, mdma0,
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
- smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d,
+ smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
nr_clks,
};
@@ -696,6 +696,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata
= {
GATE(smmu_mscl0, "smmu_mscl0", "aclk400_mscl", GATE_IP_MSCL, 8, 0, 0),
GATE(smmu_mscl1, "smmu_mscl1", "aclk400_mscl", GATE_IP_MSCL, 9, 0, 0),
GATE(smmu_mscl2, "smmu_mscl2", "aclk400_mscl", GATE_IP_MSCL, 10, 0, 0),
+ GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
};
static __initdata struct of_device_id ext_clk_match[] = {
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] clk/exynos5420: add sclk_hdmiphy to the list of special clocks
Add sclk_hdmiphy to the list of exposed clocks. This is required
by hdmi driver to change the parent of hdmi clock.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 9bcc4b1..596a368 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -59,6 +59,7 @@ clock which they consume.
sclk_pwm 155
sclk_gscl_wa 156
sclk_gscl_wb 157
+ sclk_hdmiphy 158
[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 68a96cb..0945435 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -91,7 +91,7 @@ enum exynos5420_clks {
sclk_i2s2, sclk_pcm1, sclk_pcm2, sclk_spdif, sclk_hdmi, sclk_pixel,
sclk_dp1, sclk_mipi1, sclk_fimd1, sclk_maudio0, sclk_maupcm0,
sclk_usbd300, sclk_usbd301, sclk_usbphy300, sclk_usbphy301, sclk_unipro,
- sclk_pwm, sclk_gscl_wa, sclk_gscl_wb,
+ sclk_pwm, sclk_gscl_wa, sclk_gscl_wb, sclk_hdmiphy,
/* gate clocks */
aclk66_peric = 256, uart0, uart1, uart2, uart3, i2c0, i2c1, i2c2, i2c3,
@@ -268,7 +268,7 @@ struct samsung_fixed_rate_clock
exynos5420_fixed_rate_ext_clks[] __initdata = {
/* fixed rate clocks generated inside the soc */
struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
- FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
+ FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_pwi", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_usbh20", NULL, CLK_IS_ROOT, 4800),
FRATE(none, "mphy_refclk_ixtal24", NULL, CLK_IS_ROOT, 4800),
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. This set dependents on the following patches which add support for Exynos5420 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html Rahul Sharma (5): clk/exynos5420: add sclk_hdmiphy to the list of special clocks clk/exynos5420: add gate clock for tv sysmmu clk/exynos5420: fix the order of parents of hdmi mux clk/exynos5420: add hdmi mux to change parents in hdmi driver clk/exynos5420: assign sclk_pixel id to pixel clock divider .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ drivers/clk/samsung/clk-exynos5420.c | 18 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/exynos: add support for exynos5420 mixer
Sure Seung-Woo,
I will update binding document along with this patch.
regards,
Rahul Sharma.
On Wed, Jun 19, 2013 at 10:54 AM, 김승우 wrote:
> Hi Rahul,
>
> Code part looks good to me but IMHO, binding document for exynos_mixer
> is also fixed like following because compitable string
> samsung,exynos5420-mixer is added with this patch.
>
> Required properties:
> - compatible: value should be:
> 1) "samsung,exynos4210-mixer"
> 2) "samsung,exynos5250-mixer"
> + 3) "samsung,exynos5420-mixer"
>
> Thanks and Regards,
> - Seung-Woo Kim
>
> On 2013년 06월 18일 21:49, Rahul Sharma wrote:
>> Add support for exynos5420 mixer IP in the drm mixer driver.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> drivers/gpu/drm/exynos/exynos_mixer.c | 49
>> +
>> drivers/gpu/drm/exynos/regs-mixer.h |7 +
>> 2 files changed, 44 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 2fe6d33..d51ff36 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -78,6 +78,7 @@ struct mixer_resources {
>> enum mixer_version_id {
>> MXR_VER_0_0_0_16,
>> MXR_VER_16_0_33_0,
>> + MXR_VER_128_0_0_184,
>> };
>>
>> struct mixer_context {
>> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
>> unsigned int height)
>> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
>> MXR_CFG_SCAN_PROGRASSIVE);
>>
>> - /* choosing between porper HD and SD mode */
>> - if (height <= 480)
>> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
>> - else if (height <= 576)
>> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
>> - else if (height <= 720)
>> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> - else if (height <= 1080)
>> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
>> - else
>> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
>> + /* choosing between proper HD and SD mode */
>> + if (height <= 480)
>> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
>> + else if (height <= 576)
>> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
>> + else if (height <= 720)
>> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + else if (height <= 1080)
>> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
>> + else
>> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
>> + }
>>
>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
>> }
>> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
>> *ctx, int win)
>> /* setup geometry */
>> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>>
>> + /* setup display size */
>> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
>> + win == MIXER_DEFAULT_WIN) {
>> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
>> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
>> + mixer_reg_write(res, MXR_RESOLUTION, val);
>> + }
>> +
>> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
>> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
>> val |= MXR_GRP_WH_H_SCALE(x_ratio);
>> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context
>> *ctx, int win)
>> mixer_cfg_layer(ctx, win, true);
>>
>> /* layer update mandatory for mixer 16.0.33.0 */
>> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
>> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
>> + ctx->mxr_ver == MXR_VER_128_0_0_184)
>> mixer_layer_update(ctx);
>>
>> mixer_run(ctx);
>> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>>
>> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
>> {
>> + struct mixer_context *mixer_ctx = ctx;
>> u32 w, h;
>>
>> w = mode->hdisplay;
>> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
>> drm_display_mode *mode)
>> mode->hdisplay, mode->vdisplay, mode->vrefresh,
>> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>>
>> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
>> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
>> + return 0;
>> +
>> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
>> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
>> (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
>> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
>> exynos_drm_hdmi_context *ctx,
>> return 0;
>> }
>>
>> +static struct mixer_drv_data exynos5420_mxr_drv_data = {
>> + .version = MXR_VER_128_0_0_184,
>> + .is_vp_enab
Re: [PATCH 2/4] drm/exynos: add support for exynos5420 mixer
Hi Rahul,
Code part looks good to me but IMHO, binding document for exynos_mixer
is also fixed like following because compitable string
samsung,exynos5420-mixer is added with this patch.
Required properties:
- compatible: value should be:
1) "samsung,exynos4210-mixer"
2) "samsung,exynos5250-mixer"
+ 3) "samsung,exynos5420-mixer"
Thanks and Regards,
- Seung-Woo Kim
On 2013년 06월 18일 21:49, Rahul Sharma wrote:
> Add support for exynos5420 mixer IP in the drm mixer driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 49
> +
> drivers/gpu/drm/exynos/regs-mixer.h |7 +
> 2 files changed, 44 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 2fe6d33..d51ff36 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -78,6 +78,7 @@ struct mixer_resources {
> enum mixer_version_id {
> MXR_VER_0_0_0_16,
> MXR_VER_16_0_33_0,
> + MXR_VER_128_0_0_184,
> };
>
> struct mixer_context {
> @@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> MXR_CFG_SCAN_PROGRASSIVE);
>
> - /* choosing between porper HD and SD mode */
> - if (height <= 480)
> - val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> - else if (height <= 576)
> - val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> - else if (height <= 720)
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> - else if (height <= 1080)
> - val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> - else
> - val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> + /* choosing between proper HD and SD mode */
> + if (height <= 480)
> + val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
> + else if (height <= 576)
> + val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
> + else if (height <= 720)
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + else if (height <= 1080)
> + val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
> + else
> + val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
> + }
>
> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
> }
> @@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context
> *ctx, int win)
> /* setup geometry */
> mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
>
> + /* setup display size */
> + if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
> + win == MIXER_DEFAULT_WIN) {
> + val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
> + val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
> + mixer_reg_write(res, MXR_RESOLUTION, val);
> + }
> +
> val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
> val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
> val |= MXR_GRP_WH_H_SCALE(x_ratio);
> @@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> mixer_cfg_layer(ctx, win, true);
>
> /* layer update mandatory for mixer 16.0.33.0 */
> - if (ctx->mxr_ver == MXR_VER_16_0_33_0)
> + if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
> + ctx->mxr_ver == MXR_VER_128_0_0_184)
> mixer_layer_update(ctx);
>
> mixer_run(ctx);
> @@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
> {
> + struct mixer_context *mixer_ctx = ctx;
> u32 w, h;
>
> w = mode->hdisplay;
> @@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
> drm_display_mode *mode)
> mode->hdisplay, mode->vdisplay, mode->vrefresh,
> (mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
>
> + if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
> + mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
> + return 0;
> +
> if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
> (w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
> (w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
> @@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
> exynos_drm_hdmi_context *ctx,
> return 0;
> }
>
> +static struct mixer_drv_data exynos5420_mxr_drv_data = {
> + .version = MXR_VER_128_0_0_184,
> + .is_vp_enabled = 0,
> +};
> +
> static struct mixer_drv_data exynos5250_mxr_drv_data = {
> .version = MXR_VER_16_0_33_0,
> .is_vp_enabled = 0,
> @@ -1139,6 +1161,9 @@ static struct platform_device_id mixer_driver_types[] =
> {
>
> static struct of_dev
RE: exynos-drm-next todo work.
> -Original Message- > From: Rahul Sharma [mailto:r.sh.o...@gmail.com] > Sent: Tuesday, June 18, 2013 6:46 PM > To: Inki Dae > Cc: linux-samsung-...@vger.kernel.org; DRI mailing list > Subject: Re: exynos-drm-next todo work. > > Hi Mr. Dae, > > Related to HDMI sound support in Alsa, I have posted a working RFC > "exynos-hdmi to CDF complaint display driver". It registers a separate > sound card by registering hdmi audio codec dai and cpu-dai, as you > mentioned. But there is a problem with this approach that I2S being the > single cpu dai for HDMI and Speaker sound card, only one card can > support playback at a time. > > I would like to work on this to provide a more refined solution. > Thanks. However, I think it's not good to use the CDF framework to interface between ALSA SoC DAI driver and DRM HDMI driver. The purpose of the CDF framework is to provide common interfaces to display bus drivers to Linux framebuffer and DRM KMS based display controller drivers as long as I know. So my opinion is to implement ALSA Soc DAI driver-it seems like possible to use as is-based on a new common framework that the other can also use it. Thanks, Inki Dae > regards, > Rahul Sharma. > > On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae wrote: > > Hi all, > > > > I'd like to discuss Exynos DRM TODO work. > > > > There are features we have to solve and implement. The purpose of this > email > > is to share what we have to do so that other guys can be involved > without > > duplicated work. > > > > 1. gscaler based on KMS interfaces - exynos5250 and later use the > gscaler > > device instead of VP device. And now exynos drm driver has gscaler > module as > > a sub module of IPP framework. However, this gscaler module is very > specific > > to IPP framework so it's not easy to reuse this module. So maybe we need > so > > many works for it. > > > > Video play back path using post process (AS IS): > > MFCIPPKMS-FIMD or HDMI > > > > Ideal video play back path using post process (TO BE): > > MFCKMSFIMD or HDMI > > > > The above scenario is to send decoded image data (YUV format) to display > > device via post process. However, we don't really need to use IPP > framework > > in case of using gscaler as VP. All we have to do is to call kms > interface > > (setplane) for it like we did before. > > > > 2. More features for HDMI sound support - we need to implement Exynos > ALSA > > SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, > bit > > rate, and so on from user side should be sent to drm hdmi driver via > ALSA > > interface and the ALSA SoC DAI driver. As of now, it seems like that we > > should implement this driver like OMAP does because there is no common > > framework for interfacing between ALSA SoC DAI driver and DRM HDMI > driver: > > in case of OMAP, it seems like that ALSA SoC audio driver calls > interfaces > > of DSS driver directly. I think we could implement ALSA SoC DAI driver > in > > more generic way if we first implement common framework for it. > > > > Welcome to any volunteer and other opinions. > > > > Thanks, > > Inki Dae > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-samsung- > soc" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #6 from Aaron Watry --- Created attachment 81042 --> https://bugs.freedesktop.org/attachment.cgi?id=81042&action=edit code-in-else.ll -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/34ffed6a/attachment.html>
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #5 from Aaron Watry --- Ack! You're right. I'm so used to the output being arg 0 from every other piglit test that I neglected to check these. With that and the index multiplier changed, these tests also pass on Cedar. All of the test cases currently pass on my pitcairn, except for the code-in-else test, which fails with: cl-program-tester: /home/awatry/src/llvm/include/llvm/Target/TargetRegisterInfo.h:560: const llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getRegClass(unsigned int) const: Assertion `i < getNumRegClasses() && "Register Class ID out of range"' failed. Stack dump: 0.Running pass 'Function Pass Manager' on module 'radeon'. 1.Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@test4' I'll attach the assembly in a follow-up -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/652ba763/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #70 from vincent --- Created attachment 81040 --> https://bugs.freedesktop.org/attachment.cgi?id=81040&action=edit Add a cos/sin pattern Andy, does current master work on your rv790 and Unigine ? Marc, can you try the attached patch and Unigine Heaven ? I'm not sure it'll work (the cos/sin pattern does not trunc anything, but it should at least not crash) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/0ff3f0f6/attachment.html>
Re: [PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
+ mike On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma wrote: > Add clock changes for hdmi subsystem for exynos5250 SoC. These > include addition of new clocks like mout_hdmi and smmu_tv, associating > ID to clk_hdmiphy and some essential corrections. > > This set is based on kukjin's for-next branch at > http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. > > This set dependents on the following patches which add support for Exynos5420 > http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg19264.html > > Rahul Sharma (5): > clk/exynos5420: add sclk_hdmiphy to the list of special clocks > clk/exynos5420: add gate clock for tv sysmmu > clk/exynos5420: fix the order of parents of hdmi mux > clk/exynos5420: add hdmi mux to change parents in hdmi driver > clk/exynos5420: assign sclk_pixel id to pixel clock divider > > .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ > drivers/clk/samsung/clk-exynos5420.c | 18 > +++--- > 2 files changed, 18 insertions(+), 7 deletions(-) > > -- > 1.7.10.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Aaron Watry changed: What|Removed |Added Attachment #80972|0 |1 is obsolete|| --- Comment #6 from Aaron Watry --- Created attachment 81038 --> https://bugs.freedesktop.org/attachment.cgi?id=81038&action=edit Output from llc -debug-only=isel --march=r600 --mcpu=verde < vload-int.ll -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/4d45d210/attachment.html>
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Aaron Watry changed: What|Removed |Added Attachment #80971|0 |1 is obsolete|| --- Comment #5 from Aaron Watry --- Created attachment 81037 --> https://bugs.freedesktop.org/attachment.cgi?id=81037&action=edit LLVM Assembly that is produced from vload-int.cl (after first patch) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/cbf7a602/attachment.html>
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #4 from Aaron Watry --- The good news is that the store error is gone... Now I get a load error :/ LLVM ERROR: Cannot select: 0x2c92af0: i64,ch = load 0x21fe0c8, 0x2c924f0, 0x2c921f0 [ID=15] 0x2c924f0: i64 = add 0x2c91ef0, 0x2c923f0 [ID=13] 0x2c91ef0: i64,ch = CopyFromReg 0x21fe0c8, 0x2c91df0 [ID=12] 0x2c91df0: i64 = Register %vreg0 [ID=1] 0x2c923f0: i64 = Constant<44> [ID=4] 0x2c921f0: i64 = undef [ID=3] I'll attach the llvm assembly in a follow-up -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/3bcfce08/attachment.html>
[PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT
On Tue, Jun 18, 2013 at 6:18 PM, Benoit Parrot wrote:
> The preferred_bpp value in currently hard-coded to 16.
> This causes color corruption on the am335x-evm lcd panel which
> requires 32 bpp instead. This changes attempts to use the configured
> bpp value from the DT or built-in panel-info struct.
>
> Signed-off-by: Benoit Parrot
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c| 12 +++-
> drivers/gpu/drm/tilcdc/tilcdc_drv.h|1 +
> drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 ++
> drivers/gpu/drm/tilcdc/tilcdc_slave.c |2 ++
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |2 ++
> 5 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 2b5461b..f2a6528 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -157,7 +157,9 @@ static int tilcdc_load(struct drm_device *dev, unsigned
> long flags)
> struct platform_device *pdev = dev->platformdev;
> struct device_node *node = pdev->dev.of_node;
> struct tilcdc_drm_private *priv;
> + struct tilcdc_module *mod;
> struct resource *res;
> + u32 bpp = 0;
> int ret;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> @@ -256,7 +258,15 @@ static int tilcdc_load(struct drm_device *dev, unsigned
> long flags)
>
> platform_set_drvdata(pdev, dev);
>
> - priv->fbdev = drm_fbdev_cma_init(dev, 16,
> +
> + list_for_each_entry(mod, &module_list, list) {
> + DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
> + bpp = mod->preferred_bpp;
> + if (bpp > 0)
> + break;
> + }
> +
> + priv->fbdev = drm_fbdev_cma_init(dev, bpp,
> dev->mode_config.num_crtc,
> dev->mode_config.num_connector);
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 8242b5a..0906843 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -89,6 +89,7 @@ struct tilcdc_module {
> const char *name;
> struct list_head list;
> const struct tilcdc_module_ops *funcs;
> + unsigned int preferred_bpp;
> };
>
> void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 0917665..86c6732 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -393,6 +393,8 @@ static int panel_probe(struct platform_device *pdev)
> goto fail;
> }
>
> + mod->preferred_bpp = panel_mod->info->bpp;
> +
> panel_mod->backlight = of_find_backlight_by_node(node);
> if (panel_mod->backlight)
> dev_info(&pdev->dev, "found backlight\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index db1d2fc..8bf4fd1 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -323,6 +323,8 @@ static int slave_probe(struct platform_device *pdev)
> goto fail;
> }
>
> + mod->preferred_bpp = slave_info.bpp;
> +
> i2c_node = of_find_node_by_phandle(i2c_phandle);
> if (!i2c_node) {
> dev_err(&pdev->dev, "could not get i2c bus node\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index a36788f..925c7cd 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -354,6 +354,8 @@ static int tfp410_probe(struct platform_device *pdev)
> goto fail;
> }
>
> + mod->preferred_bpp = dvi_info.bpp;
> +
> i2c_node = of_find_node_by_phandle(i2c_phandle);
> if (!i2c_node) {
> dev_err(&pdev->dev, "could not get i2c bus node\n");
> --
> 1.7.9.5
>
[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider
sclk_pixel is used to represent pixel clock divider on all exynos
SoCs not as a gate clock. It is queried in driver to pass as the
parent to hdmi clock while switching between parents. A new ID can
be asssigned Pixel gate clock which is currently not in use. Pixel
clock gate is default 'on'.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5420.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 59cf177..edd0696 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata =
{
DIV(none, "dout_fimd1", "mout_fimd1", DIV_DISP10, 0, 4),
DIV(none, "dout_mipi1", "mout_mipi1", DIV_DISP10, 16, 8),
DIV(none, "dout_dp1", "mout_dp1", DIV_DISP10, 24, 4),
- DIV(none, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
+ DIV(sclk_pixel, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
/* Audio Block */
DIV(none, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
@@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata
= {
GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
GATE(sclk_hdmi, "sclk_hdmi", "mout_hdmi",
GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
- GATE(sclk_pixel, "sclk_pixel", "dout_hdmi_pixel",
+ GATE(none, "sclk_pixel", "dout_hdmi_pixel",
GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
GATE(sclk_dp1, "sclk_dp1", "dout_dp1",
GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
--
1.7.10.4
[PATCH 4/5] clk/exynos5420: add hdmi mux to change parents in hdmi driver
hdmi driver needs to change the parent of hdmi clock
to pixel clock or hdmiphy clock, based on the stability
of hdmiphy. This patch is exposing the mux for changing
the parent.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |5 +
drivers/clk/samsung/clk-exynos5420.c |5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index f0b1ce0..c7a319d 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -182,6 +182,11 @@ clock which they consume.
g3d 501
smmu_tv 502
+ Mux ID
+
+
+ mout_hdmi1024
+
Example 1: An example of a clock controller node is listed below.
clock: clock-controller at 0x1001 {
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 193d25e..59cf177 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -111,6 +111,9 @@ enum exynos5420_clks {
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
+ /* mux clocks */
+ mout_hdmi = 1024,
+
nr_clks,
};
@@ -371,7 +374,7 @@ struct samsung_mux_clock exynos5420_mux_clks[] __initdata =
{
MUX(none, "mout_mipi1", group2_p, SRC_DISP10, 16, 3),
MUX(none, "mout_dp1", group2_p, SRC_DISP10, 20, 3),
MUX(none, "mout_pixel", group2_p, SRC_DISP10, 24, 3),
- MUX(none, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
+ MUX(mout_hdmi, "mout_hdmi", hdmi_p, SRC_DISP10, 28, 1),
/* MAU Block */
MUX(none, "mout_maudio0", maudio0_p, SRC_MAU, 28, 3),
--
1.7.10.4
[PATCH 3/5] clk/exynos5420: fix the order of parents of hdmi mux
Listing sclk_hdmiphy at 0th position in the list of parents is
causing wrong configuration in reg SRC_DISP10.
Signed-off-by: Rahul Sharma
---
drivers/clk/samsung/clk-exynos5420.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index e8be481..193d25e 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -257,7 +257,7 @@ PNAME(audio2_p) = { "fin_pll", "cdclk2", "sclk_dpll",
"sclk_mpll",
"sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
PNAME(spdif_p) = { "fin_pll", "dout_audio0", "dout_audio1", "dout_audio2",
"spdif_extclk", "sclk_ipll", "sclk_epll", "sclk_rpll" };
-PNAME(hdmi_p) = { "sclk_hdmiphy", "dout_hdmi_pixel" };
+PNAME(hdmi_p) = { "dout_hdmi_pixel", "sclk_hdmiphy" };
PNAME(maudio0_p) = { "fin_pll", "maudio_clk", "sclk_dpll", "sclk_mpll",
"sclk_spll", "sclk_ipll", "sclk_epll", "sclk_rpll" };
--
1.7.10.4
[PATCH 2/5] clk/exynos5420: add gate clock for tv sysmmu
Adding sysmmu clock for tv for exynos5420.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 596a368..f0b1ce0 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -180,6 +180,7 @@ clock which they consume.
fimc_lite3 495
aclk_g3d 500
g3d 501
+ smmu_tv 502
Example 1: An example of a clock controller node is listed below.
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 0945435..e8be481 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -109,7 +109,7 @@ enum exynos5420_clks {
aclk300_gscl = 460, smmu_gscl0, smmu_gscl1, gscl_wa, gscl_wb, gscl0,
gscl1, clk_3aa, aclk266_g2d = 470, sss, slim_sss, mdma0,
aclk333_g2d = 480, g2d, aclk333_432_gscl = 490, smmu_3aa, smmu_fimcl0,
- smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d,
+ smmu_fimcl1, smmu_fimcl3, fimc_lite3, aclk_g3d = 500, g3d, smmu_tv,
nr_clks,
};
@@ -696,6 +696,7 @@ struct samsung_gate_clock exynos5420_gate_clks[] __initdata
= {
GATE(smmu_mscl0, "smmu_mscl0", "aclk400_mscl", GATE_IP_MSCL, 8, 0, 0),
GATE(smmu_mscl1, "smmu_mscl1", "aclk400_mscl", GATE_IP_MSCL, 9, 0, 0),
GATE(smmu_mscl2, "smmu_mscl2", "aclk400_mscl", GATE_IP_MSCL, 10, 0, 0),
+ GATE(smmu_tv, "smmu_tv", "aclk200_disp1", GATE_IP_DISP1, 9, 0, 0),
};
static __initdata struct of_device_id ext_clk_match[] = {
--
1.7.10.4
[PATCH 1/5] clk/exynos5420: add sclk_hdmiphy to the list of special clocks
Add sclk_hdmiphy to the list of exposed clocks. This is required
by hdmi driver to change the parent of hdmi clock.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/clock/exynos5420-clock.txt |1 +
drivers/clk/samsung/clk-exynos5420.c |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 9bcc4b1..596a368 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -59,6 +59,7 @@ clock which they consume.
sclk_pwm 155
sclk_gscl_wa 156
sclk_gscl_wb 157
+ sclk_hdmiphy 158
[Peripheral Clock Gates]
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 68a96cb..0945435 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -91,7 +91,7 @@ enum exynos5420_clks {
sclk_i2s2, sclk_pcm1, sclk_pcm2, sclk_spdif, sclk_hdmi, sclk_pixel,
sclk_dp1, sclk_mipi1, sclk_fimd1, sclk_maudio0, sclk_maupcm0,
sclk_usbd300, sclk_usbd301, sclk_usbphy300, sclk_usbphy301, sclk_unipro,
- sclk_pwm, sclk_gscl_wa, sclk_gscl_wb,
+ sclk_pwm, sclk_gscl_wa, sclk_gscl_wb, sclk_hdmiphy,
/* gate clocks */
aclk66_peric = 256, uart0, uart1, uart2, uart3, i2c0, i2c1, i2c2, i2c3,
@@ -268,7 +268,7 @@ struct samsung_fixed_rate_clock
exynos5420_fixed_rate_ext_clks[] __initdata = {
/* fixed rate clocks generated inside the soc */
struct samsung_fixed_rate_clock exynos5420_fixed_rate_clks[] __initdata = {
- FRATE(none, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
+ FRATE(sclk_hdmiphy, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_pwi", NULL, CLK_IS_ROOT, 2400),
FRATE(none, "sclk_usbh20", NULL, CLK_IS_ROOT, 4800),
FRATE(none, "mphy_refclk_ixtal24", NULL, CLK_IS_ROOT, 4800),
--
1.7.10.4
[PATCH 0/5] clk/exynos5420: add clocks for hdmi subsystem
Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. This set dependents on the following patches which add support for Exynos5420 http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg19264.html Rahul Sharma (5): clk/exynos5420: add sclk_hdmiphy to the list of special clocks clk/exynos5420: add gate clock for tv sysmmu clk/exynos5420: fix the order of parents of hdmi mux clk/exynos5420: add hdmi mux to change parents in hdmi driver clk/exynos5420: assign sclk_pixel id to pixel clock divider .../devicetree/bindings/clock/exynos5420-clock.txt |7 +++ drivers/clk/samsung/clk-exynos5420.c | 18 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) -- 1.7.10.4
[PATCH 5/5] clk/exynos5420: assign sclk_pixel id to pixel clock divider
With this patch, it is at par with Exynos5250 and Exynos4 clocks
where sclk_pixel ID is assigned to a divider clock but in real,
sclk_pixel is listed under gate clocks (enum value).
Alternate to this, I can allocate a new ID, div_pixel, listed under
new category of Divider Clocks for Exyno4, 5250 and 5420.
div_pixel ID can be assigned to pixel clock dividers for all 3 SoCs.
This ID can be accessed by hdmi driver as usual. While sclk_pixel
ID can be left unused for Exyno4, 5250 as there are no pixel clock
gates. And, For 5420, sclk_pixel can optionally be used to
enable/disable the pixel clock gate.
Regards,
Rahul Sharma.
On Tue, Jun 18, 2013 at 8:03 PM, Rahul Sharma
wrote:
> sclk_pixel is used to represent pixel clock divider on all exynos
> SoCs not as a gate clock. It is queried in driver to pass as the
> parent to hdmi clock while switching between parents. A new ID can
> be asssigned Pixel gate clock which is currently not in use. Pixel
> clock gate is default 'on'.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/clk/samsung/clk-exynos5420.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 59cf177..edd0696 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -434,7 +434,7 @@ struct samsung_div_clock exynos5420_div_clks[] __initdata
> = {
> DIV(none, "dout_fimd1", "mout_fimd1", DIV_DISP10, 0, 4),
> DIV(none, "dout_mipi1", "mout_mipi1", DIV_DISP10, 16, 8),
> DIV(none, "dout_dp1", "mout_dp1", DIV_DISP10, 24, 4),
> - DIV(none, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
> + DIV(sclk_pixel, "dout_hdmi_pixel", "mout_pixel", DIV_DISP10, 28, 4),
>
> /* Audio Block */
> DIV(none, "dout_maudio0", "mout_maudio0", DIV_MAU, 20, 4),
> @@ -570,7 +570,7 @@ struct samsung_gate_clock exynos5420_gate_clks[]
> __initdata = {
> GATE_TOP_SCLK_DISP1, 3, CLK_SET_RATE_PARENT, 0),
> GATE(sclk_hdmi, "sclk_hdmi", "mout_hdmi",
> GATE_TOP_SCLK_DISP1, 9, CLK_SET_RATE_PARENT, 0),
> - GATE(sclk_pixel, "sclk_pixel", "dout_hdmi_pixel",
> + GATE(none, "sclk_pixel", "dout_hdmi_pixel",
> GATE_TOP_SCLK_DISP1, 10, CLK_SET_RATE_PARENT, 0),
> GATE(sclk_dp1, "sclk_dp1", "dout_dp1",
> GATE_TOP_SCLK_DISP1, 20, CLK_SET_RATE_PARENT, 0),
> --
> 1.7.10.4
>
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #13 from Krzysztof A. Sobiecki --- Is someone interested in this patch? -- 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 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality
On 06/19/2013 08:02 AM, Laurent Pinchart wrote: Hi Joonyoung, On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote: Hi, GEM CMA supports dma_buf but it needs GEM CMA specific functionality for dma_buf. We can use prime helpers for dma_buf by commit 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so this patchset is to replace from using GEM CMA specific functions to using prime helpers. Overall this looks good to me, except the that prime helpers don't cache mappings, unlike the current implementation in the GEM CMA helpers. Could that be fixed in the prime helpers first ? Right, i will update it first. Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/prime: Honor requested file flags when exporting a buffer
On Wed, Jun 19, 2013 at 11:14 AM, Laurent Pinchart wrote: > The DRM PRIME API passes file flags to the driver for the exported > buffer. Honor them instead of hardcoding 0600. > > Signed-off-by: Laurent Pinchart (this time keeping cc's). Pushed to drm-fixes. thanks for noticing/fixing Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: Constify the pretty-print functions
On Wed, Jun 19, 2013 at 10:53 AM, Laurent Pinchart wrote: > Hi Ville, > > On Friday 07 June 2013 18:43:07 ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> The structures and strings involved with various pretty-print functions >> aren't meant to be modified, so make them all const. The exception is >> drm_connector_enum_list which does get modified in drm_connector_init(). >> >> While at it move the drm_get_connector_status_name() prototype from >> drmP.h to drm_crtc.h where it belongs. > > This breaks compilation on drm-next: > > drivers/gpu/drm/drm_fb_helper.c: In function > ‘drm_fb_helper_parse_command_line’: > drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of > ‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled > by default] > In file included from drivers/gpu/drm/drm_fb_helper.c:35:0: > include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type > ‘const char The fix is in the fbdev tree, which appears not to be in -next, fail. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] ARM/dts: change compatible strings for hdmi subsystem
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma
---
arch/arm/boot/dts/cros5250-common.dtsi|4 ++--
arch/arm/boot/dts/exynos5250-smdk5250.dts |4 ++--
arch/arm/boot/dts/exynos5250.dtsi |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 3f0239e..dc259e8b 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -190,7 +190,7 @@
samsung,i2c-max-bus-freq = <66000>;
hdmiddc at 50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -224,7 +224,7 @@
samsung,i2c-max-bus-freq = <378000>;
hdmiphy at 38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e0c792..f320d7c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -72,7 +72,7 @@
samsung,i2c-max-bus-freq = <66000>;
hdmiddc at 50 {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
};
@@ -102,7 +102,7 @@
samsung,i2c-max-bus-freq = <66000>;
hdmiphy at 38 {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4212-hdmiphy";
reg = <0x38>;
};
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 0673524..2f7763b 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -601,7 +601,7 @@
};
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
clocks = <&clock 333>, <&clock 136>, <&clock 137>,
@@ -611,7 +611,7 @@
};
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
--
1.7.10.4
[PATCH 3/4] drm/exynos: fix interlace resolutions for exynos5420
Modified code for calculating hdmi IP register values from drm timing
values. The modification is based on the inputs from hw team and specifically
proposed for 1440x576i and 1440x480i. But same changes holds good for other
interlaced resolutions also.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8752171..2f807d5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1557,8 +1557,7 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m->vsync_start - m->vdisplay) / 2);
hdmi_set_reg(core->v2_blank, 2, m->vtotal / 2);
hdmi_set_reg(core->v1_blank, 2, (m->vtotal - m->vdisplay) / 2);
- hdmi_set_reg(core->v_blank_f0, 2, (m->vtotal +
- ((m->vsync_end - m->vsync_start) * 4) + 5) / 2);
+ hdmi_set_reg(core->v_blank_f0, 2, m->vtotal - m->vdisplay / 2);
hdmi_set_reg(core->v_blank_f1, 2, m->vtotal);
hdmi_set_reg(core->v_sync_line_aft_2, 2, (m->vtotal / 2) + 7);
hdmi_set_reg(core->v_sync_line_aft_1, 2, (m->vtotal / 2) + 2);
@@ -1568,7 +1567,10 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
(m->htotal / 2) + (m->hsync_start - m->hdisplay));
hdmi_set_reg(tg->vact_st, 2, (m->vtotal - m->vdisplay) / 2);
hdmi_set_reg(tg->vact_sz, 2, m->vdisplay / 2);
- hdmi_set_reg(tg->vact_st2, 2, 0x249);/* Reset value + 1*/
+ hdmi_set_reg(tg->vact_st2, 2, m->vtotal - m->vdisplay / 2);
+ hdmi_set_reg(tg->vsync2, 2, (m->vtotal / 2) + 1);
+ hdmi_set_reg(tg->vsync_bot_hdmi, 2, (m->vtotal / 2) + 1);
+ hdmi_set_reg(tg->field_bot_hdmi, 2, (m->vtotal / 2) + 1);
hdmi_set_reg(tg->vact_st3, 2, 0x0);
hdmi_set_reg(tg->vact_st4, 2, 0x0);
} else {
@@ -1590,6 +1592,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg->vact_st2, 2, 0x248); /* Reset value */
hdmi_set_reg(tg->vact_st3, 2, 0x47b); /* Reset value */
hdmi_set_reg(tg->vact_st4, 2, 0x6ae); /* Reset value */
+ hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
+ hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
+ hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
}
/* Following values & calculations are same irrespective of mode type */
@@ -1621,12 +1626,9 @@ static void hdmi_v14_mode_set(struct hdmi_context *hdata,
hdmi_set_reg(tg->hact_sz, 2, m->hdisplay);
hdmi_set_reg(tg->v_fsz, 2, m->vtotal);
hdmi_set_reg(tg->vsync, 2, 0x1);
- hdmi_set_reg(tg->vsync2, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->field_chg, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->vsync_top_hdmi, 2, 0x1); /* Reset value */
- hdmi_set_reg(tg->vsync_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->field_top_hdmi, 2, 0x1); /* Reset value */
- hdmi_set_reg(tg->field_bot_hdmi, 2, 0x233); /* Reset value */
hdmi_set_reg(tg->tg_3d, 1, 0x0);
}
--
1.7.10.4
[PATCH 2/4] drm/exynos: add support for exynos5420 mixer
Add support for exynos5420 mixer IP in the drm mixer driver.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_mixer.c | 49 +
drivers/gpu/drm/exynos/regs-mixer.h |7 +
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 2fe6d33..d51ff36 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -78,6 +78,7 @@ struct mixer_resources {
enum mixer_version_id {
MXR_VER_0_0_0_16,
MXR_VER_16_0_33_0,
+ MXR_VER_128_0_0_184,
};
struct mixer_context {
@@ -283,17 +284,19 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
unsigned int height)
val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
MXR_CFG_SCAN_PROGRASSIVE);
- /* choosing between porper HD and SD mode */
- if (height <= 480)
- val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
- else if (height <= 576)
- val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
- else if (height <= 720)
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
- else if (height <= 1080)
- val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
- else
- val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
+ /* choosing between proper HD and SD mode */
+ if (height <= 480)
+ val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
+ else if (height <= 576)
+ val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
+ else if (height <= 720)
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ else if (height <= 1080)
+ val |= MXR_CFG_SCAN_HD_1080 | MXR_CFG_SCAN_HD;
+ else
+ val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
+ }
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_SCAN_MASK);
}
@@ -557,6 +560,14 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
/* setup geometry */
mixer_reg_write(res, MXR_GRAPHIC_SPAN(win), win_data->fb_width);
+ /* setup display size */
+ if (ctx->mxr_ver == MXR_VER_128_0_0_184 &&
+ win == MIXER_DEFAULT_WIN) {
+ val = MXR_MXR_RES_HEIGHT(win_data->fb_height);
+ val |= MXR_MXR_RES_WIDTH(win_data->fb_width);
+ mixer_reg_write(res, MXR_RESOLUTION, val);
+ }
+
val = MXR_GRP_WH_WIDTH(win_data->crtc_width);
val |= MXR_GRP_WH_HEIGHT(win_data->crtc_height);
val |= MXR_GRP_WH_H_SCALE(x_ratio);
@@ -581,7 +592,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
int win)
mixer_cfg_layer(ctx, win, true);
/* layer update mandatory for mixer 16.0.33.0 */
- if (ctx->mxr_ver == MXR_VER_16_0_33_0)
+ if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+ ctx->mxr_ver == MXR_VER_128_0_0_184)
mixer_layer_update(ctx);
mixer_run(ctx);
@@ -816,6 +828,7 @@ static void mixer_win_disable(void *ctx, int win)
static int mixer_check_mode(void *ctx, struct drm_display_mode *mode)
{
+ struct mixer_context *mixer_ctx = ctx;
u32 w, h;
w = mode->hdisplay;
@@ -825,6 +838,10 @@ static int mixer_check_mode(void *ctx, struct
drm_display_mode *mode)
mode->hdisplay, mode->vdisplay, mode->vrefresh,
(mode->flags & DRM_MODE_FLAG_INTERLACE) ? 1 : 0);
+ if (mixer_ctx->mxr_ver == MXR_VER_0_0_0_16 ||
+ mixer_ctx->mxr_ver == MXR_VER_128_0_0_184)
+ return 0;
+
if ((w >= 464 && w <= 720 && h >= 261 && h <= 576) ||
(w >= 1024 && w <= 1280 && h >= 576 && h <= 720) ||
(w >= 1664 && w <= 1920 && h >= 936 && h <= 1080))
@@ -1115,6 +1132,11 @@ static int vp_resources_init(struct
exynos_drm_hdmi_context *ctx,
return 0;
}
+static struct mixer_drv_data exynos5420_mxr_drv_data = {
+ .version = MXR_VER_128_0_0_184,
+ .is_vp_enabled = 0,
+};
+
static struct mixer_drv_data exynos5250_mxr_drv_data = {
.version = MXR_VER_16_0_33_0,
.is_vp_enabled = 0,
@@ -1139,6 +1161,9 @@ static struct platform_device_id mixer_driver_types[] = {
static struct of_device_id mixer_match_types[] = {
{
+ .compatible = "samsung,exynos5420-mixer",
+ .data = &exynos5420_mxr_drv_data,
+ }, {
.compatible = "samsung,exynos5250-mixer",
.data = &exynos5250_mxr_drv_data,
}, {
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
b/drivers/gpu/drm/exynos/regs-mixer.h
index 5d8dbc0..4537026 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -44,6 +44,9 @@
#define MXR_CM_COEFF_Y 0x0080
#de
[PATCH 1/4] drm/exynos: rename compatible strings for hdmi subsystem
This patch renames the combatible strings for hdmi, mixer, ddc
and hdmiphy. It follows the convention of using compatible string
which represent the SoC in which the IP was added for the first
time.
Signed-off-by: Rahul Sharma
---
Documentation/devicetree/bindings/video/exynos_hdmi.txt|6 --
Documentation/devicetree/bindings/video/exynos_hdmiddc.txt |4 ++--
Documentation/devicetree/bindings/video/exynos_hdmiphy.txt |6 --
Documentation/devicetree/bindings/video/exynos_mixer.txt |7 +--
drivers/gpu/drm/exynos/exynos_ddc.c|2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c |2 +-
drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +++-
drivers/gpu/drm/exynos/exynos_mixer.c | 12 ++--
8 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee..2ac01ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,7 +1,9 @@
Device-Tree bindings for drm hdmi driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: value should be one among the following:
+ 1) "samsung,exynos4210-hdmi"
+ 2) "samsung,exynos4212-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -15,7 +17,7 @@ Required properties:
Example:
hdmi {
- compatible = "samsung,exynos5-hdmi";
+ compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 0xf 1 3>;
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
index fa166d9..c1bd2ea 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -1,12 +1,12 @@
Device-Tree bindings for hdmiddc driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmiddc".
+- compatible: value should be "samsung,exynos4210-hdmiddc".
- reg: I2C address of the hdmiddc device.
Example:
hdmiddc {
- compatible = "samsung,exynos5-hdmiddc";
+ compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
index 858f4f9..e59d793 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -1,12 +1,14 @@
Device-Tree bindings for hdmiphy driver
Required properties:
-- compatible: value should be "samsung,exynos5-hdmiphy".
+- compatible: value should be
+ 1) "samsung,exynos4210-hdmiphy".
+ 2) "samsung,exynos4212-hdmiphy".
- reg: I2C address of the hdmiphy device.
Example:
hdmiphy {
- compatible = "samsung,exynos5-hdmiphy";
+ compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
};
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea03..a8b063f 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,10 @@
Device-Tree bindings for mixer driver
Required properties:
-- compatible: value should be "samsung,exynos5-mixer".
+- compatible: value should be:
+ 1) "samsung,exynos4210-mixer"
+ 2) "samsung,exynos5250-mixer"
+
- reg: physical base address of the mixer and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@@ -9,7 +12,7 @@ Required properties:
Example:
mixer {
- compatible = "samsung,exynos5-mixer";
+ compatible = "samsung,exynos5250-mixer";
reg = <0x1445 0x1>;
interrupts = <0 94 0>;
};
diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c
b/drivers/gpu/drm/exynos/exynos_ddc.c
index 4e9b5ba..1a0cca1 100644
--- a/drivers/gpu/drm/exynos/exynos_ddc.c
+++ b/drivers/gpu/drm/exynos/exynos_ddc.c
@@ -51,7 +51,7 @@ static struct i2c_device_id ddc_idtable[] = {
#ifdef CONFIG_OF
static struct of_device_id hdmiddc_match_types[] = {
{
- .compatible = "samsung,exynos5-hdmiddc",
+ .compatible = "samsung,exynos4210-hdmiddc",
}, {
/* end node */
}
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 743059f..8752171 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/e
[PATCH 0/4] exynos5420/hdmi: add support for hdmi subsystem
Add support for exynos5420 hdmi subsystem. It adds compatible strings for exynos5420 mixer and Changes the drivers as per IP modifications. This set doesn't have changes for hdmiphy, which will posted independently. This set is based on drm-next branch of Inki Dae's tree at http://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git. Rahul Sharma (4): drm/exynos: rename compatible strings for hdmi subsystem drm/exynos: add support for exynos5420 mixer drm/exynos: fix interlace resolutions for exynos5420 ARM/dts: change compatible strings for hdmi subsystem .../devicetree/bindings/video/exynos_hdmi.txt |6 +- .../devicetree/bindings/video/exynos_hdmiddc.txt |4 +- .../devicetree/bindings/video/exynos_hdmiphy.txt |6 +- .../devicetree/bindings/video/exynos_mixer.txt |7 ++- arch/arm/boot/dts/cros5250-common.dtsi |4 +- arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +- arch/arm/boot/dts/exynos5250.dtsi |4 +- drivers/gpu/drm/exynos/exynos_ddc.c|2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 16 ++--- drivers/gpu/drm/exynos/exynos_hdmiphy.c|4 +- drivers/gpu/drm/exynos/exynos_mixer.c | 61 ++-- drivers/gpu/drm/exynos/regs-mixer.h|7 +++ 12 files changed, 84 insertions(+), 41 deletions(-) -- 1.7.10.4
[PATCH] drm/prime: Honor requested file flags when exporting a buffer
The DRM PRIME API passes file flags to the driver for the exported
buffer. Honor them instead of hardcoding 0600.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_prime.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d92853e..e57c675 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -210,8 +210,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj, int flags)
{
- return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
-0600);
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
}
EXPORT_SYMBOL(drm_gem_prime_export);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Remove some unused stuff from drm_plane
Hello,
On Wednesday 08 May 2013 15:52:10 Laurent Pinchart wrote:
> On Wednesday 08 May 2013 16:40:54 ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > There's a bunch of unused members inside drm_plane, bloating the size of
> > the structure needlessly. Eliminate them.
> >
> > v2: Remove all of it from kernel-doc too
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Laurent Pinchart
Wow, I've managed to review the patch and miss that it broke compilation of
the shmob-drm driver :-( I'll send a patch to fix it.
> > ---
> >
> > drivers/gpu/drm/drm_crtc.c | 2 +-
> > include/drm/drm_crtc.h | 11 ---
> > 2 files changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index d7c449f..e591914 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1739,7 +1739,7 @@ int drm_mode_getplane(struct drm_device *dev, void
> > *data,
> >
> > plane_resp->plane_id = plane->base.id;
> > plane_resp->possible_crtcs = plane->possible_crtcs;
> >
> > - plane_resp->gamma_size = plane->gamma_size;
> > + plane_resp->gamma_size = 0;
> >
> > /*
> >
> > * This ioctl is called twice, once to determine how much space is
> >
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index adb3f9b..e11c6bc 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -654,11 +654,7 @@ struct drm_plane_funcs {
> > * @format_count: number of formats supported
> > * @crtc: currently bound CRTC
> > * @fb: currently bound fb
> > - * @gamma_size: size of gamma table
> > - * @gamma_store: gamma correction table
> > - * @enabled: enabled flag
> > * @funcs: helper functions
> > - * @helper_private: storage for drver layer
> > * @properties: property tracking for this plane
> > */
> >
> > struct drm_plane {
> > @@ -674,14 +670,7 @@ struct drm_plane {
> > struct drm_crtc *crtc;
> > struct drm_framebuffer *fb;
> >
> > - /* CRTC gamma size for reporting to userspace */
> > - uint32_t gamma_size;
> > - uint16_t *gamma_store;
> > -
> > - bool enabled;
> > -
> > const struct drm_plane_funcs *funcs;
> > - void *helper_private;
> >
> > struct drm_object_properties properties;
> > };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: Constify the pretty-print functions
Hi Ville,
On Friday 07 June 2013 18:43:07 ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modified in drm_connector_init().
>
> While at it move the drm_get_connector_status_name() prototype from
> drmP.h to drm_crtc.h where it belongs.
This breaks compilation on drm-next:
drivers/gpu/drm/drm_fb_helper.c: In function
‘drm_fb_helper_parse_command_line’:
drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of
‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled
by default]
In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type
‘const char
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 30 +++---
> include/drm/drmP.h | 1 -
> include/drm/drm_crtc.h | 17 +
> 3 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 079996a..44c3421 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -92,7 +92,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
>
> /* Avoid boilerplate. I'm tired of typing. */
> #define DRM_ENUM_NAME_FN(fnname, list) \
> - char *fnname(int val) \
> + const char *fnname(int val) \
> { \
> int i; \
> for (i = 0; i < ARRAY_SIZE(list); i++) {\
> @@ -105,7 +105,7 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
> /*
> * Global properties
> */
> -static struct drm_prop_enum_list drm_dpms_enum_list[] =
> +static const struct drm_prop_enum_list drm_dpms_enum_list[] =
> {{ DRM_MODE_DPMS_ON, "On" },
> { DRM_MODE_DPMS_STANDBY, "Standby" },
> { DRM_MODE_DPMS_SUSPEND, "Suspend" },
> @@ -117,7 +117,7 @@ DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> /*
> * Optional properties
> */
> -static struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_scaling_mode_enum_list[] =
> {
> { DRM_MODE_SCALE_NONE, "None" },
> { DRM_MODE_SCALE_FULLSCREEN, "Full" },
> @@ -125,7 +125,7 @@ static struct drm_prop_enum_list
> drm_scaling_mode_enum_list[] = { DRM_MODE_SCALE_ASPECT, "Full aspect" },
> };
>
> -static struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> +static const struct drm_prop_enum_list drm_dithering_mode_enum_list[] =
> {
> { DRM_MODE_DITHERING_OFF, "Off" },
> { DRM_MODE_DITHERING_ON, "On" },
> @@ -135,7 +135,7 @@ static struct drm_prop_enum_list
> drm_dithering_mode_enum_list[] = /*
> * Non-global properties, but "required" for certain connectors.
> */
> -static struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -144,7 +144,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
>
> -static struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> @@ -154,7 +154,7 @@ static struct drm_prop_enum_list
> drm_dvi_i_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
>drm_dvi_i_subconnector_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_select_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_select_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -165,7 +165,7 @@ static struct drm_prop_enum_list
> drm_tv_select_enum_list[] =
>
> DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
>
> -static struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> +static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] =
> {
> { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> @@ -177,7 +177,7 @@ static struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] =
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
>
Re: [PATCH v3 1/3] drm: add prime helpers
On 06/18/2013 04:37 PM, Laurent Pinchart wrote:
Hi Aaron,
On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every
driver, create helpers drm_prime_import and drm_prime_export that
implement them in terms of new, lower-level hook functions:
gem_prime_pin: callback when a buffer is created, used to pin buffers
into
GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
export gem_prime_import_sg_table: convert an sg_table into a
drm_gem_object
gem_prime_vmap, gem_prime_vunmap: map and unmap an object
These hooks are optional; drivers can opt in by using
drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
and .gem_prime_export fields of struct drm_driver.
v2:
- Drop .begin_cpu_access. None of the drivers this code replaces
implemented it. Having it here was a leftover from when I was trying to
include i915 in this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three
drivers did. This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.
v3:
- Pass the vaddr down to the driver. This lets drivers that just call
vunmap on the pointer avoid having to store the pointer in their GEM
private structures. - Move documentation into a /** DOC */ comment in
drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
lines to include documentation of the individual functions from drmP.h,
but
the docproc / kernel-doc scripts barf on that file, so hopefully this is
good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: Aaron Plattner
Cc: Daniel Vetter
Cc: David Airlie
---
Documentation/DocBook/drm.tmpl | 4 +
drivers/gpu/drm/drm_prime.c| 186
+-
include/drm/drmP.h | 12 +++
3 files changed, 201 insertions(+), 1 deletion(-)
[snip]
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..366910d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
[snip]
+/**
+ * DOC: PRIME Helpers
+ *
+ * Drivers can implement @gem_prime_export and @gem_prime_import in
terms
of + * simpler APIs by using the helper functions @drm_gem_prime_export
and
+ * @drm_gem_prime_import. These functions implement dma-buf support in
terms of + * five lower-level driver callbacks:
+ *
+ * Export callbacks:
+ *
+ * - @gem_prime_pin (optional): prepare a GEM object for exporting
+ *
+ * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
pages + *
+ * - @gem_prime_vmap: vmap a buffer exported by your driver
+ *
+ * - @gem_prime_vunmap: vunmap a buffer exported by your driver
+ *
+ * Import callback:
+ *
+ * - @gem_prime_import_sg_table (import): produce a GEM object from
another + *driver's scatter/gather table
+ */
+
+struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
+struct drm_gem_object *obj, int flags)
+{
+ if (dev->driver->gem_prime_pin) {
+ int ret = dev->driver->gem_prime_pin(obj);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+ 0600);
Why do you use 0600 instead of the flags passed by the caller ?
Because I copied & pasted it from i915_gem_prime_export prior to commit
5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
pointed it out just now.
That's a pretty valid reason I guess :-) Should I submit a patch or are you
already working on one ?
:) Sorry!
I'm not working on this right now, but I can put it on my queue if you
like. You'll probably be able to fix and test it sooner than I will,
though.
+}
+EXPORT_SYMBOL(drm_gem_prime_export);
--
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT
On Tue, Jun 18, 2013 at 6:18 PM, Benoit Parrot wrote:
> The preferred_bpp value in currently hard-coded to 16.
> This causes color corruption on the am335x-evm lcd panel which
> requires 32 bpp instead. This changes attempts to use the configured
> bpp value from the DT or built-in panel-info struct.
>
> Signed-off-by: Benoit Parrot
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c| 12 +++-
> drivers/gpu/drm/tilcdc/tilcdc_drv.h|1 +
> drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 ++
> drivers/gpu/drm/tilcdc/tilcdc_slave.c |2 ++
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |2 ++
> 5 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 2b5461b..f2a6528 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -157,7 +157,9 @@ static int tilcdc_load(struct drm_device *dev, unsigned
> long flags)
> struct platform_device *pdev = dev->platformdev;
> struct device_node *node = pdev->dev.of_node;
> struct tilcdc_drm_private *priv;
> + struct tilcdc_module *mod;
> struct resource *res;
> + u32 bpp = 0;
> int ret;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> @@ -256,7 +258,15 @@ static int tilcdc_load(struct drm_device *dev, unsigned
> long flags)
>
> platform_set_drvdata(pdev, dev);
>
> - priv->fbdev = drm_fbdev_cma_init(dev, 16,
> +
> + list_for_each_entry(mod, &module_list, list) {
> + DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
> + bpp = mod->preferred_bpp;
> + if (bpp > 0)
> + break;
> + }
> +
> + priv->fbdev = drm_fbdev_cma_init(dev, bpp,
> dev->mode_config.num_crtc,
> dev->mode_config.num_connector);
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 8242b5a..0906843 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -89,6 +89,7 @@ struct tilcdc_module {
> const char *name;
> struct list_head list;
> const struct tilcdc_module_ops *funcs;
> + unsigned int preferred_bpp;
> };
>
> void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> index 0917665..86c6732 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
> @@ -393,6 +393,8 @@ static int panel_probe(struct platform_device *pdev)
> goto fail;
> }
>
> + mod->preferred_bpp = panel_mod->info->bpp;
> +
> panel_mod->backlight = of_find_backlight_by_node(node);
> if (panel_mod->backlight)
> dev_info(&pdev->dev, "found backlight\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index db1d2fc..8bf4fd1 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -323,6 +323,8 @@ static int slave_probe(struct platform_device *pdev)
> goto fail;
> }
>
> + mod->preferred_bpp = slave_info.bpp;
> +
> i2c_node = of_find_node_by_phandle(i2c_phandle);
> if (!i2c_node) {
> dev_err(&pdev->dev, "could not get i2c bus node\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index a36788f..925c7cd 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -354,6 +354,8 @@ static int tfp410_probe(struct platform_device *pdev)
> goto fail;
> }
>
> + mod->preferred_bpp = dvi_info.bpp;
> +
> i2c_node = of_find_node_by_phandle(i2c_phandle);
> if (!i2c_node) {
> dev_err(&pdev->dev, "could not get i2c bus node\n");
> --
> 1.7.9.5
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: Renesas R-Car Display Unit DRM driver
Hello Adam,
Ping ?
Daniel, would it help getting the driver in v3.11 if I resubmit it now with a
get_modes operation that just returns 0 ?
On Friday 14 June 2013 16:03:19 Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 02:54:04AM +0200, Laurent Pinchart wrote:
> > On Friday 07 June 2013 10:50:55 Daniel Vetter wrote:
> > > On Fri, Jun 07, 2013 at 09:44:45AM +0200, Laurent Pinchart wrote:
> > > > On Wednesday 05 June 2013 10:55:05 Daniel Vetter wrote:
> > > > > On Wed, Jun 05, 2013 at 03:51:53AM +0200, Laurent Pinchart wrote:
> > > > > > On Tuesday 04 June 2013 20:36:20 Daniel Vetter wrote:
> > > > > > > On Tue, Jun 4, 2013 at 8:03 PM, Laurent Pinchart wrote:
> > > > > > > > On Tuesday 04 June 2013 16:12:36 Daniel Vetter wrote:
> > > > > > > >> On Tue, Jun 04, 2013 at 04:53:40AM +0200, Laurent Pinchart
wrote:
> > > > > [snip]
> > > > >
> > > > > > > >> > +static int rcar_du_vga_connector_get_modes(struct
> > > > > > > >> > drm_connector
> > > > > > > >> > *connector)
> > > > > > > >> > +{
> > > > > > > >> > + return drm_add_modes_noedid(connector, 1280, 768);
> > > > > > > >> > +}
> > > > > > > >>
> > > > > > > >> This (and the dummy detect function below) looks a bit funny,
> > > > > > > >> since it essentially overrides the default behaviour already
> > > > > > > >> provided by the crtc helpers. Until rcar has at least proper
> > > > > > > >> detect support for VGA
> > > > > > > >
> > > > > > > > I would add that but the DDC signals are not connected on the
> > > > > > > > boards I have access to :-/
> > > > > > > >
> > > > > > > >> I'd just kill this and use the connector force support (and
> > > > > > > >> manually adding the right resolutions).
> > > > > > > >
> > > > > > > > Looks like that's a candidate for better documentation... How
> > > > > > > > does force support work ?
> > > > > > >
> > > > > > > Grep for DRM_FORCE_ON, iirc it can be set on the commandline,
> > > > > > > where you can also force a specific mode. The best I could find
> > > > > > > wrt docs is the kerneldoc for
> > > > > > > drm_mode_parse_command_line_for_connector. With a bit more
> > > > > > > reading it looks like it's intermingled with the fbdev helper
> > > > > > > code, but should be fairly easy to extract and used by your
> > > > > > > driver.
> > > > > >
> > > > > > It makes sense to force the connector state from command line, but
> > > > > > I'm not sure if the same mechanism is the best solution here. As
> > > > > > the driver has no way to know the connector state, the best we can
> > > > > > do is guess what modes are supported. I can just return 0 in the
> > > > > > get_modes handler, but then the core will not call
> > > > > > drm_add_modes_noedid(), and modes will need to be added manually.
> > > > > >
> > > > > > Is your point that for a board on which the VGA connector state
> > > > > > can't be detected, the user should always be responsible for
> > > > > > adding all the modes supported by the VGA monitor on the command
> > > > > > line ?
> > > > >
> > > > > My point is that we already have both an established code for
> > > > > connected outputs without EDID to add fallback modes and means to
> > > > > force connectors to certain states. Your code here seems to reinvent
> > > > > that wheel, so I wonder what we should/need to improve in the common
> > > > > code to suit your needs.
> > > >
> > > > The currently available code might suit my needs, it might just be
> > > > that I fail to see how to use it properly.
> > > >
> > > > Regarding the "code for connected outputs without EDID to add fallback
> > > > modes" you're referring to, is that
> > > >
> > > > if (count == 0 && connector->status ==
> > > > connector_status_connected)
> > > > count = drm_add_modes_noedid(connector, 1024, 768);
> > > >
> > > > in drm_helper_probe_single_connector_modes() ? That function will only
> > > > be called if the connector status is connector_status_connected. There
> > > > are two ways to enforce that:
> > > >
> > > > - returning connector_status_connected from the connector detect()
> > > > operation, which seems to defeat the purpose of having
> > > > connector_status_unknown completely.
> > >
> > > We might want to add such a default mode also for unknown, I'm not sure.
> > > Userspace policy is to first try to light up any connected outputs, and
> > > if> there's none try to light up any unknown outputs. Not sure whether
> > > userspace (i.e. X) will automatically add a default mode. fbcon might
> > > also handle this less gracefully.
> > >
> > > Personally I'm ok with extending this to unknown, it shouldn't really
> > > hurt (since we already try really hard not to leak unknown anywhere
> > > visible).
> >
> > Do you mean something like
> >
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c
> > b/drivers/gpu/drm/drm_crtc_helper.c index f554516..9aae384 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -160,7
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #71 from Andy Furniss --- (In reply to comment #70) > Andy, does current master work on your rv790 and Unigine ? Yes, Heaven 3.0 is working for me on master. -- 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/3] drm: add prime helpers
Hi Aaron,
On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
> On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
> > Hi Aaron,
> >
> > A bit late, but here's a small question.
> >
> > On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
> >> Instead of reimplementing all of the dma_buf functionality in every
> >> driver, create helpers drm_prime_import and drm_prime_export that
> >> implement them in terms of new, lower-level hook functions:
> >> gem_prime_pin: callback when a buffer is created, used to pin buffers
> >> into
> >> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
> >> export gem_prime_import_sg_table: convert an sg_table into a
> >> drm_gem_object
> >> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
> >>
> >> These hooks are optional; drivers can opt in by using
> >> drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
> >> and .gem_prime_export fields of struct drm_driver.
> >>
> >> v2:
> >> - Drop .begin_cpu_access. None of the drivers this code replaces
> >> implemented it. Having it here was a leftover from when I was trying to
> >> include i915 in this rework.
> >> - Use mutex_lock instead of mutex_lock_interruptible, as these three
> >> drivers did. This patch series shouldn't change that behavior.
> >> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
> >>
> >>Rename struct sg_table* variables to 'sgt' for clarity.
> >>
> >> - Update drm.tmpl for these new hooks.
> >>
> >> v3:
> >> - Pass the vaddr down to the driver. This lets drivers that just call
> >> vunmap on the pointer avoid having to store the pointer in their GEM
> >> private structures. - Move documentation into a /** DOC */ comment in
> >> drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
> >> lines to include documentation of the individual functions from drmP.h,
> >> but
> >> the docproc / kernel-doc scripts barf on that file, so hopefully this is
> >> good enough for now.
> >> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
> >>
> >>("drm/prime: drop reference on imported dma-buf come from gem")
> >>
> >> Signed-off-by: Aaron Plattner
> >> Cc: Daniel Vetter
> >> Cc: David Airlie
> >> ---
> >>
> >> Documentation/DocBook/drm.tmpl | 4 +
> >> drivers/gpu/drm/drm_prime.c| 186
> >> +-
> >> include/drm/drmP.h | 12 +++
> >> 3 files changed, 201 insertions(+), 1 deletion(-)
> >
> > [snip]
> >
> >> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> >> index 7f12573..366910d 100644
> >> --- a/drivers/gpu/drm/drm_prime.c
> >> +++ b/drivers/gpu/drm/drm_prime.c
> >
> > [snip]
> >
> >> +/**
> >> + * DOC: PRIME Helpers
> >> + *
> >> + * Drivers can implement @gem_prime_export and @gem_prime_import in
> >> terms
> >> of + * simpler APIs by using the helper functions @drm_gem_prime_export
> >> and
> >> + * @drm_gem_prime_import. These functions implement dma-buf support in
> >> terms of + * five lower-level driver callbacks:
> >> + *
> >> + * Export callbacks:
> >> + *
> >> + * - @gem_prime_pin (optional): prepare a GEM object for exporting
> >> + *
> >> + * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
> >> pages + *
> >> + * - @gem_prime_vmap: vmap a buffer exported by your driver
> >> + *
> >> + * - @gem_prime_vunmap: vunmap a buffer exported by your driver
> >> + *
> >> + * Import callback:
> >> + *
> >> + * - @gem_prime_import_sg_table (import): produce a GEM object from
> >> another + *driver's scatter/gather table
> >> + */
> >> +
> >> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> >> + struct drm_gem_object *obj, int flags)
> >> +{
> >> + if (dev->driver->gem_prime_pin) {
> >> + int ret = dev->driver->gem_prime_pin(obj);
> >> + if (ret)
> >> + return ERR_PTR(ret);
> >> + }
> >> + return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
> >> +0600);
> >
> > Why do you use 0600 instead of the flags passed by the caller ?
>
> Because I copied & pasted it from i915_gem_prime_export prior to commit
> 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
> pointed it out just now.
That's a pretty valid reason I guess :-) Should I submit a patch or are you
already working on one ?
> >> +}
> >> +EXPORT_SYMBOL(drm_gem_prime_export);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] > Sent: Tuesday, June 18, 2013 5:43 PM > To: Inki Dae > Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing > list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter'; > linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote: > > So I'd like to ask for other DRM maintainers. How do you think about it? > it > > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained > by > > Rob) and GEM CMA helper also have same issue Russell pointed out. I > think > > not only the above approach but also the performance is very important. > > CMA uses coherent memory to back their buffers, though that might not be > true of memory obtained from other drivers via dma_buf. Plus, there is > no support in the CMA helper for exporting or importng these buffers. > It's not so. Please see Dave's drm next. recently dmabuf support for the CMA helper has been merged to there. > I guess Intel i915 is only used on x86, which is a coherent platform and > requires no cache maintanence for DMA. > > OMAP DRM does not support importing non-DRM buffers buffers back into Correct. TODO yet. > DRM. Moreover, it will suffer from the problems I described if any > attempt is made to write to the buffer after it has been re-imported. > > Lastly, I should point out that the dma_buf stuff is really only useful > when you need to export a dma buffer from one driver and import it into > another driver - for example to pass data from a camera device driver to Most people know that. > a display device driver. It shouldn't be used within a single driver > as a means of passing buffers between userspace and kernel space. What I try to do is not really such ugly thing. What I try to do is to notify that, when CPU tries to access a buffer , to kernel side through dmabuf interface. So it's not really to send the buffer to kernel. Thanks, Inki Dae
Re: [PATCH v3 1/3] drm: add prime helpers
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every driver,
create helpers drm_prime_import and drm_prime_export that implement them in
terms of new, lower-level hook functions:
gem_prime_pin: callback when a buffer is created, used to pin buffers into
GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
gem_prime_vmap, gem_prime_vunmap: map and unmap an object
These hooks are optional; drivers can opt in by using drm_gem_prime_import
and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
fields of struct drm_driver.
v2:
- Drop .begin_cpu_access. None of the drivers this code replaces
implemented it. Having it here was a leftover from when I was trying to
include i915 in this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
did. This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.
v3:
- Pass the vaddr down to the driver. This lets drivers that just call
vunmap on the pointer avoid having to store the pointer in their GEM
private structures. - Move documentation into a /** DOC */ comment in
drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
lines to include documentation of the individual functions from drmP.h, but
the docproc / kernel-doc scripts barf on that file, so hopefully this is
good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: Aaron Plattner
Cc: Daniel Vetter
Cc: David Airlie
---
Documentation/DocBook/drm.tmpl | 4 +
drivers/gpu/drm/drm_prime.c| 186 +-
include/drm/drmP.h | 12 +++
3 files changed, 201 insertions(+), 1 deletion(-)
[snip]
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..366910d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
[snip]
+/**
+ * DOC: PRIME Helpers
+ *
+ * Drivers can implement @gem_prime_export and @gem_prime_import in terms
of + * simpler APIs by using the helper functions @drm_gem_prime_export and
+ * @drm_gem_prime_import. These functions implement dma-buf support in
terms of + * five lower-level driver callbacks:
+ *
+ * Export callbacks:
+ *
+ * - @gem_prime_pin (optional): prepare a GEM object for exporting
+ *
+ * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
pages + *
+ * - @gem_prime_vmap: vmap a buffer exported by your driver
+ *
+ * - @gem_prime_vunmap: vunmap a buffer exported by your driver
+ *
+ * Import callback:
+ *
+ * - @gem_prime_import_sg_table (import): produce a GEM object from
another + *driver's scatter/gather table
+ */
+
+struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
+struct drm_gem_object *obj, int flags)
+{
+ if (dev->driver->gem_prime_pin) {
+ int ret = dev->driver->gem_prime_pin(obj);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+ 0600);
Why do you use 0600 instead of the flags passed by the caller ?
Because I copied & pasted it from i915_gem_prime_export prior to commit
5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
pointed it out just now.
+}
+EXPORT_SYMBOL(drm_gem_prime_export);
--
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm: add prime helpers
Hi Aaron,
A bit late, but here's a small question.
On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
> Instead of reimplementing all of the dma_buf functionality in every driver,
> create helpers drm_prime_import and drm_prime_export that implement them in
> terms of new, lower-level hook functions:
>
> gem_prime_pin: callback when a buffer is created, used to pin buffers into
> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
> export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
>
> These hooks are optional; drivers can opt in by using drm_gem_prime_import
> and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
> fields of struct drm_driver.
>
> v2:
> - Drop .begin_cpu_access. None of the drivers this code replaces
> implemented it. Having it here was a leftover from when I was trying to
> include i915 in this rework.
> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
> did. This patch series shouldn't change that behavior.
> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
> Rename struct sg_table* variables to 'sgt' for clarity.
> - Update drm.tmpl for these new hooks.
>
> v3:
> - Pass the vaddr down to the driver. This lets drivers that just call
> vunmap on the pointer avoid having to store the pointer in their GEM
> private structures. - Move documentation into a /** DOC */ comment in
> drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
> lines to include documentation of the individual functions from drmP.h, but
> the docproc / kernel-doc scripts barf on that file, so hopefully this is
> good enough for now.
> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
> ("drm/prime: drop reference on imported dma-buf come from gem")
>
> Signed-off-by: Aaron Plattner
> Cc: Daniel Vetter
> Cc: David Airlie
> ---
> Documentation/DocBook/drm.tmpl | 4 +
> drivers/gpu/drm/drm_prime.c| 186 +-
> include/drm/drmP.h | 12 +++
> 3 files changed, 201 insertions(+), 1 deletion(-)
[snip]
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7f12573..366910d 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
[snip]
> +/**
> + * DOC: PRIME Helpers
> + *
> + * Drivers can implement @gem_prime_export and @gem_prime_import in terms
> of + * simpler APIs by using the helper functions @drm_gem_prime_export and
> + * @drm_gem_prime_import. These functions implement dma-buf support in
> terms of + * five lower-level driver callbacks:
> + *
> + * Export callbacks:
> + *
> + * - @gem_prime_pin (optional): prepare a GEM object for exporting
> + *
> + * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
> pages + *
> + * - @gem_prime_vmap: vmap a buffer exported by your driver
> + *
> + * - @gem_prime_vunmap: vunmap a buffer exported by your driver
> + *
> + * Import callback:
> + *
> + * - @gem_prime_import_sg_table (import): produce a GEM object from
> another + *driver's scatter/gather table
> + */
> +
> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
> + struct drm_gem_object *obj, int flags)
> +{
> + if (dev->driver->gem_prime_pin) {
> + int ret = dev->driver->gem_prime_pin(obj);
> + if (ret)
> + return ERR_PTR(ret);
> + }
> + return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
> + 0600);
Why do you use 0600 instead of the flags passed by the caller ?
> +}
> +EXPORT_SYMBOL(drm_gem_prime_export);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/cma: use prim helpers instead GEM CMA specific dma_buf functionality
Hi Joonyoung, On Wednesday 12 June 2013 22:16:14 Joonyoung Shim wrote: > Hi, > > GEM CMA supports dma_buf but it needs GEM CMA specific functionality for > dma_buf. We can use prime helpers for dma_buf by commit > 89177644a7b6306e6084a89eab7e290f4bfef397 "drm: add prime helpers", so > this patchset is to replace from using GEM CMA specific functions to > using prime helpers. Overall this looks good to me, except the that prime helpers don't cache mappings, unlike the current implementation in the GEM CMA helpers. Could that be fixed in the prime helpers first ? > Thanks. > > Joonyoung Shim (3): >drm: add mmap function to prime helpers >drm/cma: add low-level hook functions to use prime helpers >drm/cma: remove GEM CMA specific dma_buf functionality > > drivers/gpu/drm/drm_gem_cma_helper.c | 291 --- > drivers/gpu/drm/drm_prime.c | 5 +- > include/drm/drmP.h | 2 + > include/drm/drm_gem_cma_helper.h | 13 +- > 4 files changed, 56 insertions(+), 255 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Avoid forcing a detection cycle following a hotplug event
Hi Chris, On Saturday 08 June 2013 08:53:30 Chris Wilson wrote: > On Sat, Jun 08, 2013 at 09:28:17AM +0200, Laurent Pinchart wrote: > > Could you please also update Documentation/DocBook/drm.tmpl ? > > It looks out of context there, as nothing explains the hotplug -> > fill_modes -> probe -> detect loop... Sorry, I should have been more precise. You patches changes the prototype of the fill_modes() operation and the drm_helper_probe_single_connector_modes() function, documented in drm.tmpl. I'd like to keep the documentation in sync. > > How about: > > Modes > int (*fill_modes)(struct drm_connector *connector, uint32_t > max_width, uint32_t max_height, bool force); > > Fill the mode list with all supported modes for the connector. If the > max_width and max_height > arguments are non-zero, the implementation must ignore all modes wider > than max_width or higher than > max_height. The driver may use the existing > connector status, unless force is passed. During > a hotplug event, the driver may already have updated its knowledge of the > output and so may simply refresh the modes list from the information it > acquired whilst handling the event. However, the caller may explicitly > request that any cached information be dropped, and for the output to be > queried for its current status and modes - under such circumstances > force is true. > That looks good to me (I would split this in two paragraphs, but that's just nitpicking). Could you please also update the drm_helper_probe_single_connector_modes() description in drm.tmpl ? -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #6 from Aaron Watry --- Created attachment 81042 --> https://bugs.freedesktop.org/attachment.cgi?id=81042&action=edit code-in-else.ll -- 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 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #5 from Aaron Watry --- Ack! You're right. I'm so used to the output being arg 0 from every other piglit test that I neglected to check these. With that and the index multiplier changed, these tests also pass on Cedar. All of the test cases currently pass on my pitcairn, except for the code-in-else test, which fails with: cl-program-tester: /home/awatry/src/llvm/include/llvm/Target/TargetRegisterInfo.h:560: const llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getRegClass(unsigned int) const: Assertion `i < getNumRegClasses() && "Register Class ID out of range"' failed. Stack dump: 0.Running pass 'Function Pass Manager' on module 'radeon'. 1.Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@test4' I'll attach the assembly in a follow-up -- 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 7/9] drm/exynos: use of_get_named_gpio to get hdmi hpd gpio
Thanks Mr. Dae,
Please discard the REST of the patches in this series. I am posting a
another patch-set which has all the patches independent of hdmiphy
related changes.
regards,
Rahul Sharma.
On Mon, Jun 17, 2013 at 8:22 AM, Inki Dae wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>
> 2013/6/14 ???
>>
>> Hello Rahul,
>>
>> this patch is not related with others and it looks good to me.
>>
>> On 2013? 06? 11? 23:11, Rahul Sharma wrote:
>> > Cleanup by removing flags variable from drm_hdmi_dt_parse_pdata
>> > which is not used anywhere. Swtiching to of_get_named_gpio instead
>> > of of_get_named_gpio_flags solved this.
>> >
>> > Signed-off-by: Rahul Sharma
>>
>> Acked-by: Seung-Woo Kim
>>
>> > ---
>> > drivers/gpu/drm/exynos/exynos_hdmi.c |3 +--
>> > 1 file changed, 1 insertion(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > index 1eb5ffb..fc6a9b0 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> > @@ -2081,7 +2081,6 @@ static struct s5p_hdmi_platform_data
>> > *drm_hdmi_dt_parse_pdata
>> > {
>> > struct device_node *np = dev->of_node;
>> > struct s5p_hdmi_platform_data *pd;
>> > - enum of_gpio_flags flags;
>> > u32 value;
>> >
>> > pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
>> > @@ -2095,7 +2094,7 @@ static struct s5p_hdmi_platform_data
>> > *drm_hdmi_dt_parse_pdata
>> > goto err_data;
>> > }
>> >
>> > - pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
>> > + pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
>> >
>> > return pd;
>> >
>> >
>>
>> --
>> Seung-Woo Kim
>> Samsung Software R&D Center
>> --
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-samsung-soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 Tom Stellard changed: What|Removed |Added Attachment #80967|0 |1 is obsolete|| Attachment #80969|0 |1 is obsolete|| --- Comment #4 from Tom Stellard --- Created attachment 81026 --> https://bugs.freedesktop.org/attachment.cgi?id=81026&action=edit Updated piglit tests Thanks for writing the piglit tests, I noticed a few bugs in them though. First, the output argument for all of the tests should be index 2 and not index 0 and second, in test #2 the buffer index should be multiplied by 8 instead of 10. I've fixed the piglit tests in the attached patch and also replaced the '_' with '-' in the filename. The updated tests pass on my Llano APU. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/ea77b44f/attachment.html>
[PATCH v3 1/3] drm: add prime helpers
On 06/18/2013 04:37 PM, Laurent Pinchart wrote:
> Hi Aaron,
>
> On Tuesday 18 June 2013 16:28:15 Aaron Plattner wrote:
>> On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
>>> Hi Aaron,
>>>
>>> A bit late, but here's a small question.
>>>
>>> On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
Instead of reimplementing all of the dma_buf functionality in every
driver, create helpers drm_prime_import and drm_prime_export that
implement them in terms of new, lower-level hook functions:
gem_prime_pin: callback when a buffer is created, used to pin buffers
into
GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
export gem_prime_import_sg_table: convert an sg_table into a
drm_gem_object
gem_prime_vmap, gem_prime_vunmap: map and unmap an object
These hooks are optional; drivers can opt in by using
drm_gem_prime_import and drm_gem_prime_export as the .gem_prime_import
and .gem_prime_export fields of struct drm_driver.
v2:
- Drop .begin_cpu_access. None of the drivers this code replaces
implemented it. Having it here was a leftover from when I was trying to
include i915 in this rework.
- Use mutex_lock instead of mutex_lock_interruptible, as these three
drivers did. This patch series shouldn't change that behavior.
- Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
Rename struct sg_table* variables to 'sgt' for clarity.
- Update drm.tmpl for these new hooks.
v3:
- Pass the vaddr down to the driver. This lets drivers that just call
vunmap on the pointer avoid having to store the pointer in their GEM
private structures. - Move documentation into a /** DOC */ comment in
drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
lines to include documentation of the individual functions from drmP.h,
but
the docproc / kernel-doc scripts barf on that file, so hopefully this is
good enough for now.
- apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
("drm/prime: drop reference on imported dma-buf come from gem")
Signed-off-by: Aaron Plattner
Cc: Daniel Vetter
Cc: David Airlie
---
Documentation/DocBook/drm.tmpl | 4 +
drivers/gpu/drm/drm_prime.c| 186
+-
include/drm/drmP.h | 12 +++
3 files changed, 201 insertions(+), 1 deletion(-)
>>>
>>> [snip]
>>>
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7f12573..366910d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
>>>
>>> [snip]
>>>
+/**
+ * DOC: PRIME Helpers
+ *
+ * Drivers can implement @gem_prime_export and @gem_prime_import in
terms
of + * simpler APIs by using the helper functions @drm_gem_prime_export
and
+ * @drm_gem_prime_import. These functions implement dma-buf support in
terms of + * five lower-level driver callbacks:
+ *
+ * Export callbacks:
+ *
+ * - @gem_prime_pin (optional): prepare a GEM object for exporting
+ *
+ * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
pages + *
+ * - @gem_prime_vmap: vmap a buffer exported by your driver
+ *
+ * - @gem_prime_vunmap: vunmap a buffer exported by your driver
+ *
+ * Import callback:
+ *
+ * - @gem_prime_import_sg_table (import): produce a GEM object from
another + *driver's scatter/gather table
+ */
+
+struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
+ struct drm_gem_object *obj, int flags)
+{
+ if (dev->driver->gem_prime_pin) {
+ int ret = dev->driver->gem_prime_pin(obj);
+ if (ret)
+ return ERR_PTR(ret);
+ }
+ return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+0600);
>>>
>>> Why do you use 0600 instead of the flags passed by the caller ?
>>
>> Because I copied & pasted it from i915_gem_prime_export prior to commit
>> 5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
>> pointed it out just now.
>
> That's a pretty valid reason I guess :-) Should I submit a patch or are you
> already working on one ?
:) Sorry!
I'm not working on this right now, but I can put it on my queue if you
like. You'll probably be able to fix and test it sooner than I will,
though.
+}
+EXPORT_SYMBOL(drm_gem_prime_export);
--
Aaron
[PATCH 1/1] gpu:drm:tilcdc: get preferred_bpp value from DT
The preferred_bpp value in currently hard-coded to 16.
This causes color corruption on the am335x-evm lcd panel which
requires 32 bpp instead. This changes attempts to use the configured
bpp value from the DT or built-in panel-info struct.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c| 12 +++-
drivers/gpu/drm/tilcdc/tilcdc_drv.h|1 +
drivers/gpu/drm/tilcdc/tilcdc_panel.c |2 ++
drivers/gpu/drm/tilcdc/tilcdc_slave.c |2 ++
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |2 ++
5 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 2b5461b..f2a6528 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -157,7 +157,9 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
struct platform_device *pdev = dev->platformdev;
struct device_node *node = pdev->dev.of_node;
struct tilcdc_drm_private *priv;
+ struct tilcdc_module *mod;
struct resource *res;
+ u32 bpp = 0;
int ret;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
@@ -256,7 +258,15 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
platform_set_drvdata(pdev, dev);
- priv->fbdev = drm_fbdev_cma_init(dev, 16,
+
+ list_for_each_entry(mod, &module_list, list) {
+ DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
+ bpp = mod->preferred_bpp;
+ if (bpp > 0)
+ break;
+ }
+
+ priv->fbdev = drm_fbdev_cma_init(dev, bpp,
dev->mode_config.num_crtc,
dev->mode_config.num_connector);
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 8242b5a..0906843 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -89,6 +89,7 @@ struct tilcdc_module {
const char *name;
struct list_head list;
const struct tilcdc_module_ops *funcs;
+ unsigned int preferred_bpp;
};
void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 0917665..86c6732 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -393,6 +393,8 @@ static int panel_probe(struct platform_device *pdev)
goto fail;
}
+ mod->preferred_bpp = panel_mod->info->bpp;
+
panel_mod->backlight = of_find_backlight_by_node(node);
if (panel_mod->backlight)
dev_info(&pdev->dev, "found backlight\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
index db1d2fc..8bf4fd1 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
@@ -323,6 +323,8 @@ static int slave_probe(struct platform_device *pdev)
goto fail;
}
+ mod->preferred_bpp = slave_info.bpp;
+
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(&pdev->dev, "could not get i2c bus node\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index a36788f..925c7cd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -354,6 +354,8 @@ static int tfp410_probe(struct platform_device *pdev)
goto fail;
}
+ mod->preferred_bpp = dvi_info.bpp;
+
i2c_node = of_find_node_by_phandle(i2c_phandle);
if (!i2c_node) {
dev_err(&pdev->dev, "could not get i2c bus node\n");
--
1.7.9.5
[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Hi, On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote: > Thanks all, > > On Fri, Jun 14, 2013 at 11:39 AM, ??? wrote: >> Hello Kishon, >> >> On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote: >>> Hi, >>> >>> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote: > -Original Message- > From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com] > Sent: Thursday, June 13, 2013 5:56 PM > To: Rahul Sharma > Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org; > devicetree- > discuss at lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim; > Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren; > grant.likely at linaro.org > Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with > pmu reg control > > Hi, > > On 06/13/2013 06:26 AM, Rahul Sharma wrote: >> Mr. Dae, >> >> Thanks for your valuable inputs. >> >> I posted it as RFC because, I also have received comments to register >> hdmiphy as a clock controller. As we always configure it for specific >> frequency, hdmi-phy looks similar to a PLL. But it really doesn't >> belong to that class. Secondly prior to exynos5420, it was a i2c >> device. I am not sure we can register a I2C device as a clock >> controller. I wanted to discuss and explore this option here. > > Have you considered using the generic PHY framework for those HDMI > PHY devices [1] ? I guess we could add a dedicated group of ops for > video PHYs, similarly as is is done with struct v4l2_subdev_ops. For > configuring things like the carrier/pixel clock frequency or anything > what's common across the video PHYs. > > Perhaps you could have a look and see if this framework would be > useful for HDMI and possibly point out anything what might be missing ? > > I'm not sure it it really solves the issues specific to the Exynos > HDMI but at least with a generic PHY driver the PHY module would be > separate from the PHY controller, as often same HDMI DPHY can be used > with various types of a HDMI controller. So this would allow to not > duplicate the HDMI PHY drivers in the long-term perspective. Yeah, at least, it seems that we could use PHY module to control PMU register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off callbacks. As you may know, HDMIPHY needs i2c interfaces to control HDMIPHY clock. So with PHY module, HDMIPHY driver could enable PMU more generically, but also has to use existing i2c stuff to control HDMIPHY clock. I had a quick review to Generic PHY Framework[v6] but I didn't see that the PHY module could generically support more features such as i2c stuff. >>> >>> I don't think PHY framework needs to provide i2c interfaces to program >>> certain configurations. Instead in one of the callbacks (init/on/off) >>> PHY driver can program whatever it wants using any of the interfaces it >>> needs. IMO PHY framework should work independent of the interfaces. >> >> In exnoys hdmi case, i2c interface is not the exact issue. In exynos >> hdmi, hdmiphy should send i2c configuration about video clock >> information as the video mode information including resolution, bit per >> pixel, refresh rate passed from drm subsystem. So init/on/off callbacks >> of phy framework are not enough for exynos hdmiphy and it should have a >> callback to set video mode. >> >> Do you have plan to add driver specific extend callback pointers to phy >> framework? >> >> Currently, hdmi directly calls phy operations, but Rahul's another patch >> set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is >> connected with exynos hdmi own sub driver callback operations. >> >> IMHO, if phy framework can support extend callback feature, then this >> own sub driver callbacks can be replaced with phy framework at long term >> view. > > Extended callbacks are always welcome. I can also use phy device > private data to pass on private ops like get_pixelclk and set_pixelclk. I would recommend creating a wrapper to the existing PHY framework for HDMI PHY. That way, we can have other HDMI phys added easily. We need to figure out all the ops that might be needed by the HDMI PHY to be added to the wrapper. IMO extended callbacks can lead to abuse of the system and should be used only when absolutely necessary. Thanks Kishon
[PATCH 10/10] idr: Rework idr_preload()
The old idr_preload() used percpu buffers - since the
bitmap/radix/whatever tree only grew by fixed sized nodes, it only had
to ensure there was a node available in the percpu buffer and disable
preemption. This conveniently meant that you didn't have to pass the idr
you were going to allocate from to it.
With the new ida implementation, that doesn't work anymore - the new ida
code grows its bitmap tree by reallocating the entire thing in power of
two increments. Doh.
So we need a slightly different trick. Note that if all allocations from
an idr start by calling idr_prealloc() and disabling premption, at
most nr_cpus() allocations can happen before someone calls
idr_prealloc() again.
So, we just change idr_prealloc() to resize the ida bitmap tree if
there's less than num_possible_cpus() ids available - conveniently, we
already track the number of allocated ids, and the total number of ids
we can have allocated is just nr_leaf_nodes * BITS_PER_LONG. Easy.
This does require a fairly trivial interface change - we now have to
pass the idr we're going to allocate from (and the starting id we're
going to pass to idr_allocate_range()) to idr_prealloc(), so this patch
updates all the callers.
Signed-off-by: Kent Overstreet
Cc: Andrew Morton
Cc: Tejun Heo
Cc: Stefan Richter
Cc: David Airlie
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Steve Wise
Cc: Hoang-Nam Nguyen
Cc: Christoph Raisch
Cc: Mike Marciniszyn
Cc: Doug Gilbert
Cc: "James E.J. Bottomley"
Cc: Christine Caulfield
Cc: David Teigland
Cc: Trond Myklebust
Cc: John McCutchan
Cc: Robert Love
Cc: Eric Paris
Cc: Dave Airlie
Cc: Thomas Hellstrom
Cc: Brian Paul
Cc: Maarten Lankhorst
Cc: Dmitry Torokhov
Cc: Erez Shitrit
Cc: Al Viro
Cc: Haggai Eran
Cc: Jack Morgenstein
Cc: Wolfram Sang
Cc: Greg Kroah-Hartman
Cc: Davidlohr Bueso
Cc: Rik van Riel
Cc: Michel Lespinasse
Cc: linux1394-devel at lists.sourceforge.net
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-rdma at vger.kernel.org
Cc: linux-scsi at vger.kernel.org
Cc: cluster-devel at redhat.com
Cc: linux-nfs at vger.kernel.org
---
drivers/firewire/core-cdev.c | 2 +-
drivers/gpu/drm/drm_gem.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +-
drivers/infiniband/core/cm.c | 7 +---
drivers/infiniband/core/sa_query.c | 2 +-
drivers/infiniband/core/uverbs_cmd.c | 2 +-
drivers/infiniband/hw/cxgb3/iwch.h | 2 +-
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 2 +-
drivers/infiniband/hw/ehca/ehca_cq.c | 2 +-
drivers/infiniband/hw/ehca/ehca_qp.c | 2 +-
drivers/infiniband/hw/ipath/ipath_driver.c | 2 +-
drivers/infiniband/hw/mlx4/cm.c| 2 +-
drivers/infiniband/hw/qib/qib_init.c | 2 +-
drivers/scsi/sg.c | 2 +-
fs/dlm/lock.c | 2 +-
fs/dlm/recover.c | 2 +-
fs/nfs/nfs4client.c| 2 +-
fs/notify/inotify/inotify_user.c | 2 +-
include/linux/idr.h| 37 +
ipc/util.c | 4 +-
lib/idr.c | 66 ++
21 files changed, 91 insertions(+), 59 deletions(-)
diff --git a/drivers/firewire/core-cdev.c b/drivers/firewire/core-cdev.c
index 436debf..3c70fbc 100644
--- a/drivers/firewire/core-cdev.c
+++ b/drivers/firewire/core-cdev.c
@@ -490,7 +490,7 @@ static int add_client_resource(struct client *client,
int ret;
if (preload)
- idr_preload(gfp_mask);
+ idr_preload(&client->resource_idr, 0, gfp_mask);
spin_lock_irqsave(&client->lock, flags);
if (client->in_shutdown)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1c897b9..cf50894 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,7 +273,7 @@ drm_gem_handle_create(struct drm_file *file_priv,
* Get the user-visible handle using idr. Preload and perform
* allocation under our spinlock.
*/
- idr_preload(GFP_KERNEL);
+ idr_preload(&file_priv->object_idr, 1, GFP_KERNEL);
spin_lock(&file_priv->table_lock);
ret = idr_alloc_range(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
@@ -449,7 +449,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
if (obj == NULL)
return -ENOENT;
- idr_preload(GFP_KERNEL);
+ idr_preload(&dev->object_name_idr, 1, GFP_KERNEL);
spin_lock(&dev->object_name_lock);
if (!obj->name) {
ret = idr_alloc_range(&dev->object_name_idr, obj, 1, 0,
GFP_NOWAIT);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index ccbaed1..9f00706 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -177,7 +177,
[PATCH 09/10] idr: Remove unneeded idr locking, idr_preload() usage
Our new idr implementation does its own locking, instead of forcing it
onto the callers like the old implementation.
Many of the existing idr users need locking for more than just
idr_alloc()/idr_remove()/idr_find() - they're taking refcounts and such
under their locks and we can't touch those.
But a significant number of users had locks that protected nothing more
than the idr data structures itself - those we can get rid of.
Note that we have to be careful when removing locks; in some places,
locks appear to only be protecting idr_alloc()/idr_remove() calls but
they're also used by other code that needs to ensure the idr isn't
modified while it's doing something else - so ideally we want to delete
the lock that protected the idr, or else we have to carefully audit all
the other places it's used.
There's also a fair number of places where things were being done under
the idr lock unnecessarily; drivers/dca/dca-sysfs.c is a good example.
dca->id is set to the id idr_alloc() returns under the lock - but
there's no idr_find() calls under the lock, and dca->id isn't touched in
the idr_remove() paths. So the lock can be safely deleted.
The really nice thing about deleting this unnecessary locking is that it
lets us trivially delete a lot of now unnecessary idr_preload() - with
idr doing its own locking, we can pass GFP_KERNEL to idr_alloc() just
fine.
Signed-off-by: Kent Overstreet
Cc: Andrew Morton
Cc: Tejun Heo
Cc: David Airlie
Cc: Tom Tucker
Cc: Steve Wise
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Alasdair Kergon
Cc: dm-devel at redhat.com
Cc: Samuel Ortiz
Cc: Alex Dubov
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Chris Ball
Cc: "James E.J. Bottomley"
Cc: Willem Riede
Cc: "Kai M?kisara"
Cc: "Nicholas A. Bellinger"
Cc: Li Zefan
Cc: Vlad Yasevich
Cc: Neil Horman
Cc: "David S. Miller"
Cc: Dave Airlie
Cc: Alon Levy
Cc: Guennadi Liakhovetski
Cc: Christoph Hellwig
Cc: linux-kernel at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linux-rdma at vger.kernel.org
Cc: linux-mmc at vger.kernel.org
Cc: linux-scsi at vger.kernel.org
Cc: osst-users at lists.sourceforge.net
Cc: target-devel at vger.kernel.org
Cc: containers at lists.linux-foundation.org
Cc: cgroups at vger.kernel.org
Cc: linux-sctp at vger.kernel.org
Cc: netdev at vger.kernel.org
---
drivers/dca/dca-sysfs.c | 18 +++---
drivers/gpu/drm/qxl/qxl_cmd.c | 4 +---
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_kms.c | 1 -
drivers/gpu/drm/qxl/qxl_release.c | 19 +--
drivers/infiniband/hw/amso1100/c2.h | 1 -
drivers/infiniband/hw/amso1100/c2_qp.c| 20 ++--
drivers/md/dm.c | 22 --
drivers/memstick/core/memstick.c | 17 +++--
drivers/mfd/rtsx_pcr.c| 13 +++--
drivers/misc/c2port/core.c| 11 +--
drivers/misc/tifm_core.c | 15 +++
drivers/mmc/core/host.c | 13 ++---
drivers/scsi/ch.c | 14 ++
drivers/scsi/st.c | 13 +
drivers/target/iscsi/iscsi_target.c | 17 -
drivers/target/iscsi/iscsi_target.h | 1 -
drivers/target/iscsi/iscsi_target_login.c | 12 ++--
include/linux/cgroup.h| 1 -
include/net/sctp/sctp.h | 1 -
kernel/cgroup.c | 9 +
kernel/workqueue.c| 15 ++-
net/9p/util.c | 15 +--
net/sctp/associola.c | 14 ++
net/sctp/protocol.c | 1 -
net/sctp/socket.c | 2 --
26 files changed, 42 insertions(+), 228 deletions(-)
diff --git a/drivers/dca/dca-sysfs.c b/drivers/dca/dca-sysfs.c
index effda66..6be5fbd 100644
--- a/drivers/dca/dca-sysfs.c
+++ b/drivers/dca/dca-sysfs.c
@@ -31,7 +31,6 @@
static struct class *dca_class;
static struct idr dca_idr;
-static spinlock_t dca_idr_lock;
int dca_sysfs_add_req(struct dca_provider *dca, struct device *dev, int slot)
{
@@ -55,23 +54,15 @@ int dca_sysfs_add_provider(struct dca_provider *dca, struct
device *dev)
struct device *cd;
int ret;
- idr_preload(GFP_KERNEL);
- spin_lock(&dca_idr_lock);
-
- ret = idr_alloc(&dca_idr, dca, GFP_NOWAIT);
- if (ret >= 0)
- dca->id = ret;
-
- spin_unlock(&dca_idr_lock);
- idr_preload_end();
+ ret = idr_alloc(&dca_idr, dca, GFP_KERNEL);
if (ret < 0)
return ret;
+ dca->id = ret;
+
cd = device_create(dca_class, dev, MKDEV(0, 0), NULL, "dca%d", dca->id);
if (IS_ERR(cd)) {
- spin_lock(&dca_idr_lock);
idr_remove(&dca_idr, dca->id);
-
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #3 from Tom Stellard --- These patches should fix the issue: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130617/178156.html The first patch is unrelated to the bug, but it is required in order to prevent the test case in the second patch from crashing on Cayman. I've tested this on llc, can you verify it works on real hardware. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/9c67558e/attachment.html>
[PATCH v3 1/3] drm: add prime helpers
On 06/18/2013 04:08 PM, Laurent Pinchart wrote:
> Hi Aaron,
>
> A bit late, but here's a small question.
>
> On Tuesday 15 January 2013 12:47:42 Aaron Plattner wrote:
>> Instead of reimplementing all of the dma_buf functionality in every driver,
>> create helpers drm_prime_import and drm_prime_export that implement them in
>> terms of new, lower-level hook functions:
>>
>>gem_prime_pin: callback when a buffer is created, used to pin buffers into
>> GTT gem_prime_get_sg_table: convert a drm_gem_object to an sg_table for
>> export gem_prime_import_sg_table: convert an sg_table into a drm_gem_object
>> gem_prime_vmap, gem_prime_vunmap: map and unmap an object
>>
>> These hooks are optional; drivers can opt in by using drm_gem_prime_import
>> and drm_gem_prime_export as the .gem_prime_import and .gem_prime_export
>> fields of struct drm_driver.
>>
>> v2:
>> - Drop .begin_cpu_access. None of the drivers this code replaces
>> implemented it. Having it here was a leftover from when I was trying to
>> include i915 in this rework.
>> - Use mutex_lock instead of mutex_lock_interruptible, as these three drivers
>> did. This patch series shouldn't change that behavior.
>> - Rename helpers to gem_prime_get_sg_table and gem_prime_import_sg_table.
>>Rename struct sg_table* variables to 'sgt' for clarity.
>> - Update drm.tmpl for these new hooks.
>>
>> v3:
>> - Pass the vaddr down to the driver. This lets drivers that just call
>> vunmap on the pointer avoid having to store the pointer in their GEM
>> private structures. - Move documentation into a /** DOC */ comment in
>> drm_prime.c and include it in drm.tmpl with a !P line. I tried to use !F
>> lines to include documentation of the individual functions from drmP.h, but
>> the docproc / kernel-doc scripts barf on that file, so hopefully this is
>> good enough for now.
>> - apply refcount fix from commit be8a42ae60addd8b6092535c11b42d099d6470ec
>>("drm/prime: drop reference on imported dma-buf come from gem")
>>
>> Signed-off-by: Aaron Plattner
>> Cc: Daniel Vetter
>> Cc: David Airlie
>> ---
>> Documentation/DocBook/drm.tmpl | 4 +
>> drivers/gpu/drm/drm_prime.c| 186 +-
>> include/drm/drmP.h | 12 +++
>> 3 files changed, 201 insertions(+), 1 deletion(-)
>
> [snip]
>
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index 7f12573..366910d 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>
> [snip]
>
>> +/**
>> + * DOC: PRIME Helpers
>> + *
>> + * Drivers can implement @gem_prime_export and @gem_prime_import in terms
>> of + * simpler APIs by using the helper functions @drm_gem_prime_export and
>> + * @drm_gem_prime_import. These functions implement dma-buf support in
>> terms of + * five lower-level driver callbacks:
>> + *
>> + * Export callbacks:
>> + *
>> + * - @gem_prime_pin (optional): prepare a GEM object for exporting
>> + *
>> + * - @gem_prime_get_sg_table: provide a scatter/gather table of pinned
>> pages + *
>> + * - @gem_prime_vmap: vmap a buffer exported by your driver
>> + *
>> + * - @gem_prime_vunmap: vunmap a buffer exported by your driver
>> + *
>> + * Import callback:
>> + *
>> + * - @gem_prime_import_sg_table (import): produce a GEM object from
>> another + *driver's scatter/gather table
>> + */
>> +
>> +struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
>> + struct drm_gem_object *obj, int flags)
>> +{
>> +if (dev->driver->gem_prime_pin) {
>> +int ret = dev->driver->gem_prime_pin(obj);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +}
>> +return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
>> + 0600);
>
> Why do you use 0600 instead of the flags passed by the caller ?
Because I copied & pasted it from i915_gem_prime_export prior to commit
5b42427fc38ecb9056c4e64deaff36d6d6ba1b67 and didn't notice until you
pointed it out just now.
>> +}
>> +EXPORT_SYMBOL(drm_gem_prime_export);
--
Aaron
[RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Thanks all, On Fri, Jun 14, 2013 at 11:39 AM, ??? wrote: > Hello Kishon, > > On 2013? 06? 13? 21:54, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Thursday 13 June 2013 04:51 PM, Inki Dae wrote: >>> >>> -Original Message- From: Sylwester Nawrocki [mailto:s.nawrocki at samsung.com] Sent: Thursday, June 13, 2013 5:56 PM To: Rahul Sharma Cc: Rahul Sharma; Inki Dae; linux-samsung-soc at vger.kernel.org; devicetree- discuss at lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim; Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren; grant.likely at linaro.org Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control Hi, On 06/13/2013 06:26 AM, Rahul Sharma wrote: > Mr. Dae, > > Thanks for your valuable inputs. > > I posted it as RFC because, I also have received comments to register > hdmiphy as a clock controller. As we always configure it for specific > frequency, hdmi-phy looks similar to a PLL. But it really doesn't > belong to that class. Secondly prior to exynos5420, it was a i2c > device. I am not sure we can register a I2C device as a clock > controller. I wanted to discuss and explore this option here. Have you considered using the generic PHY framework for those HDMI PHY devices [1] ? I guess we could add a dedicated group of ops for video PHYs, similarly as is is done with struct v4l2_subdev_ops. For configuring things like the carrier/pixel clock frequency or anything what's common across the video PHYs. Perhaps you could have a look and see if this framework would be useful for HDMI and possibly point out anything what might be missing ? I'm not sure it it really solves the issues specific to the Exynos HDMI but at least with a generic PHY driver the PHY module would be separate from the PHY controller, as often same HDMI DPHY can be used with various types of a HDMI controller. So this would allow to not duplicate the HDMI PHY drivers in the long-term perspective. >>> >>> Yeah, at least, it seems that we could use PHY module to control PMU >>> register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off >>> callbacks. As you may know, HDMIPHY needs i2c interfaces to control >>> HDMIPHY >>> clock. So with PHY module, HDMIPHY driver could enable PMU more >>> generically, >>> but also has to use existing i2c stuff to control HDMIPHY clock. I had a >>> quick review to Generic PHY Framework[v6] but I didn't see that the PHY >>> module could generically support more features such as i2c stuff. >> >> I don't think PHY framework needs to provide i2c interfaces to program >> certain configurations. Instead in one of the callbacks (init/on/off) >> PHY driver can program whatever it wants using any of the interfaces it >> needs. IMO PHY framework should work independent of the interfaces. > > In exnoys hdmi case, i2c interface is not the exact issue. In exynos > hdmi, hdmiphy should send i2c configuration about video clock > information as the video mode information including resolution, bit per > pixel, refresh rate passed from drm subsystem. So init/on/off callbacks > of phy framework are not enough for exynos hdmiphy and it should have a > callback to set video mode. > > Do you have plan to add driver specific extend callback pointers to phy > framework? > > Currently, hdmi directly calls phy operations, but Rahul's another patch > set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is > connected with exynos hdmi own sub driver callback operations. > > IMHO, if phy framework can support extend callback feature, then this > own sub driver callbacks can be replaced with phy framework at long term > view. Extended callbacks are always welcome. I can also use phy device private data to pass on private ops like get_pixelclk and set_pixelclk. Similar logic has been used to pass struct omap_usb to usb phy controller. I can add these changes for migration of hdmiphy to generic phy framwork to my hdmiphy separation patch set. regards, Rahul Sharma. > > Thanks and Regards, > - Seung-Woo Kim > >> >> For example, twl4030 phy driver actually uses i2c to program its >> registers but still it uses the PHY framework [1]. >> >> [1] --> http://www.gossamer-threads.com/lists/linux/kernel/1729414 >> >> Thanks >> Kishon >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-samsung-soc" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > Seung-Woo Kim > Samsung Software R&D Center > -- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
exynos-drm-next todo work.
Hi all, I'd like to discuss Exynos DRM TODO work. There are features we have to solve and implement. The purpose of this email is to share what we have to do so that other guys can be involved without duplicated work. 1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler device instead of VP device. And now exynos drm driver has gscaler module as a sub module of IPP framework. However, this gscaler module is very specific to IPP framework so it's not easy to reuse this module. So maybe we need so many works for it. Video play back path using post process (AS IS): MFCIPPKMS-FIMD or HDMI Ideal video play back path using post process (TO BE): MFCKMSFIMD or HDMI The above scenario is to send decoded image data (YUV format) to display device via post process. However, we don't really need to use IPP framework in case of using gscaler as VP. All we have to do is to call kms interface (setplane) for it like we did before. 2. More features for HDMI sound support - we need to implement Exynos ALSA SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit rate, and so on from user side should be sent to drm hdmi driver via ALSA interface and the ALSA SoC DAI driver. As of now, it seems like that we should implement this driver like OMAP does because there is no common framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver: in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces of DSS driver directly. I think we could implement ALSA SoC DAI driver in more generic way if we first implement common framework for it. Welcome to any volunteer and other opinions. Thanks, Inki Dae
exynos-drm-next todo work.
Hi Mr. Dae, Related to HDMI sound support in Alsa, I have posted a working RFC "exynos-hdmi to CDF complaint display driver". It registers a separate sound card by registering hdmi audio codec dai and cpu-dai, as you mentioned. But there is a problem with this approach that I2S being the single cpu dai for HDMI and Speaker sound card, only one card can support playback at a time. I would like to work on this to provide a more refined solution. regards, Rahul Sharma. On Tue, Jun 18, 2013 at 12:03 PM, Inki Dae wrote: > Hi all, > > I'd like to discuss Exynos DRM TODO work. > > There are features we have to solve and implement. The purpose of this email > is to share what we have to do so that other guys can be involved without > duplicated work. > > 1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler > device instead of VP device. And now exynos drm driver has gscaler module as > a sub module of IPP framework. However, this gscaler module is very specific > to IPP framework so it's not easy to reuse this module. So maybe we need so > many works for it. > > Video play back path using post process (AS IS): > MFCIPPKMS-FIMD or HDMI > > Ideal video play back path using post process (TO BE): > MFCKMSFIMD or HDMI > > The above scenario is to send decoded image data (YUV format) to display > device via post process. However, we don't really need to use IPP framework > in case of using gscaler as VP. All we have to do is to call kms interface > (setplane) for it like we did before. > > 2. More features for HDMI sound support - we need to implement Exynos ALSA > SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit > rate, and so on from user side should be sent to drm hdmi driver via ALSA > interface and the ALSA SoC DAI driver. As of now, it seems like that we > should implement this driver like OMAP does because there is no common > framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver: > in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces > of DSS driver directly. I think we could implement ALSA SoC DAI driver in > more generic way if we first implement common framework for it. > > Welcome to any volunteer and other opinions. > > Thanks, > Inki Dae > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message-
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 3:21 AM
> To: Inki Dae
> Cc: Maarten Lankhorst; linux-fbdev; Kyungmin Park; DRI mailing list; Rob
> Clark; myungjoo.ham; YoungJun Cho; Daniel Vetter; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
>
> On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> > It seems like that all pages of the scatterlist should be mapped with
> > DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> > function call), and the pages should be unmapped from DMA again every
> > time DMA operation is completed: internally, including each cache
> > operation.
>
> Correct.
>
> > Isn't that big overhead?
>
> Yes, if you _have_ to do a cache operation to ensure that the DMA agent
> can see the data the CPU has written.
>
> > And If there is no problem, we should accept such overhead?
>
> If there is no problem then why are we discussing this and why do we need
> this API extension? :)
Ok, another issue regardless of dmabuf-sync. Reasonable to me even though
big overhead. Besides, it seems like that most DRM drivers have same issue.
Therefore, we may need to solve this issue like below:
- do not map a dmabuf with DMA. And just create/update buffer object
of importer.
- map the buffer with DMA every time DMA start or iommu page fault
occurs.
- unmap the buffer from DMA every time DMA operation is completed
With the above approach, cache operation portion of my approach,
dmabuf-sync, can be removed. However, I'm not sure that we really have to
use the above approach with a big overhead. Of course, if we don't use the
above approach then user processes would need to do each cache operation
before DMA operation is started and also after DMA operation is completed in
some cases; user space mapped with physical memory as cachable, and CPU and
DMA share the same buffer.
So I'd like to ask for other DRM maintainers. How do you think about it? it
seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
Rob) and GEM CMA helper also have same issue Russell pointed out. I think
not only the above approach but also the performance is very important.
Thanks,
Inki Dae
>
> > Actually, drm_gem_fd_to_handle() includes to map a
> > given dmabuf with iommu table (just logical data) of the DMA. And then,
> the
> > device address (or iova) already mapped will be set to buffer register
> of
> > the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
>
> Consider this with a PIPT cache:
>
> dma_map_sg()- at this point, the kernel addresses of these
> buffers are cleaned and invalidated for the DMA
>
> userspace writes to the buffer, the data sits in the CPU cache
> Because the cache is PIPT, this data becomes visible to the
> kernel as well.
>
> DMA is started, and it writes to the buffer
>
> Now, at this point, which is the correct data? The data physically in the
> RAM which the DMA has written, or the data in the CPU cache. It may
> the answer is - they both are, and the loss of either can be a potential
> data corruption issue - there is no way to tell which data should be
> kept but the system is in an inconsistent state and _one_ of them will
> have to be discarded.
>
> dma_unmap_sg() - at this point, the kernel addresses of the
> buffers are _invalidated_ and any data in those
> cache lines is discarded
>
> Which also means that the data in userspace will also be discarded with
> PIPT caches.
>
> This is precisely why we have buffer rules associated with the DMA API,
> which are these:
>
> dma_map_sg()
> - the buffer transfers ownership from the CPU to the DMA agent.
> - the CPU may not alter the buffer in any way.
> while (cpu_wants_access) {
> dma_sync_sg_for_cpu()
> - the buffer transfers ownership from the DMA to the CPU.
> - the DMA may not alter the buffer in any way.
> dma_sync_sg_for_device()
> - the buffer transfers ownership from the CPU to the DMA
> - the CPU may not alter the buffer in any way.
> }
> dma_unmap_sg()
> - the buffer transfers ownership from the DMA to the CPU.
> - the DMA may not alter the buffer in any way.
>
> Any violation of that is likely to lead to data corruption. Now, some
> may say that the DMA API is only about the kernel mapping. Yes it is,
> because it takes no regard what so ever about what happens with the
> userspace mappings. This is absolutely true when you have VIVT or
> aliasing VIPT caches.
>
> Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
> is exactly the same behaviourally from this aspect) any modif
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #69 from Marc Dietrich --- I mean it cannot find the intrinsic at all: # ./Release/bin/llc < test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=r600 LLVM ERROR: Cannot select: 0x8a5570: f32 = fsin 0x8a5670 [ORD=2] [ID=3] 0x8a5670: f32,ch = CopyFromReg 0x871928, 0x8a5970 [ID=2] 0x8a5970: f32 = Register %T0_X [ID=1] In function: test litte different with eg. -mcpu=hainan: # ./Release/bin/llc < test/CodeGen/R600/llvm.sin.ll -march=r600 -mcpu=hainan LLVM ERROR: Cannot select: target intrinsic %llvm.AMDGPU.store.output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/64c9ab90/attachment-0001.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #70 from vincent --- Created attachment 81040 --> https://bugs.freedesktop.org/attachment.cgi?id=81040&action=edit Add a cos/sin pattern Andy, does current master work on your rv790 and Unigine ? Marc, can you try the attached patch and Unigine Heaven ? I'm not sure it'll work (the cos/sin pattern does not trunc anything, but it should at least not crash) -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Aaron Watry changed: What|Removed |Added Attachment #80972|0 |1 is obsolete|| --- Comment #6 from Aaron Watry --- Created attachment 81038 --> https://bugs.freedesktop.org/attachment.cgi?id=81038&action=edit Output from llc -debug-only=isel --march=r600 --mcpu=verde < vload-int.ll -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Aaron Watry changed: What|Removed |Added Attachment #80971|0 |1 is obsolete|| --- Comment #5 from Aaron Watry --- Created attachment 81037 --> https://bugs.freedesktop.org/attachment.cgi?id=81037&action=edit LLVM Assembly that is produced from vload-int.cl (after first patch) -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #4 from Aaron Watry --- The good news is that the store error is gone... Now I get a load error :/ LLVM ERROR: Cannot select: 0x2c92af0: i64,ch = load 0x21fe0c8, 0x2c924f0, 0x2c921f0 [ID=15] 0x2c924f0: i64 = add 0x2c91ef0, 0x2c923f0 [ID=13] 0x2c91ef0: i64,ch = CopyFromReg 0x21fe0c8, 0x2c91df0 [ID=12] 0x2c91df0: i64 = Register %vreg0 [ID=1] 0x2c923f0: i64 = Constant<44> [ID=4] 0x2c921f0: i64 = undef [ID=3] I'll attach the llvm assembly in a follow-up -- 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/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list
On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote: > ville.syrjala at linux.intel.com wrote: > > From: Ville Syrj?l? > > > > Having both modes can be beneficial for video playback cases. If you can > > match the video framerate exactly, and the audio and video clocks come > > from the same source, you should be able to avoid dropped/repeated > > frames without expensive operations such as resampling the audio to > > match video output rate. > > > > Rather than add both variants based on the CEA extension short video > > descriptors in do_cea_modes(), add only one variant there. Once all > > the EDID has been fully probed, do a loop over the entire probed mode > > list, during which we add the other variants for all modes that match > > CEA modes. This allows us to match modes that didn't come via the CEA > > short video descriptors. For example one Samsung TV here doesn't have > > the 640x480-60 mode as a SVD, but instead it's specified via a detailed > > timing descriptor. > > > > Signed-off-by: Ville Syrj?l? > > --- > > A few people requested this. Originally I was a bit opposed to it, but > > when I thought about it a bit more I figured if the audio and video > > clocks come from the same source (or happen to be close enough w/o > > significant drift), this could provide a better A/V sync w/o resampling > > tricks. > > I see this has gone in now, one thing I notice is that xorg/apps/xrandr > only prints Hz to 1dp so you can't see which mode is which for the 24p > and 30i cases. > > Maybe someone reading has commit access for xorg? Not sure if you noticed but I posted some relevant xrandr patches to xorg-devel. Unfortunately I got no response, and I've been too lazy to figure out who I need to pester. -- Ville Syrj?l? Intel OTC
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_fb.c between commit b72447cdf129 ("drm/i915:
Drop bogus fbdev sprite disable code") from the drm tree and commit
b51b32cde175 ("drm/i915: s/drm_i915_private_t/struct drm_i915_private/")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_fb.c
index 3b03c3c,244060a..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@@ -291,7 -292,9 +292,7 @@@ void intel_fb_output_poll_changed(struc
void intel_fb_restore_mode(struct drm_device *dev)
{
int ret;
- drm_i915_private_t *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_plane *plane;
if (INTEL_INFO(dev)->num_pipes == 0)
return;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/88fd9c3b/attachment-0001.pgp>
[PATCH] drm/tegra: Include linux/types.h
On Mon, Jun 17, 2013 at 11:04:59PM +0200, Paul Bolle wrote: > On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote: > > That has already been fixed in linux-next. > > This header was added in v3.10-rc1. The fix in linux-next will ship in > v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10 > release candidate(s)? It's not really a bug and it can easily be worked around by including linux/types.h explicitly. But you're right, there's still a chance of getting this in before the final release of 3.10 and I can prepare a pull request for Dave. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/767bb829/attachment.pgp>
[PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode
Checking up on this patch from a few months back that I'd like to get included.. Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2]. However ajax has not yet provided comments. Is this SOL without feedback from ajax? [1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html [2] http://lists.freedesktop.org/archives/dri-devel/2013-April/036829.html On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler wrote: > Changes in this version > * rename do_force_quirk_modes() -> do_force_quirk_mode() > * use list_for_each_entry() instead of list_for_each_entry_safe() in >do_force_quirk_mode() > * remove num_modes from do_force_quirk_mode(), just return 1 or 0 as >appropriate > * remove unused quirks argument from add_force_quirk_modes() > * fixes to allow cases of forcing multiple modes > * adjusted comments to adhere closer to style guides > > Changes in version 3 > * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline > * Adds bool to specify reduced blanking to edid_quirk_force_mode > * Removes preferred bit from all other modes > > Changes in version 2 > * none > > There is at least one monitor that doesn't report its native resolution > in its EDID block. This enhancement extends the EDID quirk logic to > make monitors like this "just work". > > The first patch in this series sets up a new quirk list where monitors' > correct width, height, refresh rate, and reduced blanking parameters are > specified. When a matching monitor is attached the full mode is > calculated with drm_cvt_mode() and added to the connector. The > DRM_MODE_TYPE_PREFERRED bit is set on the new mode and unset from all > other modes. > > The first patch also defines a new quirk bit: EDID_QUIRK_FORCE_MODE. > This bit needs to be set for the new quirk list described above to be > checked. > > The second patch adds the offending monitor to the quirk lists. > > Dylan Semler (2): > drm: Enhance EDID quirks to explicitly set a mode > drm: Add EDID force quirk for MMT Monitor2Go HD+ > > drivers/gpu/drm/drm_edid.c | 89 > ++ > 1 file changed, 89 insertions(+) > > -- > 1.7.11.7 > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/f791e077/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #68 from Alex Deucher --- Trig functions need slightly different setup on r6xx and r7xx+. See tgsi_setup_trig() in r600_shader.c: /* * r600 - trunc to -PI..PI range * r700 - normalize by dividing by 2PI * see fdo bug 27901 */ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130618/1c3bd184/attachment.html>
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Am Dienstag, den 18.06.2013, 18:04 +0900 schrieb Inki Dae: [...] > > > a display device driver. It shouldn't be used within a single driver > > as a means of passing buffers between userspace and kernel space. > > What I try to do is not really such ugly thing. What I try to do is to > notify that, when CPU tries to access a buffer , to kernel side through > dmabuf interface. So it's not really to send the buffer to kernel. > > Thanks, > Inki Dae > The most basic question about why you are trying to implement this sort of thing in the dma_buf framework still stands. Once you imported a dma_buf into your DRM driver it's a GEM object and you can and should use the native DRM ioctls to prepare/end a CPU access to this BO. Then internally to your driver you can use the dma_buf reservation/fence stuff to provide the necessary cross-device sync. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote: > On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote: > > What we need is something along the lines of: > > (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA. > > or > > (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all. > > I strongly vote for (b) (plus adding a dma_buf_map_sync interface to allow > syncing to other devices/cpu whithout dropping the dma mappings). At least > that's been the idea behind things, but currently all (x86-based) drm > drivers cut corners here massively. > > Aside: The entire reason behind hiding the dma map step in the dma-buf > attachment is to allow drivers to expose crazy iommus (e.g. the tiler unit > on omap) to other devices. So imo (a) isn't the right choice. That's why I also talk below about adding the dma_buf_map/sync callbacks below, so that a dma_buf implementation can do whatever is necessary with the sg at the point of use. However, you are correct that this should be unnecessary, as DRM should only be calling dma_buf_map_attachment() when it needs to know about the memory behind the object. The problem is that people will cache that information - it also may be expensive to setup for the dma_buf - as it involves counting the number of pages, memory allocation, and maybe obtaining the set of pages from shmem. With (a) plus the callbacks below, it means that step is only performed once, and then the DMA API part is entirely separate - we can have our cake and eat it in that regard. > > Note: the existing stuff does have the nice side effect of being able > > to pass buffers which do not have a struct page * associated with them > > through the dma_buf API - I think we can still preserve that by having > > dma_buf provide a couple of new APIs to do the SG list map/sync/unmap, > > but in any case we need to fix the existing API so that: > > > > dma_buf_map_attachment() becomes dma_buf_get_sg() > > dma_buf_unmap_attachment() becomes dma_buf_put_sg() > > > > both getting rid of the DMA direction argument, and then we have four > > new dma_buf calls: > > > > dma_buf_map_sg() > > dma_buf_unmap_sg() > > dma_buf_sync_sg_for_cpu() > > dma_buf_sync_sg_for_device() > > > > which do the actual sg map/unmap via the DMA API *at the appropriate > > time for DMA*. > > Hm, my idea was to just add a dma_buf_sync_attchment for the device side > syncing, since the cpu access stuff is already bracketed with the > begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap, > but imo mmap support for dma_buf is a bit insane anyway, so I don't care > too much about it. > > Since such dma mappings would be really longstanding in most cases anyway > drivers could just map with BIDIRECTIONAL and do all the real flushing > with the new sync stuff. Note that the DMA API debug doesn't allow you to change the direction argument on an existing mapping (neither should it, again this is documented in the DMA API stuff in Documentation/). This is where you would need the complete set of four functions I mention above which reflect the functionality of the DMA API. The dma_buf implementation doesn't _have_ to implement them if they are no-ops - for example, your dma_buf sg array contains DMA pointers, and the memory is already coherent in some way (for example, it's a separate chunk of memory which isn't part of system RAM.)
[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list
Ville Syrj?l? wrote: > On Tue, Jun 18, 2013 at 11:10:30AM +0100, Andy Furniss wrote: >> ville.syrjala at linux.intel.com wrote: >>> From: Ville Syrj?l? >>> >>> Having both modes can be beneficial for video playback cases. If you can >>> match the video framerate exactly, and the audio and video clocks come >>> from the same source, you should be able to avoid dropped/repeated >>> frames without expensive operations such as resampling the audio to >>> match video output rate. >>> >>> Rather than add both variants based on the CEA extension short video >>> descriptors in do_cea_modes(), add only one variant there. Once all >>> the EDID has been fully probed, do a loop over the entire probed mode >>> list, during which we add the other variants for all modes that match >>> CEA modes. This allows us to match modes that didn't come via the CEA >>> short video descriptors. For example one Samsung TV here doesn't have >>> the 640x480-60 mode as a SVD, but instead it's specified via a detailed >>> timing descriptor. >>> >>> Signed-off-by: Ville Syrj?l? >>> --- >>> A few people requested this. Originally I was a bit opposed to it, but >>> when I thought about it a bit more I figured if the audio and video >>> clocks come from the same source (or happen to be close enough w/o >>> significant drift), this could provide a better A/V sync w/o resampling >>> tricks. >> >> I see this has gone in now, one thing I notice is that xorg/apps/xrandr >> only prints Hz to 1dp so you can't see which mode is which for the 24p >> and 30i cases. >> >> Maybe someone reading has commit access for xorg? > > Not sure if you noticed but I posted some relevant xrandr patches to > xorg-devel. Unfortunately I got no response, and I've been too lazy > to figure out who I need to pester. > Ahh, sorry I didn't see those, I just has a look at the current code to check it was still the same.
[patch] drm/i915: remove a superflous semi-colon
On Tue, Jun 18, 2013 at 10:29:58AM +0300, Dan Carpenter wrote: > This macro doesn't need a semi-colon. > > Signed-off-by: Dan Carpenter Queued for -next, thanks for the patch. -Daniel > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index e5cc7c0..592b0eb9 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1773,7 +1773,7 @@ int __i915_add_request(struct intel_ring_buffer *ring, > struct drm_i915_gem_object *batch_obj, > u32 *seqno); > #define i915_add_request(ring, seqno) \ > - __i915_add_request(ring, NULL, NULL, seqno); > + __i915_add_request(ring, NULL, NULL, seqno) > int __must_check i915_wait_seqno(struct intel_ring_buffer *ring, > uint32_t seqno); > int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf); -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] radeon: Fix a false positive lockup after 10s of inactivity
On Thu, Jun 13, 2013 at 2:22 PM, Andy Lutomirski wrote: > On Wed, Jun 12, 2013 at 6:56 AM, Jerome Glisse wrote: >> Andy can you test (without your patch) and see if it helps with your issue : >> http://people.freedesktop.org/~glisse/0001-drm-radeon-update-lockup-tracking-when-scheduling-in.patch > > Testing now. I'll report back in a couple of days. > 3.9.4 plus this patch has been completely stable for several days now. Tested-by: Andy Lutomirski Can you send this to Linux and -stable? Thanks, Andy
[PATCH] drm/edid: Add both 60Hz and 59.94Hz CEA modes to connector's mode list
ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Having both modes can be beneficial for video playback cases. If you can > match the video framerate exactly, and the audio and video clocks come > from the same source, you should be able to avoid dropped/repeated > frames without expensive operations such as resampling the audio to > match video output rate. > > Rather than add both variants based on the CEA extension short video > descriptors in do_cea_modes(), add only one variant there. Once all > the EDID has been fully probed, do a loop over the entire probed mode > list, during which we add the other variants for all modes that match > CEA modes. This allows us to match modes that didn't come via the CEA > short video descriptors. For example one Samsung TV here doesn't have > the 640x480-60 mode as a SVD, but instead it's specified via a detailed > timing descriptor. > > Signed-off-by: Ville Syrj?l? > --- > A few people requested this. Originally I was a bit opposed to it, but > when I thought about it a bit more I figured if the audio and video > clocks come from the same source (or happen to be close enough w/o > significant drift), this could provide a better A/V sync w/o resampling > tricks. I see this has gone in now, one thing I notice is that xorg/apps/xrandr only prints Hz to 1dp so you can't see which mode is which for the 24p and 30i cases. Maybe someone reading has commit access for xorg?
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 Tom Stellard changed: What|Removed |Added Attachment #80967|0 |1 is obsolete|| Attachment #80969|0 |1 is obsolete|| --- Comment #4 from Tom Stellard --- Created attachment 81026 --> https://bugs.freedesktop.org/attachment.cgi?id=81026&action=edit Updated piglit tests Thanks for writing the piglit tests, I noticed a few bugs in them though. First, the output argument for all of the tests should be index 2 and not index 0 and second, in test #2 the buffer index should be multiplied by 8 instead of 10. I've fixed the piglit tests in the attached patch and also replaced the '_' with '-' in the filename. The updated tests pass on my Llano APU. -- 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 0/5] clk/exynos5250: add clocks for hdmi subsystem
Hi Mr. Kukjin, Kindly consider the following patches for review and integration. regards, Rahul Sharma. On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K wrote: > Hi, > Tested this series on snow board and is working fine. > > Tested-by: Arun Kumar K > > Regards > Arun > > On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma > wrote: >> Add clock changes for hdmi subsystem for exynos5250 SoC. These >> include addition of new clocks like mout_hdmi and smmu_tv, associating >> ID to clk_hdmiphy and some essential corrections. >> >> This set is based on kukjin's for-next branch at >> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. >> >> Arun Kumar K (1): >> clk/exynos5250: Fix HDMI clock number in documentation >> >> Rahul Sharma (4): >> clk/exynos5250: add mout_hdmi mux clock for hdmi >> clk/exynos5250: add sclk_hdmiphy in the list of special clocks >> clk/exynos5250: add clock for tv sysmmu >> clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem >> >> .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- >> drivers/clk/samsung/clk-exynos5250.c | 18 >> +- >> 2 files changed, 24 insertions(+), 6 deletions(-) >> >> -- >> 1.7.10.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote: > > > > -Original Message- > > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk] > > Sent: Tuesday, June 18, 2013 5:43 PM > > To: Inki Dae > > Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing > > list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter'; > > linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org > > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > > framework > > > > On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote: > > > So I'd like to ask for other DRM maintainers. How do you think about it? > > it > > > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained > > by > > > Rob) and GEM CMA helper also have same issue Russell pointed out. I > > think > > > not only the above approach but also the performance is very important. > > > > CMA uses coherent memory to back their buffers, though that might not be > > true of memory obtained from other drivers via dma_buf. Plus, there is > > no support in the CMA helper for exporting or importng these buffers. > > > > It's not so. Please see Dave's drm next. recently dmabuf support for the CMA > helper has been merged to there. The point stands: CMA is DMA coherent memory. It doesn't need and must never be dma-map-sg'd or dma-sync'd or dma-unmap'd.
[patch] drm/i915: remove a superflous semi-colon
This macro doesn't need a semi-colon. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index e5cc7c0..592b0eb9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1773,7 +1773,7 @@ int __i915_add_request(struct intel_ring_buffer *ring, struct drm_i915_gem_object *batch_obj, u32 *seqno); #define i915_add_request(ring, seqno) \ - __i915_add_request(ring, NULL, NULL, seqno); + __i915_add_request(ring, NULL, NULL, seqno) int __must_check i915_wait_seqno(struct intel_ring_buffer *ring, uint32_t seqno); int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
Re: [PATCH v4 0/2] Enhance EDID quirks to allow forcing a mode
Checking up on this patch from a few months back that I'd like to get included.. Acked by Daniel Vetter[1] and Reviewed by Jani Nikula[2]. However ajax has not yet provided comments. Is this SOL without feedback from ajax? [1] http://lists.freedesktop.org/archives/dri-devel/2013-March/036457.html [2] http://lists.freedesktop.org/archives/dri-devel/2013-April/036829.html On Mon, Mar 25, 2013 at 5:58 PM, Dylan Semler wrote: > Changes in this version > * rename do_force_quirk_modes() -> do_force_quirk_mode() > * use list_for_each_entry() instead of list_for_each_entry_safe() in >do_force_quirk_mode() > * remove num_modes from do_force_quirk_mode(), just return 1 or 0 as >appropriate > * remove unused quirks argument from add_force_quirk_modes() > * fixes to allow cases of forcing multiple modes > * adjusted comments to adhere closer to style guides > > Changes in version 3 > * Uses drm_cvt_mode() instead of drm_gtf_mode() to build modeline > * Adds bool to specify reduced blanking to edid_quirk_force_mode > * Removes preferred bit from all other modes > > Changes in version 2 > * none > > There is at least one monitor that doesn't report its native resolution > in its EDID block. This enhancement extends the EDID quirk logic to > make monitors like this "just work". > > The first patch in this series sets up a new quirk list where monitors' > correct width, height, refresh rate, and reduced blanking parameters are > specified. When a matching monitor is attached the full mode is > calculated with drm_cvt_mode() and added to the connector. The > DRM_MODE_TYPE_PREFERRED bit is set on the new mode and unset from all > other modes. > > The first patch also defines a new quirk bit: EDID_QUIRK_FORCE_MODE. > This bit needs to be set for the new quirk list described above to be > checked. > > The second patch adds the offending monitor to the quirk lists. > > Dylan Semler (2): > drm: Enhance EDID quirks to explicitly set a mode > drm: Add EDID force quirk for MMT Monitor2Go HD+ > > drivers/gpu/drm/drm_edid.c | 89 > ++ > 1 file changed, 89 insertions(+) > > -- > 1.7.11.7 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #3 from Tom Stellard --- These patches should fix the issue: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130617/178156.html The first patch is unrelated to the bug, but it is required in order to prevent the test case in the second patch from crashing on Cayman. I've tested this on llc, can you verify it works on real hardware. -- 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/nouveau: remove limit on gart
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 3a5e19a..41ddecd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -168,9 +168,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_mem *node;
>
> - if (unlikely((mem->num_pages << PAGE_SHIFT) >= 512 * 1024 * 1024))
> - return -ENOMEM;
> -
> node = kzalloc(sizeof(*node), GFP_KERNEL);
> if (!node)
> return -ENOMEM;
> @@ -406,8 +403,6 @@ nouveau_ttm_init(struct nouveau_drm *drm)
> /* GART init */
> if (drm->agp.stat != ENABLED) {
> drm->gem.gart_available = nouveau_vmmgr(drm->device)->limit;
> - if (drm->gem.gart_available > 512 * 1024 * 1024)
> - drm->gem.gart_available = 512 * 1024 * 1024;
> } else {
> drm->gem.gart_available = drm->agp.size;
> }
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote: > So I'd like to ask for other DRM maintainers. How do you think about it? it > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by > Rob) and GEM CMA helper also have same issue Russell pointed out. I think > not only the above approach but also the performance is very important. CMA uses coherent memory to back their buffers, though that might not be true of memory obtained from other drivers via dma_buf. Plus, there is no support in the CMA helper for exporting or importng these buffers. I guess Intel i915 is only used on x86, which is a coherent platform and requires no cache maintanence for DMA. OMAP DRM does not support importing non-DRM buffers buffers back into DRM. Moreover, it will suffer from the problems I described if any attempt is made to write to the buffer after it has been re-imported. Lastly, I should point out that the dma_buf stuff is really only useful when you need to export a dma buffer from one driver and import it into another driver - for example to pass data from a camera device driver to a display device driver. It shouldn't be used within a single driver as a means of passing buffers between userspace and kernel space.
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> > space as cachable)
> >
> > handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
> > ...
> > va1 = drm_gem_mmap(handle1);
> > va2 = drm_gem_mmap(handle2);
> > va3 = malloc(size);
> > ...
> >
> > while (conditions) {
> > memcpy(va1, some data, size);
>
> No!
>
> Well, the first thing to say here is that under the requirements of the
> DMA API, the above is immediately invalid, because you're writing to a
> buffer which under the terms of the DMA API is currently owned by the
> DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
> before you do that - but how is userspace supposed to know that requirement?
> Why should userspace even _have_ to know these requirements of the DMA
> API?
>
> It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
> causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
> into userspace is a bug too, as it has the potential to touch caches or
> stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
> going to make too big a deal about that, because I don't think we have
> anything that picky.
>
> However, the first point above is the most important one, and exposing
> the quirks of the DMA API to userland is certainly not a nice thing to be
> doing. This needs to be fixed - we can't go and enforce an API which is
> deeply embedded within the kernel all the way out to userland.
>
> What we need is something along the lines of:
> (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> or
> (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
I strongly vote for (b) (plus adding a dma_buf_map_sync interface to allow
syncing to other devices/cpu whithout dropping the dma mappings). At least
that's been the idea behind things, but currently all (x86-based) drm
drivers cut corners here massively.
Aside: The entire reason behind hiding the dma map step in the dma-buf
attachment is to allow drivers to expose crazy iommus (e.g. the tiler unit
on omap) to other devices. So imo (a) isn't the right choice.
>
> and for the scatterlist to be mapped for DMA at the point where the DMA
> operation is initiated, and unmapped at the point where the DMA operation
> is complete.
>
> So no, the problem is not that we need more APIs and code - we need the
> existing kernel API fixed so that we don't go exposing userspace to the
> requirements of the DMA API. Unless we do that, we're going to end
> up with a huge world of pain, where kernel architecture people need to
> audit every damned DRM userspace implementation that happens to be run
> on their platform, and that's not something arch people really can
> afford to do.
>
> Basically, I think the dma_buf stuff needs to be rewritten with the
> requirements of the DMA API in the forefront of whosever mind is doing
> the rewriting.
>
> Note: the existing stuff does have the nice side effect of being able
> to pass buffers which do not have a struct page * associated with them
> through the dma_buf API - I think we can still preserve that by having
> dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> but in any case we need to fix the existing API so that:
>
> dma_buf_map_attachment() becomes dma_buf_get_sg()
> dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>
> both getting rid of the DMA direction argument, and then we have four
> new dma_buf calls:
>
> dma_buf_map_sg()
> dma_buf_unmap_sg()
> dma_buf_sync_sg_for_cpu()
> dma_buf_sync_sg_for_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.
Hm, my idea was to just add a dma_buf_sync_attchment for the device side
syncing, since the cpu access stuff is already bracketed with the
begin/end cpu access stuff. We might need a sync_for_cpu or so for mmap,
but imo mmap support for dma_buf is a bit insane anyway, so I don't care
too much about it.
Since such dma mappings would be really longstanding in most cases anyway
drivers could just map with BIDIRECTIONAL and do all the real flushing
with the new sync stuff.
Another piece of fun will be integration with the fencing stuff Maarten is
doing. I'm not sure whether we should integrate that into the dma-buf
interface (for simple users who don't want to deal with the full
complexity at least).
>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be foll
[PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David
