Re: [RFC,libdrm 1/3] tegra: Add stream library

[Arto Merilainen]

On 12/28/2012 09:57 AM, Mark Zhang wrote:

On 12/28/2012 03:45 PM, Arto Merilainen wrote:

On 12/28/2012 08:47 AM, Mark Zhang wrote:

+
+/* Add fences */
+if (num_fences) {
+
+tegra_stream_push(stream,
+nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
+host1x_uclass_wait_syncpt_r(), num_fences));
+
+for (; num_fences; num_fences--, fence++) {
+assert(tegra_fence_is_valid(fence));


This is useless. We already add "1 + num_fences" to num_words above. So
move this "assert" before adding "1 + num_fences" to num_words makes
sense.



The assertion checks the validity of a single fence - not if there is
room in the command buffer.

The goal is to prevent having invalid fences in the command stream. If
this check were not here it would be possible to initialise a fence with
tegra_fence_clear() and put that fence into the stream.


My idea is, if one fence is invalid, then we should not count this in
"num_words". In current code, if one fence is invalid, then this fence
will not be pushed into the command stream, and the "num_words" shows a
wrong command buffer size.

So I think we should:
- validate the fences, remove the invalid fence
- update num_words
- then you don't need to check fence here - I mean, before push a host1x
syncpt wait command into the active buffer of stream.



In my opinion asking tegra_stream_begin() to put a bad fence into the 
stream is a case we should never be. assert() kills the application 
immediately (in debug builds) and usually this helps the programmer for 
1) finding bugs 2) not doing bad code.


"Silencing" is not a good solution especially in this case: 
tegra_stream_flush() returns an invalid fence when flushing fails. If 
the application chains submits (i.e. do a blit and then do another using 
the output of the first blit) it is crucial to be sure the first submit 
has been performed before starting the second one.


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

Re: [RFC,libdrm 1/3] tegra: Add stream library

[Mark Zhang]

On 12/28/2012 04:50 PM, Arto Merilainen wrote:
> On 12/28/2012 09:57 AM, Mark Zhang wrote:
>> On 12/28/2012 03:45 PM, Arto Merilainen wrote:
>>> On 12/28/2012 08:47 AM, Mark Zhang wrote:
> +
> +/* Add fences */
> +if (num_fences) {
> +
> +tegra_stream_push(stream,
> +nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
> +host1x_uclass_wait_syncpt_r(), num_fences));
> +
> +for (; num_fences; num_fences--, fence++) {
> +assert(tegra_fence_is_valid(fence));

 This is useless. We already add "1 + num_fences" to num_words above. So
 move this "assert" before adding "1 + num_fences" to num_words makes
 sense.

>>>
>>> The assertion checks the validity of a single fence - not if there is
>>> room in the command buffer.
>>>
>>> The goal is to prevent having invalid fences in the command stream. If
>>> this check were not here it would be possible to initialise a fence with
>>> tegra_fence_clear() and put that fence into the stream.
>>
>> My idea is, if one fence is invalid, then we should not count this in
>> "num_words". In current code, if one fence is invalid, then this fence
>> will not be pushed into the command stream, and the "num_words" shows a
>> wrong command buffer size.
>>
>> So I think we should:
>> - validate the fences, remove the invalid fence
>> - update num_words
>> - then you don't need to check fence here - I mean, before push a host1x
>> syncpt wait command into the active buffer of stream.
>>
> 
> In my opinion asking tegra_stream_begin() to put a bad fence into the
> stream is a case we should never be. assert() kills the application
> immediately (in debug builds) and usually this helps the programmer for
> 1) finding bugs 2) not doing bad code.
> 

Yep, I agree. But in release builds, assert does nothing. So this
checking doesn't make sense and also a wrong fence will be pushed into
command buffer silently. And we always use release version in real
products, so we can't count on this "assert".

> "Silencing" is not a good solution especially in this case:
> tegra_stream_flush() returns an invalid fence when flushing fails. If
> the application chains submits (i.e. do a blit and then do another using
> the output of the first blit) it is crucial to be sure the first submit
> has been performed before starting the second one.
>

Yes. So I suggest doing fence checking at the beginning of the
"tegra_stream_begin", if invalid fence found, return an error.


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

Re: [PATCHv4 0/8] Support for Tegra 2D hardware

[Mark Zhang]

Hi Terje,

Here is the second part comments. I admit I still haven't finished
reading the codes... really too many codes. :)
Anyway I'll keep doing this when I have free slots.

diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index a936902..c3ded60 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
*context,
if (err)
goto fail;

+   /* We define CMA as an temporary solution in host1x driver.
+  That's also why we have a CMA kernel config in it.
+  But seems here, in tegradrm, we hardcode the CMA here.
+  So what do you do when host1x change to IOMMU?
+  Do we also need to define a CMA config in tegradrm
driver,
+  then after host1x changes to IOMMU, we add another IOMMU
+  config in tegradrm? Or we should invent another more
+  generic wrapper layer here? */
cmdbuf.mem = handle_cma_to_host1x(drm, file_priv,
cmdbuf.mem);
if (!cmdbuf.mem)
goto fail;
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc8ca2f..0867b72 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -82,6 +82,26 @@ struct host1x_job *host1x_job_alloc(struct
host1x_channel *ch,
mem += num_unpins * sizeof(dma_addr_t);
job->pin_ids = num_unpins ? mem : NULL;

+   /* I think this is a somewhat ugly design.
+  Actually "addr_phys" is consisted by "reloc_addr_phys" and
+  "gather_addr_phys".
+  Why don't we just declare "reloc_addr_phys" and
"gather_addr_phys"?
+  In current design, let's say if one nvhost newbie changes the
order
+  of these 2 blocks of code in function "pin_job_mem":
+
+  for (i = 0; i < job->num_relocs; i++) {
+   struct host1x_reloc *reloc = &job->relocarray[i];
+   job->pin_ids[count] = reloc->target;
+   count++;
+  }
+
+  for (i = 0; i < job->num_gathers; i++) {
+   struct host1x_job_gather *g = &job->gathers[i];
+   job->pin_ids[count] = g->mem_id;
+   count++;
+  }
+
+  Then likely something weird occurs... */
job->reloc_addr_phys = job->addr_phys;
job->gather_addr_phys = &job->addr_phys[num_relocs];

@@ -252,6 +272,10 @@ static int do_relocs(struct host1x_job *job,
}
}

+   /* I have question here. Does this mean the address info
+  which need to be relocated(according to the libdrm codes,
+  seems this address is "0xDEADBEEF") always staying at the
+  beginning of a page? */
__raw_writel(
(job->reloc_addr_phys[i] +
reloc->target_offset) >> reloc->shift,
@@ -565,6 +589,7 @@ int host1x_job_pin(struct host1x_job *job, struct
platform_device *pdev)
}
}

+   /* if (host1x_firewall && !err) { */
if (host1x_firewall) {
err = copy_gathers(job, pdev);
if (err) {
@@ -573,6 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct
platform_device *pdev)
}
}

+/* Rename this label to "out" or something else.
+   Because if everything goes right, the codes under this label also
+   get executed. */
 fail:
wmb();

diff --git a/drivers/gpu/host1x/memmgr.c b/drivers/gpu/host1x/memmgr.c
index f3954f7..bb5763d 100644
--- a/drivers/gpu/host1x/memmgr.c
+++ b/drivers/gpu/host1x/memmgr.c
@@ -156,6 +156,9 @@ int host1x_memmgr_pin_array_ids(struct
platform_device *dev,
count, &unpin_data[pin_count],
phys_addr);

+   /* I don't think the current "host1x_cma_pin_array_ids"
+  is able to return a negative value. So this "if" doesn't
+  make sense...*/
if (cma_count < 0) {
/* clean up previous handles */
while (pin_count) {

Mark
On 12/21/2012 07:39 PM, Terje Bergstrom wrote:
> This set of patches adds support for Tegra20 and Tegra30 host1x and
> 2D. It is based on linux-next-20121220.
> 
> The fourth version has only few changes compared to previous version:
>  * Fixed some sparse warnings
>  * Fixed host1x Makefile to allow building as module
>  * Fixed host1x module unload
>  * Fixed tegradrm unload sequence
>  * host1x creates DRM dummy device and tegradrm uses it for storing
>DRM related data.
> 
> Some of the issues left open:
>  * Register definitions still use static inline. There has been a
>debate about code style versus ability to use compiler type
>checking and code coverage analysis. There was no conclusion, so
>I left it as was.
>  * Uses

Re: [RFC,libdrm 1/3] tegra: Add stream library

[Arto Merilainen]

On 12/28/2012 11:04 AM, Mark Zhang wrote:

On 12/28/2012 04:50 PM, Arto Merilainen wrote:


In my opinion asking tegra_stream_begin() to put a bad fence into the
stream is a case we should never be. assert() kills the application
immediately (in debug builds) and usually this helps the programmer for
1) finding bugs 2) not doing bad code.



Yep, I agree. But in release builds, assert does nothing. So this
checking doesn't make sense and also a wrong fence will be pushed into
command buffer silently. And we always use release version in real
products, so we can't count on this "assert".


The only pro of using assert is low (=no :-) ) overhead in release builds.




"Silencing" is not a good solution especially in this case:
tegra_stream_flush() returns an invalid fence when flushing fails. If
the application chains submits (i.e. do a blit and then do another using
the output of the first blit) it is crucial to be sure the first submit
has been performed before starting the second one.



Yes. So I suggest doing fence checking at the beginning of the
"tegra_stream_begin", if invalid fence found, return an error.



This sounds reasonable.

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

[PATCH] drm/exynos: Add device tree based discovery support for Exynos G2D

[Ajay Kumar]

This patch adds device tree match table for Exynos G2D controller.

Signed-off-by: Ajay Kumar 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 6ffa076..aa3d2e4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1240,6 +1241,14 @@ static int g2d_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(g2d_pm_ops, g2d_suspend, g2d_resume);
 
+#ifdef CONFIG_OF
+static const struct of_device_id exynos_g2d_match[] = {
+   { .compatible = "samsung,exynos-g2d-41" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, exynos_g2d_match);
+#endif
+
 struct platform_driver g2d_driver = {
.probe  = g2d_probe,
.remove = __devexit_p(g2d_remove),
@@ -1247,5 +1256,6 @@ struct platform_driver g2d_driver = {
.name   = "s5p-g2d",
.owner  = THIS_MODULE,
.pm = &g2d_pm_ops,
+   .of_match_table = of_match_ptr(exynos_g2d_match),
},
 };
-- 
1.8.0

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

Re: [PATCH 04/10] drm/exynos: Use devm_clk_get in exynos_drm_fimc.c

[Sachin Kamat]

On 27 December 2012 15:43, Inki Dae  wrote:
>
>
> 2012/12/26 Sachin Kamat 
>>
>>
>>
>> On Wednesday, 26 December 2012, Inki Dae  wrote:
>> >
>> >
>> > 2012/12/24 Sachin Kamat 
>> >>
>> >> This eliminates the need for explicit clk_put and makes the
>> >> cleanup and exit path code simpler.
>> >>
>> >> Cc: Eunchul Kim 
>> >> Signed-off-by: Sachin Kamat 
>> >> ---
>> >>  drivers/gpu/drm/exynos/exynos_drm_fimc.c |   46
>> >> ++---
>> >>  1 files changed, 10 insertions(+), 36 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> >> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> >> index 972aa70..c4006b8 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>> >> @@ -1739,64 +1739,50 @@ static int __devinit fimc_probe(struct
>> >> platform_device *pdev)
>> >> platform_get_device_id(pdev)->driver_data;
>> >>
>> >> /* clock control */
>> >> -   ctx->sclk_fimc_clk = clk_get(dev, "sclk_fimc");
>> >> +   ctx->sclk_fimc_clk = devm_clk_get(dev, "sclk_fimc");
>> >> if (IS_ERR(ctx->sclk_fimc_clk)) {
>> >> dev_err(dev, "failed to get src fimc clock.\n");
>> >> return PTR_ERR(ctx->sclk_fimc_clk);
>> >> }
>> >> clk_enable(ctx->sclk_fimc_clk);
>> >>
>> >> -   ctx->fimc_clk = clk_get(dev, "fimc");
>> >> +   ctx->fimc_clk = devm_clk_get(dev, "fimc");
>> >> if (IS_ERR(ctx->fimc_clk)) {
>> >> dev_err(dev, "failed to get fimc clock.\n");
>> >> clk_disable(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->sclk_fimc_clk);
>> >> return PTR_ERR(ctx->fimc_clk);
>> >> }
>> >>
>> >> -   ctx->wb_clk = clk_get(dev, "pxl_async0");
>> >> +   ctx->wb_clk = devm_clk_get(dev, "pxl_async0");
>> >> if (IS_ERR(ctx->wb_clk)) {
>> >> dev_err(dev, "failed to get writeback a clock.\n");
>> >> clk_disable(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->fimc_clk);
>> >> return PTR_ERR(ctx->wb_clk);
>> >> }
>> >>
>> >> -   ctx->wb_b_clk = clk_get(dev, "pxl_async1");
>> >> +   ctx->wb_b_clk = devm_clk_get(dev, "pxl_async1");
>> >> if (IS_ERR(ctx->wb_b_clk)) {
>> >> dev_err(dev, "failed to get writeback b clock.\n");
>> >> clk_disable(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->fimc_clk);
>> >> -   clk_put(ctx->wb_clk);
>> >> return PTR_ERR(ctx->wb_b_clk);
>> >> }
>> >>
>> >> -   parent_clk = clk_get(dev, ddata->parent_clk);
>> >> +   parent_clk = devm_clk_get(dev, ddata->parent_clk);
>> >>
>> >> if (IS_ERR(parent_clk)) {
>> >> dev_err(dev, "failed to get parent clock.\n");
>> >> clk_disable(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->fimc_clk);
>> >> -   clk_put(ctx->wb_clk);
>> >> -   clk_put(ctx->wb_b_clk);
>> >> return PTR_ERR(parent_clk);
>> >> }
>> >>
>> >> if (clk_set_parent(ctx->sclk_fimc_clk, parent_clk)) {
>> >> dev_err(dev, "failed to set parent.\n");
>> >> -   clk_put(parent_clk);
>> >> +   devm_clk_put(dev, parent_clk);
>> >
>> > remove the above call. is there any reason that devm_clk_put should be
>> > called here?
>>
>> Devm resources are freed/released automatically only when the device
>> detaches. In the above case the clock was released explicitly (for whatever
>> reasons) earlier. Hence i have used devm call to keep the code logic same as
>> i do not know the behavior if this clock is 'put' when the device detaches
>> instead of here.
>>
>
> If probe is failed, devm resources are released by devres_release_all(). So
> that is unnecessary call. Remove it.

In this case you are right. It is not required. I will remove it.
But in the below case it is not part of cleanup, so I will keep it.
What is your opinion about it?

>
>>
>>
>> >
>> >>
>> >> clk_disable(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->sclk_fimc_clk);
>> >> -   clk_put(ctx->fimc_clk);
>> >> -   clk_put(ctx->wb_clk);
>> >> -   clk_put(ctx->wb_b_clk);
>> >> return -EINVAL;
>> >> }
>> >>
>> >> -   clk_put(parent_clk);
>> >> +   devm_clk_put(dev, parent_clk);
>> >
>> > ditto.
>> >
>> >>
>> >> clk_set_rate(ctx->sclk_fimc_clk, pdata->clk_rate);
>> >>
>> >> /* resource memory */
>> >> @@ -1804,16 +1790,14 @@ static int __devinit fimc_probe(struct
>> >> platform_device *pdev)
>> >> ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
>> >> if (!ctx->regs) {
>> >> dev_err(dev, "failed to m

[PATCH 0/4] drm/exynos: add support for extra resolutions to exynos5

[Rahul Sharma]

This patch set adds support for more resolutions and refresh rates to Samsung
Exynos5 SoC series which contains hdmi transmitter (hdmi v1.4a compliant).

Given resolution will be supported or not, is decided by two factors:
1) Corresponding pixel clock is supported by hdmi PHY.
2) Mixer supports the display mode.

This patch series is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

Rahul Sharma (3):
  drm/exynos: add display-mode-check operation to exynos_mixer_ops
struct
  drm/exynos: implement display-mode-check callback in mixer driver
  drm/exynos: mixer: set correct mode for range of resolutions

Sean Paul (1):
  drm/exynos: hdmi: support extra resolutions using drm_display_mode
timings

 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   12 +
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |3 +
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1022 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c|   38 +-
 4 files changed, 423 insertions(+), 652 deletions(-)

-- 
1.8.0

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

[PATCH 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

[Rahul Sharma]

This patch adds the display mode check operation to exynos_mixer_ops
in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions
on the proposed display modes. These restriction needs to be considered
during mode negotiation, which happens immediately after edid parsing.

Both, mixer check-mode and hdmi check-timing callbacks are called one after
another and ANDed result is returned back.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 55793c4..3a8eea6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -125,9 +125,21 @@ static int drm_hdmi_get_edid(struct device *dev,
 static int drm_hdmi_check_timing(struct device *dev, void *timing)
 {
struct drm_hdmi_context *ctx = to_context(dev);
+   int ret = 0;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
+   /*
+   * Both, mixer and hdmi should be able to handle the requested mode.
+   * If any of the two fails, return mode as BAD.
+   */
+
+   if (mixer_ops && mixer_ops->check_mode)
+   ret = mixer_ops->check_mode(ctx->mixer_ctx->ctx, timing);
+
+   if (ret)
+   return ret;
+
if (hdmi_ops && hdmi_ops->check_timing)
return hdmi_ops->check_timing(ctx->hdmi_ctx->ctx, timing);
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 784a7e9..ae4b6ae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -58,6 +58,9 @@ struct exynos_mixer_ops {
void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
void (*win_commit)(void *ctx, int zpos);
void (*win_disable)(void *ctx, int zpos);
+
+   /* display */
+   int (*check_mode)(void *ctx, void *mode);
 };
 
 void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
-- 
1.8.0

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

[PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver

[Rahul Sharma]

This patch adds the implementation of check_mode callback in the mixer
driver. Based on the mixer version, correct set of restrictions will be
exposed by the mixer driver. A resolution will be acceptable only if passes
the criteria set by mixer and hdmi IPs.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 21db895..093b374 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -810,6 +810,33 @@ static void mixer_win_disable(void *ctx, int win)
mixer_ctx->win_data[win].enabled = false;
 }
 
+int mixer_check_mode(void *ctx, void *mode)
+{
+   struct mixer_context *mixer_ctx = ctx;
+   struct fb_videomode *check_mode = mode;
+   unsigned int w, h;
+
+   w = check_mode->xres;
+   h = check_mode->yres;
+
+   DRM_DEBUG_KMS("%s : xres=%d, yres=%d, refresh=%d, intl=%d\n",
+   __func__, check_mode->xres, check_mode->yres,
+   check_mode->refresh, (check_mode->vmode &
+   FB_VMODE_INTERLACED) ? true : false);
+
+   if (mixer_ctx->mxr_ver == MXR_VER_16_0_33_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))
+   return 0;
+   } else {
+   return 0;
+   }
+
+   return -EINVAL;
+}
 static void mixer_wait_for_vblank(void *ctx)
 {
struct mixer_context *mixer_ctx = ctx;
@@ -947,6 +974,9 @@ static struct exynos_mixer_ops mixer_ops = {
.win_mode_set   = mixer_win_mode_set,
.win_commit = mixer_win_commit,
.win_disable= mixer_win_disable,
+
+   /* display */
+   .check_mode = mixer_check_mode,
 };
 
 /* for pageflip event */
-- 
1.8.0

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

[PATCH 3/4] drm/exynos: mixer: set correct mode for range of resolutions

[Rahul Sharma]

With this patch, mixer driver find the correct resolution mode for
the range of resolutions, upto 1080 vertical lines. Resolution will
be categorized to NTSC SD, PAL SD or HD and the correct mode is
set to the mixer configuration register.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 093b374..8ef0e71 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -283,13 +283,13 @@ static void mixer_cfg_scan(struct mixer_context *ctx, 
unsigned int height)
MXR_CFG_SCAN_PROGRASSIVE);
 
/* choosing between porper HD and SD mode */
-   if (height == 480)
+   if (height <= 480)
val |= MXR_CFG_SCAN_NTSC | MXR_CFG_SCAN_SD;
-   else if (height == 576)
+   else if (height <= 576)
val |= MXR_CFG_SCAN_PAL | MXR_CFG_SCAN_SD;
-   else if (height == 720)
+   else if (height <= 720)
val |= MXR_CFG_SCAN_HD_720 | MXR_CFG_SCAN_HD;
-   else if (height == 1080)
+   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;
-- 
1.8.0

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

[PATCH 4/4] drm/exynos: hdmi: support extra resolutions using drm_display_mode timings

[Rahul Sharma]

From: Sean Paul 

This patch programs the core and timing generator registers using the
timing data provided in drm_display_mode and not using hard-coded
configurations.

Additional PHY configs has been added. This allows us to support more
permissible resolutions and refresh rates.

Signed-off-by: Rahul Sharma 
Signed-off-by: Sean Paul 
Signed-off-by: Shirish S 
Signed-off-by: Akshay Saraswat 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 1022 +-
 1 file changed, 374 insertions(+), 648 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2c46b6c..8cb42ad 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -88,6 +88,73 @@ struct hdmi_resources {
int regul_count;
 };
 
+struct hdmi_tg_regs {
+   u8 cmd[1];
+   u8 h_fsz[2];
+   u8 hact_st[2];
+   u8 hact_sz[2];
+   u8 v_fsz[2];
+   u8 vsync[2];
+   u8 vsync2[2];
+   u8 vact_st[2];
+   u8 vact_sz[2];
+   u8 field_chg[2];
+   u8 vact_st2[2];
+   u8 vact_st3[2];
+   u8 vact_st4[2];
+   u8 vsync_top_hdmi[2];
+   u8 vsync_bot_hdmi[2];
+   u8 field_top_hdmi[2];
+   u8 field_bot_hdmi[2];
+   u8 tg_3d[1];
+};
+
+struct hdmi_core_regs {
+   u8 h_blank[2];
+   u8 v2_blank[2];
+   u8 v1_blank[2];
+   u8 v_line[2];
+   u8 h_line[2];
+   u8 hsync_pol[1];
+   u8 vsync_pol[1];
+   u8 int_pro_mode[1];
+   u8 v_blank_f0[2];
+   u8 v_blank_f1[2];
+   u8 h_sync_start[2];
+   u8 h_sync_end[2];
+   u8 v_sync_line_bef_2[2];
+   u8 v_sync_line_bef_1[2];
+   u8 v_sync_line_aft_2[2];
+   u8 v_sync_line_aft_1[2];
+   u8 v_sync_line_aft_pxl_2[2];
+   u8 v_sync_line_aft_pxl_1[2];
+   u8 v_blank_f2[2]; /* for 3D mode */
+   u8 v_blank_f3[2]; /* for 3D mode */
+   u8 v_blank_f4[2]; /* for 3D mode */
+   u8 v_blank_f5[2]; /* for 3D mode */
+   u8 v_sync_line_aft_3[2];
+   u8 v_sync_line_aft_4[2];
+   u8 v_sync_line_aft_5[2];
+   u8 v_sync_line_aft_6[2];
+   u8 v_sync_line_aft_pxl_3[2];
+   u8 v_sync_line_aft_pxl_4[2];
+   u8 v_sync_line_aft_pxl_5[2];
+   u8 v_sync_line_aft_pxl_6[2];
+   u8 vact_space_1[2];
+   u8 vact_space_2[2];
+   u8 vact_space_3[2];
+   u8 vact_space_4[2];
+   u8 vact_space_5[2];
+   u8 vact_space_6[2];
+};
+
+struct hdmi_v14_conf {
+   int pixel_clock;
+   struct hdmi_core_regs core;
+   struct hdmi_tg_regs tg;
+   int cea_video_id;
+};
+
 struct hdmi_context {
struct device   *dev;
struct drm_device   *drm_dev;
@@ -106,6 +173,7 @@ struct hdmi_context {
 
/* current hdmiphy conf index */
int cur_conf;
+   struct hdmi_v14_confmode_conf;
 
struct hdmi_resources   res;
 
@@ -394,586 +462,132 @@ static const struct hdmi_v13_conf hdmi_v13_confs[] = {
 };
 
 /* HDMI Version 1.4 */
-static const u8 hdmiphy_conf27_027[32] = {
-   0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
-   0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
-   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xe3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf74_176[32] = {
-   0x01, 0xd1, 0x1f, 0x10, 0x40, 0x5b, 0xef, 0x08,
-   0x81, 0xa0, 0xb9, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x5a, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xa6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf74_25[32] = {
-   0x01, 0xd1, 0x1f, 0x10, 0x40, 0x40, 0xf8, 0x08,
-   0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0xa5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x00,
-};
-
-static const u8 hdmiphy_conf148_5[32] = {
-   0x01, 0xd1, 0x1f, 0x00, 0x40, 0x40, 0xf8, 0x08,
-   0x81, 0xa0, 0xba, 0xd8, 0x45, 0xa0, 0xac, 0x80,
-   0x3c, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
-   0x54, 0x4b, 0x25, 0x03, 0x00, 0x00, 0x01, 0x00,
-};
-
-struct hdmi_tg_regs {
-   u8 cmd;
-   u8 h_fsz_l;
-   u8 h_fsz_h;
-   u8 hact_st_l;
-   u8 hact_st_h;
-   u8 hact_sz_l;
-   u8 hact_sz_h;
-   u8 v_fsz_l;
-   u8 v_fsz_h;
-   u8 vsync_l;
-   u8 vsync_h;
-   u8 vsync2_l;
-   u8 vsync2_h;
-   u8 vact_st_l;
-   u8 vact_st_h;
-   u8 vact_sz_l;
-   u8 vact_sz_h;
-   u8 field_chg_l;
-   u8 field_chg_h;
-   u8 vact_st2_l;
-   u8 vact_st2_h;
-   u8 vact_st3_l;
-   u8 vact_st3_h;
-   u8 vact_st4_l;
-   u8 vact_st4_h;
-   u8 vsync_top_hdmi_l;
-   u8 vsync_top_hdmi_h;
-   u8 vsync_bot_hdmi_l;
-   u8 vsync_bot_hdmi_h;
-   u8 field_top_hdmi_l;
-   u8 field_top_hdmi_h;
-   u8 field_bot_hdmi_l;
-   u8 field_bot_hdmi_h;
-   u8 tg_3d;
-};
-
-struct hdmi_core_regs {
-   u8

Re: [RFC v2 0/5] Common Display Framework

[Vikas Sajjan]

On 27 December 2012 20:13, Tomasz Figa  wrote:
> Hi Laurent,
>
> On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
>> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
>> > > On 17 December 2012 20:55, Laurent Pinchart wrote:
>> > > > Hi Vikas,
>> > > >
>> > > > Sorry for the late reply. I now have more time to work on CDF, so
>> > > > delays should be much shorter.
>> > > >
>> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
>> > > > > Hi Laurent,
>> > > > >
>> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform,
>> > > > > what
>> > > > > I found is that, the exynos display controller is MIPI DSI based
>> > > > > controller.
>> > > > >
>> > > > > But if I look at CDF patches, it has only support for MIPI DBI
>> > > > > based
>> > > > > Display controller.
>> > > > >
>> > > > > So my question is, do we have any generic framework for MIPI DSI
>> > > > > based display controller? basically I wanted to know, how to go
>> > > > > about
>> > > > > porting CDF for such kind of display controller.
>> > > >
>> > > > MIPI DSI support is not available yet. The only reason for that is
>> > > > that I don't have any MIPI DSI hardware to write and test the code
>> > > > with :-)
>> > > >
>> > > > The common display framework should definitely support MIPI DSI. I
>> > > > think the existing MIPI DBI code could be used as a base, so the
>> > > > implementation shouldn't be too high.
>> > > >
>> > > > Yeah, i was also thinking in similar lines, below is my though for
>> > > > MIPI DSI support in CDF.
>> > >
>> > > o   MIPI DSI support as part of CDF framework will expose
>> > > §  mipi_dsi_register_device(mpi_device) (will be called
>> > > mach-xxx-dt.c
>> > > file )
>> > > §  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
>> > > from
>> > > platform specific init driver call )
>> > > ·bus ops will be
>> > > o   read data
>> > > o   write data
>> > > o   write command
>> > > §  MIPI DSI will be registered as bus_register()
>> > >
>> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI)
>> > > will
>> > > initialize the MIPI DSI HW IP.
>> > >
>> > > This probe will also parse the DT file for MIPI DSI based panel, add
>> > > the panel device (device_add() ) to kernel and register the display
>> > > entity with its control and  video ops with CDF.
>> > >
>> > > I can give this a try.
>> >
>> > I am currently in progress of reworking Exynos MIPI DSIM code and
>> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I
>> > have most of the work done, I have just to solve several remaining
>> > problems.
>> Do you already have code that you can publish ? I'm particularly
>> interested (and I think Tomi Valkeinen would be as well) in looking at
>> the DSI operations you expose to DSI sinks (panels, transceivers, ...).
>
> Well, I'm afraid this might be little below your expectations, but here's
> an initial RFC of the part defining just the DSI bus. I need a bit more
> time for patches for Exynos MIPI DSI master and s6e8ax0 LCD.
>
> The implementation is very simple and heavily based on your MIPI DBI
> support and existing Exynos MIPI DSIM framework. Provided operation set is
> based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately
> this is my only source of information about MIPI DSI.
>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Linux Platform
>
> From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001
> From: Tomasz Figa 
> Date: Thu, 27 Dec 2012 12:36:15 +0100
> Subject: [RFC] video: display: Add generic MIPI DSI bus
>
> Signed-off-by: Tomasz Figa 
> ---
>  drivers/video/display/Kconfig|   4 +
>  drivers/video/display/Makefile   |   1 +
>  drivers/video/display/mipi-dsi-bus.c | 214
> +++
>  include/video/display.h  |   1 +
>  include/video/mipi-dsi-bus.h |  98 
>  5 files changed, 318 insertions(+)
>  create mode 100644 drivers/video/display/mipi-dsi-bus.c
>  create mode 100644 include/video/mipi-dsi-bus.h
>
> diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
> index 13b6aaf..dbaff9d 100644
> --- a/drivers/video/display/Kconfig
> +++ b/drivers/video/display/Kconfig
> @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI
> tristate
> default n
>
> +config DISPLAY_MIPI_DSI
> +   tristate
> +   default n
> +
>  config DISPLAY_PANEL_DPI
> tristate "DPI (Parallel) Display Panels"
> ---help---
> diff --git a/drivers/video/display/Makefile
> b/drivers/video/display/Makefile
> index 482bec7..429b3ac8 100644
> --- a/drivers/video/display/Makefile
> +++ b/drivers/video/display/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_DISPLAY_CORE) += display-core.o
>  obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
> +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-

[PATCH] drm/exynos: let drm handle edid allocations

[Rahul Sharma]

There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.

Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
---
This patch is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

 drivers/gpu/drm/exynos/exynos_drm_connector.c | 36 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  9 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |  4 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 25 ---
 5 files changed, 37 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ab37437..7ee43aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -96,7 +96,9 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
-   unsigned int count;
+   unsigned int count = 0;
+   struct edid *edid = NULL;
+   int ret;
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
@@ -114,27 +116,25 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
 * because lcd panel has only one mode.
 */
if (display_ops->get_edid) {
-   int ret;
-   void *edid;
-
-   edid = kzalloc(MAX_EDID, GFP_KERNEL);
-   if (!edid) {
-   DRM_ERROR("failed to allocate edid\n");
-   return 0;
+   edid = display_ops->get_edid(manager->dev, connector);
+   if (IS_ERR_OR_NULL(edid)) {
+   ret = PTR_ERR(edid);
+   edid = NULL;
+   DRM_ERROR("Panel operation get_edid failed %d\n", ret);
+   goto out;
}
 
-   ret = display_ops->get_edid(manager->dev, connector,
-   edid, MAX_EDID);
-   if (ret < 0) {
-   DRM_ERROR("failed to get edid data.\n");
-   kfree(edid);
-   edid = NULL;
-   return 0;
+   ret = drm_mode_connector_update_edid_property(connector, edid);
+   if (ret) {
+   DRM_ERROR("update edid property failed(%d)\n", ret);
+   goto out;
}
 
-   drm_mode_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
-   kfree(edid);
+   if (count < 0) {
+   DRM_ERROR("Add edid modes failed %d\n", count);
+   goto out;
+   }
} else {
struct exynos_drm_panel_info *panel;
struct drm_display_mode *mode = drm_mode_create(connector->dev);
@@ -161,6 +161,8 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
count = 1;
}
 
+out:
+   kfree(edid);
return count;
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b9e51bc..4606fac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -148,8 +148,8 @@ struct exynos_drm_overlay {
 struct exynos_drm_display_ops {
enum exynos_drm_output_type type;
bool (*is_connected)(struct device *dev);
-   int (*get_edid)(struct device *dev, struct drm_connector *connector,
-   u8 *edid, int len);
+   struct edid *(*get_edid)(struct device *dev,
+   struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
int (*check_timing)(struct device *dev, void *timing);
int (*power_on)(struct device *dev, int mode);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3a8eea6..681a4cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -108,18 +108,17 @@ static bool drm_hdmi_is_connected(struct device *dev)
return false;
 }
 
-static int drm_hdmi_get_edid(struct device *dev,
-   struct drm_connector *connector, u8 *edid, int len)
+struct edid *drm_hdmi_get_edid(struct device *dev,
+   struct drm_connector *connector)
 {
struct drm_hdmi_context *ctx = to_context(dev);
 
DRM_DEBUG_KMS("%s\n", __FILE__);
 
if (hdmi_ops && hdmi_ops->get_edid)
-   return hdmi_ops->get_edid(ctx

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

[bugzilla-daemon]

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

--- Comment #17 from klausenb...@hotmail.com ---
(In reply to comment #16)
> (In reply to comment #15)
> > A patch referencing this bug report has been merged in Linux v3.7-rc1:
> > 
> > commit bced76f27165ca7733437715185c3a1aa526f7a1
> > Author: Alex Deucher 
> > Date:   Fri Sep 14 09:45:50 2012 -0400
> > 
> > drm/radeon: restore backlight level on resume
> 
> appears to be the same patch as mentioned in comment #10, and (at least for
> me) still does not fix the issue

I have think i have same problem with a Radeon HD 6520G (AMD A6-3410MX), it
have "nothing" with backlight to do, if i use a flashlight i can see the screen
is 100% off.

-- 
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 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

[bugzilla-daemon]

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

--- Comment #24 from Anthony Waters  ---
On a HD6950 this patches causes the GPU to lock up if the GPU is in the low
power profile and the x server is started with multiple monitors attached.  The
x server doesn't crash immediatly, but crashes upon opening anything. I am
unable to SSH in so I cannot obtain a dmesg upon the crash.

Here are more details
1. Start up computer
2. Put gpu into low power profile through `echo low >
/sys/class/drm/card0/device/power_profile`
3. radeon_pm_info shows something like
default engine clock: 80 kHz
current engine clock: 249990 kHz
default memory clock: 125 kHz
current memory clock: 125 kHz
voltage: 900 mV
(as expected because the patch pushesh the memory clock to the maximum with
multiple heads)
4. start the x server and open an application, GPU locks up/crashes and
displays corruption some times

However, if the GPU is set to be in the high power profile it doesn't crash. 
Here are the power tables from the GPU

[0.814049] [drm:radeon_pm_print_states], 4 Power State(s)
[0.814050] [drm:radeon_pm_print_states], State 0: 
[0.814051] [drm:radeon_pm_print_states],Default
[0.814052] [drm:radeon_pm_print_states], 
[0.814053]  16 PCIE Lanes
[0.814138] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814138] [drm:radeon_pm_print_states],0 e: 80 m:
125  v: 1175
[0.814140] [drm:radeon_pm_print_states],1 e: 80 m:
125  v: 1175
[0.814141] [drm:radeon_pm_print_states],2 e: 80 m:
125  v: 1175
[0.814142] [drm:radeon_pm_print_states], State 1: Performance
[0.814143] [drm:radeon_pm_print_states],16 PCIE Lanes
[0.814144] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814145] [drm:radeon_pm_print_states],0 e: 25 m:
15   v: 900
[0.814146] [drm:radeon_pm_print_states],1 e: 50 m:
125  v: 1000
[0.814147] [drm:radeon_pm_print_states],2 e: 87 m:
125  v: 1175
[0.814148] [drm:radeon_pm_print_states], State 2: 
[0.814149] [drm:radeon_pm_print_states],16 PCIE Lanes
[0.814150] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814150] [drm:radeon_pm_print_states],0 e: 50 m:
125  v: 1000
[0.814151] [drm:radeon_pm_print_states],1 e: 50 m:
125  v: 1000
[0.814152] [drm:radeon_pm_print_states],2 e: 87 m:
125  v: 1175
[0.814154] [drm:radeon_pm_print_states], State 3: 
[0.814154] [drm:radeon_pm_print_states],16 PCIE Lanes
[0.814155] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814156] [drm:radeon_pm_print_states],0 e: 50 m:
125  v: 1000
[0.814157] [drm:radeon_pm_print_states],1 e: 50 m:
125  v: 1000
[0.814158] [drm:radeon_pm_print_states],2 e: 87 m:
125  v: 1175

To summarize (all with multiple heads)

1. e: 25 m: 125 v: 900 - crash
2. e: 80 m: 125 v: 1175 - no crash
3. e: 25 m: 15  v: 900 - no 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 43167] X intel driver causes wrong wraparound of console command line

[bugzilla-daemon]

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

--- Comment #43 from al...@verizon.net ---
(In reply to comment #42)

> Does dropping 'm' from the modeline solve your problem?

Hi Jani,

I cannot believe this !!!

# The "old", subject machine:
#  "ASUS P5E-VM HDMI" with Intel G35/ICH9R, Intel Core 2 Duo E8400, 3.0 GHz
#  kernel-3.7.1

[]$ cat /boot/grub/menu.lst
 ...
 kernel /boot/LFSkernel root=/dev/sda3 video=640x400M@70# without 'm'!

[]$ startx ...
# After exiting from Xorg (runlevel 5) to this console text, runlevel 3:

[]$ stty -a
speed 38400 baud; rows 25; columns 80; line = 0;
 ...
[]$
123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-
-bash:
123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-:
command not found

(Note:  the Comments limited window does not give proper justice to the actual
command line, '123456789-123456789- ...'.
In real life, on the screen, the command text DOES wrap-around correctly to the
next row after the 80th column.)

THANK YOU VERY MUCH !

Unless you come up with other questions/suggestions/comments, etc., I think(?)
you can close this (I'm still in shock!)

Best Wishes,
-- Alex

PS  We'll never know why 640x400 works.  Could it be the "M" which moves us to
a different look-up table (than what xrandr shows as "natural" resolutions)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC,libdrm 1/3] tegra: Add stream library

[Thierry Reding]

On Fri, Dec 28, 2012 at 09:45:48AM +0200, Arto Merilainen wrote:
> On 12/28/2012 08:47 AM, Mark Zhang wrote:
> >>+int tegra_fence_is_valid(const struct tegra_fence *fence)
> >>+{
> >>+int valid = fence ? 1 : 0;
> >>+valid = valid && fence->id != (uint32_t) -1;
> >>+valid = valid && fence->id < 32;
> >
> >Hardcode here. Assume always has 32 syncpts.
> >Change to a micro wrapped with tegra version ifdef will be better.
> >
> 
> You are correct. I will fix this.

I disagree. We shouldn't be hiding this kind of detail behind an #ifdef.
Instead it should be detected at runtime. Otherwise you'll need to build
different versions of libdrm for every generation of Tegra. That may be
fine for NVIDIA provided BSPs, but distributions would have a very hard
time dealing with that. What we want is software that works unmodified
on as many generations of Tegra as possible.

Thierry


pgpRWXYzm7WZc.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 33418] [RADEON:KMS:JUNIPER:HD6850:R600G] nexuiz continuous GPU soft resets

[bugzilla-daemon]

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

almos  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from almos  ---
The classic driver has been deprecated for a while now, since r600g has more
features and performance. I can play nexuiz on my HD6850 with r600g of mesa 9.0
and 9.1-dev just fine. BTW HD6850 is not Juniper, but Barts Pro.

I found that setting all CPU cores to performance while gaming gets rid of the
lag spikes. I use a startup script for all games that sets perfromance; runs
game; sets ondemand.

I think this one is safe to close.

-- 
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 58839] New: errors about too many fences printed while playing neverball

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 58839
  Assignee: dri-devel@lists.freedesktop.org
   Summary: errors about too many fences printed while playing
neverball
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: aaalmo...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

This is printed in mass quantities:
EE r600_pipe.c:80 r600_create_fence - r600: too many concurrent fences

They don't cause any visible rendering error though.

-- 
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 58840] New: rendering error with MSAA on HD6850

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 58840
  Assignee: dri-devel@lists.freedesktop.org
   Summary: rendering error with MSAA on HD6850
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: aaalmo...@gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

There are weird rendering errors when OpenGL applications use MSAA framebuffer.
The output is mostly noise. KDE 4.8 with OpenGL compositing is totally unusable
this way.

It is also interesting, that MS visuals are only advertised in glxinfo, if I
have the msaa-capable r600_dri.so installed on the system. If I only enable it
via LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH, they are not advertised, but still
selectable. At least with __GL_FSAA_MODE=4 the applications are broken in the
same way.

-- 
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: [PATCHv4 5/8] drm: tegra: Remove redundant host1x

[Thierry Reding]

On Mon, Dec 24, 2012 at 10:25:00PM -0700, Stephen Warren wrote:
> On 12/21/2012 11:50 PM, Terje Bergström wrote:
> > On 21.12.2012 16:36, Thierry Reding wrote:
> >> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
> >>> +static struct platform_driver tegra_drm_platform_driver = {
> >>> + .driver = {
> >>> + .name = "tegradrm",
> >>
> >> This should be "tegra-drm" to match the module name.
> > 
> > We've actually created two problems.
> > 
> > First is that the device name should match driver name which should
> > match module name. But host1x doesn't know the module name of tegradrm.
> 
> There's no hard requirement for the device/driver name to match the
> module name. It's good thing to do, but nothing will blow up if it don't
> (modules can use MODULE_ALIAS() to declare which drivers they expose).
> 
> But, what's the problem with host1x knowing the driver name; the host1x
> driver and tegradrm driver are both part of the same code-base, so this
> seems trivial to achieve.

Indeed. If we define the name to match the tegra-drm module name, then
just changing the above line is fine. This doesn't need to be automatic.
Making sure that both strings match in both drivers is enough.

> > Second problem is that host1x driver creates tegradrm device even if
> > tegradrm isn't loaded to system.
> 
> That's fine. If there's no driver, the device simply won't be probe()d.
> That's just like a device node existing in device tree, but the driver
> for it not being enabled in the kernel, or the relevant module not being
> inserted.
> 
> > These mean that the device has to be created in tegra-drm module to have
> 
> I definitely disagree here.

Instead of going over this back and forth, I've decided to rewrite this
patch from scratch the way I think it should be done. Maybe that'll make
things clearer. I haven't tested it on real hardware yet because I don't
have access over the holidays, but I'll post the patch once I've
verified that it actually works. The code is based on patches 1-4 of
this series and is meant to replace patch 5.

Thierry


pgpEJJ2OuqAhi.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 58042] [bisected] Garbled UI in Team Fortress 2 Beta

[bugzilla-daemon]

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

Bryan Quigley  changed:

   What|Removed |Added

 CC||bryanquig...@ubuntu.com

--- Comment #5 from Bryan Quigley  ---
I have the garbled issue, but if I try to play the game it soon crashes.  Do
you all have this additional issue as well?

-- 
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 51581] xorg not start after kexec when use nouveau

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=51581





--- Comment #1 from Suloev Dmitry   2012-12-29 06:30:53 
---
Any news?

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

[Bug 50091] [BISECTED]GeForce 6150SE: system hangs on X-server start with garbled screen

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=50091


Suloev Dmitry  changed:

   What|Removed |Added

 CC||suloevdmi...@gmail.com




--- Comment #24 from Suloev Dmitry   2012-12-29 
06:33:44 ---
You use kexec for reboot or this happen on cold boot?

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

[RFC v2 0/5] Common Display Framework

[Sascha Hauer]

On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote:
> On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer  
> wrote:
> > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> >
> > This implies that the master driver knows all potential subdevices,
> > something which is not true for SoCs which have external i2c encoders
> > attached to unrelated i2c controllers.
> 
> well, it can be brute-forced..  ie. drm driver calls common
> register_all_panels() fxn, which, well, registers all the
> panel/display subdev's based on their corresponding CONFIG_FOO_PANEL
> defines.  If you anyways aren't building the panels as separate
> modules, that would work.  Maybe not the most *elegant* approach, but
> simple and functional.
> 
> I guess it partly depends on the structure in devicetree.  If you are
> assuming that the i2c encoder belongs inside the i2c bus, like:
> 
>   &i2cN {
> foo-i2c-encoder {
>   
> };
>   };
> 
> and you are letting devicetree create the devices, then it doesn't
> quite work.  I'm not entirely convinced you should do it that way.
> Really any device like that is going to be hooked up to at least a
> couple busses..  i2c, some sort of bus carrying pixel data, maybe some
> gpio's, etc.  So maybe makes more sense for a virtual drm/kms bus, and
> then use phandle stuff to link it to the various other busses it
> needs:
> 
>   mydrmdev {
> foo-i2c-encoder {
>i2c = <&i2cN>;
>gpio = <&gpioM 2 3>
>...
> };
>   };

This seems to shift initialization order problem to another place.
Here we have to make sure the controller is initialized before the drm
driver. Same with suspend/resume.

It's not only i2c devices, also platform devices. On i.MX for example we
have a hdmi transmitter which is somewhere on the physical address
space.

I think grouping the different units together in a devicetree blob
because we think they might form a logical virtual device is not going
to work. It might make it easier from a drm perspective, but I think
doing this will make for a lot of special cases. What will happen for
example if you have two encoder devices in a row to configure? The
foo-i2c-encoder would then get another child node.

Right now the devicetree is strictly ordered by (control-, not data-)
bus topology. Linux has great helper code to support this model. Giving
up this help to brute force a different topology and then trying to fit
the result back into the Linux Bus hierarchy doesn't sound like a good
idea to me.

> 
> ok, admittedly that is a bit different from other proposals about how
> this all fits in devicetree.. but otoh, I'm not a huge believer in
> letting something that is supposed to make life easier (DT), actually
> make things harder or more complicated.  Plus this CDF stuff all needs
> to also work on platforms not using OF/DT.

Right, but every other platform I know of is also described by its bus
topology, be it platform device based or PCI or maybe even USB based.

CDF has to solve the same problem as ASoC and soc-camera: subdevices for
a virtual device can come from many different corners of the system. BTW
one example for a i2c encoder would be the SiI9022 which could not only
be part of a drm device, but also of an ASoC device.

Sascha

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

[Bug 41265] Radeon KMS does not work on thunderbolt media dock

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

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

--- Comment #53 from Gerald Nunn  ---
Does AMD need to make a change to the proprietary fglrx drivers in order for
the kernel patch to work with their drivers and if so has a bug been opened
with them? I'm using Ubuntu 12.10 with kernel 3.6.9 and no problem getting this
to work with the gallium (radeon) drivers, however when I try the fglrx drivers
I get the following messages in kern.log:

Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925204] <3>[fglrx:hal_read_VBIOS]
*ERROR* Invalid AMD VBIOS!
Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925207] <3>[fglrx:hal_init_gpu]
*ERROR* Failed to read VBIOS!
Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925208] <6>[fglrx] device open
failed with code -1

Which sounds like a similar issue to what was described here. While I generally
find the gallium drivers to be more stable and reliable then fglrx,
unfortunately fglrx significantly outperforms the open source drivers when it
comes to gaming.

-- 
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/20121228/f1a6d13d/attachment.html>

[PATCH] video: drm: exynos: mie bypass enable for fimd

[Leela Krishna Amudala]

Hello Inki Dae,

On Thu, Dec 27, 2012 at 11:47 AM, Inki Dae  wrote:
>
> Hi,
>
> DISP1BLK_CFG register is related to GScaler, HDCP and MIXER as well. So
> it's not good that this register is controlled in fimd module. And I think
> the function to control the register should be placed in SoC common file .
> In other words, other drivers should be able to control the register through
> common thing also.
>

Thanks for reviewing the patch.
You mean to say that this functionality should be implemented at arch side
and called by drivers using call back functions ?

If so, then if we moved the driver to full DT version, all the call
backs will be removed.
Then how to make a call to this function?

So I thought other drivers (apart from Fimd) also parses the
appropriate nodes and
program the register as per the need.

Please correct me if my understanding is wrong.

Best Wishes,
Leela Krishna Amudala.


> Thanks,
> Inki Dae
>
> 2012/12/26 Leela Krishna Amudala 
>>
>> Bypasses the mie for fimd by parsing the register and bit offset values
>> from "mie-bypass" node, if "mie-bypass" node is present in the dts file.
>>
>> Signed-off-by: Leela Krishna Amudala 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 55
>> 
>>  1 file changed, 55 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index bf0d9ba..f8ad259 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -118,6 +118,12 @@ static const struct of_device_id
>> fimd_driver_dt_match[] = {
>>  MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
>>  #endif
>>
>> +struct mie_bypass {
>> +   u32 enable_bypass;
>> +   void __iomem*bypass_reg;
>> +   u32 bypass_bit_offset;
>> +};
>> +
>>  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
>> struct platform_device *pdev)
>>  {
>> @@ -133,6 +139,41 @@ static inline struct fimd_driver_data
>> *drm_fimd_get_driver_data(
>> platform_get_device_id(pdev)->driver_data;
>>  }
>>
>> +static struct mie_bypass *parse_mie_bypass_for_fimd(struct device *dev,
>> +   struct device_node
>> *mie_bypass_node)
>> +{
>> +   struct mie_bypass *bypass_data;
>> +   u32 phy_address;
>> +
>> +   bypass_data = devm_kzalloc(dev, sizeof(*bypass_data),
>> GFP_KERNEL);
>> +   if (!bypass_data) {
>> +   dev_err(dev, "memory allocation for bypass data
>> failed\n");
>> +   return ERR_PTR(-ENOMEM);
>> +   }
>> +   of_property_read_u32(mie_bypass_node,
>> "samsung,mie-bypass-enable",
>> +   &bypass_data->enable_bypass);
>> +   of_property_read_u32(mie_bypass_node, "samsung,disp1blk-cfg-reg",
>> +   &phy_address);
>> +   of_property_read_u32(mie_bypass_node,
>> "samsung,bypass-bit-offset",
>> +   &bypass_data->bypass_bit_offset);
>> +
>> +   bypass_data->bypass_reg = ioremap(phy_address, SZ_4);
>>
>> +   if (!bypass_data->bypass_reg) {
>> +   dev_err(dev, "failed to ioremap phy_address\n");
>> +   return ERR_PTR(-ENOMEM);
>> +   }
>> +   return bypass_data;
>> +}
>>
>> +
>> +static void mie_bypass_for_fimd(struct mie_bypass *bypass_data)
>> +{
>> +   u32 reg;
>> +
>> +   reg = __raw_readl(bypass_data->bypass_reg);
>> +   reg |= (1 << bypass_data->bypass_bit_offset);
>> +   __raw_writel(reg, bypass_data->bypass_reg);
>> +}
>> +
>>  static bool fimd_display_is_connected(struct device *dev)
>>  {
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>> @@ -906,12 +947,26 @@ static int __devinit fimd_probe(struct
>> platform_device *pdev)
>> struct exynos_drm_fimd_pdata *pdata;
>> struct exynos_drm_panel_info *panel;
>> struct resource *res;
>> +   struct device_node *mie_bypass_node;
>> +   struct mie_bypass *bypass_data = NULL;
>> int win;
>> int ret = -EINVAL;
>>
>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>
>> pdata = pdev->dev.platform_data;
>> +   if (pdev->dev.of_node) {
>> +   mie_bypass_node = of_find_node_by_name(pdev->dev.of_node,
>> +   "mie-bypass");
>> +   if (mie_bypass_node) {
>> +   bypass_data =
>> parse_mie_bypass_for_fimd(&pdev->dev,
>> +   mie_bypass_node);
>>
>> +   if (IS_ERR(bypass_data))
>> +   return PTR_ERR(bypass_data);
>> +   if (bypass_data->enable_bypass)
>> +   mie_bypass_for_fimd(bypass_data);
>> +   }
>> +   }
>> if (!pdata) {
>> dev_err(dev, "no platform data specified\n");
>> return -EINVAL;

[PATCH] video: drm: exynos: mie bypass enable for fimd

[Inki Dae]

2012/12/28 Leela Krishna Amudala :
> Hello Inki Dae,
>
> On Thu, Dec 27, 2012 at 11:47 AM, Inki Dae  wrote:
>>
>> Hi,
>>
>> DISP1BLK_CFG register is related to GScaler, HDCP and MIXER as well. So
>> it's not good that this register is controlled in fimd module. And I think
>> the function to control the register should be placed in SoC common file .
>> In other words, other drivers should be able to control the register through
>> common thing also.
>>
>
> Thanks for reviewing the patch.
> You mean to say that this functionality should be implemented at arch side
> and called by drivers using call back functions ?
>
> If so, then if we moved the driver to full DT version, all the call
> backs will be removed.
> Then how to make a call to this function?
>
> So I thought other drivers (apart from Fimd) also parses the
> appropriate nodes and
> program the register as per the need.
>
> Please correct me if my understanding is wrong.
>

The base address of DISP1BLK_CFG already was iorempped by
iotable_init() at machine init.  So you can control DISP1BLK_CFG
register using only offset. But your patch does ioremap again and also
even not iounmap. This is ugly. Please see
arch/arm/plat-samsung/setup-mipiphy.c how the common register is
controlled and this is a good example. And please abuse dt.

> Best Wishes,
> Leela Krishna Amudala.
>
>
>> Thanks,
>> Inki Dae
>>
>> 2012/12/26 Leela Krishna Amudala 
>>>
>>> Bypasses the mie for fimd by parsing the register and bit offset values
>>> from "mie-bypass" node, if "mie-bypass" node is present in the dts file.
>>>
>>> Signed-off-by: Leela Krishna Amudala 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 55
>>> 
>>>  1 file changed, 55 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index bf0d9ba..f8ad259 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -118,6 +118,12 @@ static const struct of_device_id
>>> fimd_driver_dt_match[] = {
>>>  MODULE_DEVICE_TABLE(of, fimd_driver_dt_match);
>>>  #endif
>>>
>>> +struct mie_bypass {
>>> +   u32 enable_bypass;
>>> +   void __iomem*bypass_reg;
>>> +   u32 bypass_bit_offset;
>>> +};
>>> +
>>>  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
>>> struct platform_device *pdev)
>>>  {
>>> @@ -133,6 +139,41 @@ static inline struct fimd_driver_data
>>> *drm_fimd_get_driver_data(
>>> platform_get_device_id(pdev)->driver_data;
>>>  }
>>>
>>> +static struct mie_bypass *parse_mie_bypass_for_fimd(struct device *dev,
>>> +   struct device_node
>>> *mie_bypass_node)
>>> +{
>>> +   struct mie_bypass *bypass_data;
>>> +   u32 phy_address;
>>> +
>>> +   bypass_data = devm_kzalloc(dev, sizeof(*bypass_data),
>>> GFP_KERNEL);
>>> +   if (!bypass_data) {
>>> +   dev_err(dev, "memory allocation for bypass data
>>> failed\n");
>>> +   return ERR_PTR(-ENOMEM);
>>> +   }
>>> +   of_property_read_u32(mie_bypass_node,
>>> "samsung,mie-bypass-enable",
>>> +   &bypass_data->enable_bypass);
>>> +   of_property_read_u32(mie_bypass_node, "samsung,disp1blk-cfg-reg",
>>> +   &phy_address);
>>> +   of_property_read_u32(mie_bypass_node,
>>> "samsung,bypass-bit-offset",
>>> +   &bypass_data->bypass_bit_offset);
>>> +
>>> +   bypass_data->bypass_reg = ioremap(phy_address, SZ_4);
>>>
>>> +   if (!bypass_data->bypass_reg) {
>>> +   dev_err(dev, "failed to ioremap phy_address\n");
>>> +   return ERR_PTR(-ENOMEM);
>>> +   }
>>> +   return bypass_data;
>>> +}
>>>
>>> +
>>> +static void mie_bypass_for_fimd(struct mie_bypass *bypass_data)
>>> +{
>>> +   u32 reg;
>>> +
>>> +   reg = __raw_readl(bypass_data->bypass_reg);
>>> +   reg |= (1 << bypass_data->bypass_bit_offset);
>>> +   __raw_writel(reg, bypass_data->bypass_reg);
>>> +}
>>> +
>>>  static bool fimd_display_is_connected(struct device *dev)
>>>  {
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>> @@ -906,12 +947,26 @@ static int __devinit fimd_probe(struct
>>> platform_device *pdev)
>>> struct exynos_drm_fimd_pdata *pdata;
>>> struct exynos_drm_panel_info *panel;
>>> struct resource *res;
>>> +   struct device_node *mie_bypass_node;
>>> +   struct mie_bypass *bypass_data = NULL;
>>> int win;
>>> int ret = -EINVAL;
>>>
>>> DRM_DEBUG_KMS("%s\n", __FILE__);
>>>
>>> pdata = pdev->dev.platform_data;
>>> +   if (pdev->dev.of_node) {
>>> +   mie_bypass_node = of_find_node_by_name(pdev->dev.of_node,
>>> +   "mie-bypass");
>>> +   if (mie_bypass_node) {
>>> +   

[RFC,libdrm 1/3] tegra: Add stream library

[Mark Zhang]

I just skimmed the code of libdrm while I'm trying to understand the
host1x driver. So below is what I found.

Mark
On 12/13/2012 10:01 PM, Arto Meril?inen wrote:
> From: Arto Merilainen 
> 
> This patch introduces tegra stream library. The library is used for
> buffer management, command stream construction and work
> synchronization.
> 
[...]
> +
> +/*
> + * tegra_fence_is_valid(fence)
> + *
> + * Check validity of a fence. We just check that the fence range
> + * is valid w.r.t. host1x hardware.
> + */
> +
> +int tegra_fence_is_valid(const struct tegra_fence *fence)
> +{
> +int valid = fence ? 1 : 0;
> +valid = valid && fence->id != (uint32_t) -1;
> +valid = valid && fence->id < 32;

Hardcode here. Assume always has 32 syncpts.
Change to a micro wrapped with tegra version ifdef will be better.

> +return valid;
> +}
> +
[...]
> +
> +/* Add fences */
> +if (num_fences) {
> +
> +tegra_stream_push(stream,
> +nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
> +host1x_uclass_wait_syncpt_r(), num_fences));
> +
> +for (; num_fences; num_fences--, fence++) {
> +assert(tegra_fence_is_valid(fence));

This is useless. We already add "1 + num_fences" to num_words above. So
move this "assert" before adding "1 + num_fences" to num_words makes sense.

> +
> +tegra_stream_push(stream, 
> nvhost_class_host_wait_syncpt(fence->id,
> +fence->value));
> +}
> +}
> +
> +if (class_id)
> +tegra_stream_push(stream, nvhost_opcode_setclass(class_id, 0, 0));
> +
> +return 0;
> +}
> +
[...]
> +
> +#endif /* TEGRA_DRMIF_H */
> 

[RFC,libdrm 2/3] tegra: Add 2d library

[Mark Zhang]

I just skimmed the code of libdrm while I'm trying to understand the
host1x driver. So below is what I found.

Mark
On 12/13/2012 10:01 PM, Arto Meril?inen wrote:
> From: Francis Hart 
> 
> This patch introduces a simple 2d library on top of stream library.
> 
> Signed-off-by: Francis Hart 
[...]
> +void
> +g2fill_dispatch(const struct tegra_2d_g2fill *hw,
> +struct tegra_stream *stream)
> +{
> +ASSERT(hw);
> +ASSERT(hw->is_valid);
> +ASSERT(stream);
> +
> +tegra_stream_push_setclass(stream, NV_GRAPHICS_2D_CLASS_ID);

I think at the end of the "tegra_stream_begin", we already pushed a
setclass opcode into the stream's active buffer.
So why we need another one here?

> +
> +tegra_stream_push_words(stream,
> +&hw->block,
> +sizeof(hw->block) / sizeof(uint32_t),
> +1,
> +tegra_reloc(&hw->block.dstba,
> +hw->dst_handle,
> +hw->dst_offset));
> +}
> +
[...]
> +#endif // TEGRA_2D_H
> 

[RFC,libdrm 1/3] tegra: Add stream library

[Arto Merilainen]

On 12/28/2012 08:47 AM, Mark Zhang wrote:
>> +int tegra_fence_is_valid(const struct tegra_fence *fence)
>> +{
>> +int valid = fence ? 1 : 0;
>> +valid = valid && fence->id != (uint32_t) -1;
>> +valid = valid && fence->id < 32;
>
> Hardcode here. Assume always has 32 syncpts.
> Change to a micro wrapped with tegra version ifdef will be better.
>

You are correct. I will fix this.

>> +return valid;
>> +}
>> +
> [...]
>> +
>> +/* Add fences */
>> +if (num_fences) {
>> +
>> +tegra_stream_push(stream,
>> +nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
>> +host1x_uclass_wait_syncpt_r(), num_fences));
>> +
>> +for (; num_fences; num_fences--, fence++) {
>> +assert(tegra_fence_is_valid(fence));
>
> This is useless. We already add "1 + num_fences" to num_words above. So
> move this "assert" before adding "1 + num_fences" to num_words makes sense.
>

The assertion checks the validity of a single fence - not if there is 
room in the command buffer.

The goal is to prevent having invalid fences in the command stream. If 
this check were not here it would be possible to initialise a fence with 
tegra_fence_clear() and put that fence into the stream.

>> +
>> +tegra_stream_push(stream, 
>> nvhost_class_host_wait_syncpt(fence->id,
>> +fence->value));
>> +}
>> +}
>> +
>> +if (class_id)
>> +tegra_stream_push(stream, nvhost_opcode_setclass(class_id, 0, 0));
>> +
>> +return 0;
>> +}
>> +
> [...]
>> +
>> +#endif /* TEGRA_DRMIF_H */
>>

- Arto

[RFC,libdrm 1/3] tegra: Add stream library

[Mark Zhang]

On 12/28/2012 03:45 PM, Arto Merilainen wrote:
> On 12/28/2012 08:47 AM, Mark Zhang wrote:
>>> +int tegra_fence_is_valid(const struct tegra_fence *fence)
>>> +{
>>> +int valid = fence ? 1 : 0;
>>> +valid = valid && fence->id != (uint32_t) -1;
>>> +valid = valid && fence->id < 32;
>>
>> Hardcode here. Assume always has 32 syncpts.
>> Change to a micro wrapped with tegra version ifdef will be better.
>>
> 
> You are correct. I will fix this.
> 
>>> +return valid;
>>> +}
>>> +
>> [...]
>>> +
>>> +/* Add fences */
>>> +if (num_fences) {
>>> +
>>> +tegra_stream_push(stream,
>>> +nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
>>> +host1x_uclass_wait_syncpt_r(), num_fences));
>>> +
>>> +for (; num_fences; num_fences--, fence++) {
>>> +assert(tegra_fence_is_valid(fence));
>>
>> This is useless. We already add "1 + num_fences" to num_words above. So
>> move this "assert" before adding "1 + num_fences" to num_words makes
>> sense.
>>
> 
> The assertion checks the validity of a single fence - not if there is
> room in the command buffer.
> 
> The goal is to prevent having invalid fences in the command stream. If
> this check were not here it would be possible to initialise a fence with
> tegra_fence_clear() and put that fence into the stream.

My idea is, if one fence is invalid, then we should not count this in
"num_words". In current code, if one fence is invalid, then this fence
will not be pushed into the command stream, and the "num_words" shows a
wrong command buffer size.

So I think we should:
- validate the fences, remove the invalid fence
- update num_words
- then you don't need to check fence here - I mean, before push a host1x
syncpt wait command into the active buffer of stream.

> 
>>> +
>>> +tegra_stream_push(stream,
>>> nvhost_class_host_wait_syncpt(fence->id,
>>> +fence->value));
>>> +}
>>> +}
>>> +
>>> +if (class_id)
>>> +tegra_stream_push(stream, nvhost_opcode_setclass(class_id,
>>> 0, 0));
>>> +
>>> +return 0;
>>> +}
>>> +
>> [...]
>>> +
>>> +#endif /* TEGRA_DRMIF_H */
>>>
> 
> - Arto

[RFC,libdrm 1/3] tegra: Add stream library

[Arto Merilainen]

On 12/28/2012 09:57 AM, Mark Zhang wrote:
> On 12/28/2012 03:45 PM, Arto Merilainen wrote:
>> On 12/28/2012 08:47 AM, Mark Zhang wrote:
 +
 +/* Add fences */
 +if (num_fences) {
 +
 +tegra_stream_push(stream,
 +nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
 +host1x_uclass_wait_syncpt_r(), num_fences));
 +
 +for (; num_fences; num_fences--, fence++) {
 +assert(tegra_fence_is_valid(fence));
>>>
>>> This is useless. We already add "1 + num_fences" to num_words above. So
>>> move this "assert" before adding "1 + num_fences" to num_words makes
>>> sense.
>>>
>>
>> The assertion checks the validity of a single fence - not if there is
>> room in the command buffer.
>>
>> The goal is to prevent having invalid fences in the command stream. If
>> this check were not here it would be possible to initialise a fence with
>> tegra_fence_clear() and put that fence into the stream.
>
> My idea is, if one fence is invalid, then we should not count this in
> "num_words". In current code, if one fence is invalid, then this fence
> will not be pushed into the command stream, and the "num_words" shows a
> wrong command buffer size.
>
> So I think we should:
> - validate the fences, remove the invalid fence
> - update num_words
> - then you don't need to check fence here - I mean, before push a host1x
> syncpt wait command into the active buffer of stream.
>

In my opinion asking tegra_stream_begin() to put a bad fence into the 
stream is a case we should never be. assert() kills the application 
immediately (in debug builds) and usually this helps the programmer for 
1) finding bugs 2) not doing bad code.

"Silencing" is not a good solution especially in this case: 
tegra_stream_flush() returns an invalid fence when flushing fails. If 
the application chains submits (i.e. do a blit and then do another using 
the output of the first blit) it is crucial to be sure the first submit 
has been performed before starting the second one.

- Arto

[RFC,libdrm 1/3] tegra: Add stream library

[Mark Zhang]

On 12/28/2012 04:50 PM, Arto Merilainen wrote:
> On 12/28/2012 09:57 AM, Mark Zhang wrote:
>> On 12/28/2012 03:45 PM, Arto Merilainen wrote:
>>> On 12/28/2012 08:47 AM, Mark Zhang wrote:
> +
> +/* Add fences */
> +if (num_fences) {
> +
> +tegra_stream_push(stream,
> +nvhost_opcode_setclass(NV_HOST1X_CLASS_ID,
> +host1x_uclass_wait_syncpt_r(), num_fences));
> +
> +for (; num_fences; num_fences--, fence++) {
> +assert(tegra_fence_is_valid(fence));

 This is useless. We already add "1 + num_fences" to num_words above. So
 move this "assert" before adding "1 + num_fences" to num_words makes
 sense.

>>>
>>> The assertion checks the validity of a single fence - not if there is
>>> room in the command buffer.
>>>
>>> The goal is to prevent having invalid fences in the command stream. If
>>> this check were not here it would be possible to initialise a fence with
>>> tegra_fence_clear() and put that fence into the stream.
>>
>> My idea is, if one fence is invalid, then we should not count this in
>> "num_words". In current code, if one fence is invalid, then this fence
>> will not be pushed into the command stream, and the "num_words" shows a
>> wrong command buffer size.
>>
>> So I think we should:
>> - validate the fences, remove the invalid fence
>> - update num_words
>> - then you don't need to check fence here - I mean, before push a host1x
>> syncpt wait command into the active buffer of stream.
>>
> 
> In my opinion asking tegra_stream_begin() to put a bad fence into the
> stream is a case we should never be. assert() kills the application
> immediately (in debug builds) and usually this helps the programmer for
> 1) finding bugs 2) not doing bad code.
> 

Yep, I agree. But in release builds, assert does nothing. So this
checking doesn't make sense and also a wrong fence will be pushed into
command buffer silently. And we always use release version in real
products, so we can't count on this "assert".

> "Silencing" is not a good solution especially in this case:
> tegra_stream_flush() returns an invalid fence when flushing fails. If
> the application chains submits (i.e. do a blit and then do another using
> the output of the first blit) it is crucial to be sure the first submit
> has been performed before starting the second one.
>

Yes. So I suggest doing fence checking at the beginning of the
"tegra_stream_begin", if invalid fence found, return an error.


> - Arto

[PATCHv4 0/8] Support for Tegra 2D hardware

[Mark Zhang]

Hi Terje,

Here is the second part comments. I admit I still haven't finished
reading the codes... really too many codes. :)
Anyway I'll keep doing this when I have free slots.

diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index a936902..c3ded60 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
*context,
if (err)
goto fail;

+   /* We define CMA as an temporary solution in host1x driver.
+  That's also why we have a CMA kernel config in it.
+  But seems here, in tegradrm, we hardcode the CMA here.
+  So what do you do when host1x change to IOMMU?
+  Do we also need to define a CMA config in tegradrm
driver,
+  then after host1x changes to IOMMU, we add another IOMMU
+  config in tegradrm? Or we should invent another more
+  generic wrapper layer here? */
cmdbuf.mem = handle_cma_to_host1x(drm, file_priv,
cmdbuf.mem);
if (!cmdbuf.mem)
goto fail;
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index cc8ca2f..0867b72 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -82,6 +82,26 @@ struct host1x_job *host1x_job_alloc(struct
host1x_channel *ch,
mem += num_unpins * sizeof(dma_addr_t);
job->pin_ids = num_unpins ? mem : NULL;

+   /* I think this is a somewhat ugly design.
+  Actually "addr_phys" is consisted by "reloc_addr_phys" and
+  "gather_addr_phys".
+  Why don't we just declare "reloc_addr_phys" and
"gather_addr_phys"?
+  In current design, let's say if one nvhost newbie changes the
order
+  of these 2 blocks of code in function "pin_job_mem":
+
+  for (i = 0; i < job->num_relocs; i++) {
+   struct host1x_reloc *reloc = &job->relocarray[i];
+   job->pin_ids[count] = reloc->target;
+   count++;
+  }
+
+  for (i = 0; i < job->num_gathers; i++) {
+   struct host1x_job_gather *g = &job->gathers[i];
+   job->pin_ids[count] = g->mem_id;
+   count++;
+  }
+
+  Then likely something weird occurs... */
job->reloc_addr_phys = job->addr_phys;
job->gather_addr_phys = &job->addr_phys[num_relocs];

@@ -252,6 +272,10 @@ static int do_relocs(struct host1x_job *job,
}
}

+   /* I have question here. Does this mean the address info
+  which need to be relocated(according to the libdrm codes,
+  seems this address is "0xDEADBEEF") always staying at the
+  beginning of a page? */
__raw_writel(
(job->reloc_addr_phys[i] +
reloc->target_offset) >> reloc->shift,
@@ -565,6 +589,7 @@ int host1x_job_pin(struct host1x_job *job, struct
platform_device *pdev)
}
}

+   /* if (host1x_firewall && !err) { */
if (host1x_firewall) {
err = copy_gathers(job, pdev);
if (err) {
@@ -573,6 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct
platform_device *pdev)
}
}

+/* Rename this label to "out" or something else.
+   Because if everything goes right, the codes under this label also
+   get executed. */
 fail:
wmb();

diff --git a/drivers/gpu/host1x/memmgr.c b/drivers/gpu/host1x/memmgr.c
index f3954f7..bb5763d 100644
--- a/drivers/gpu/host1x/memmgr.c
+++ b/drivers/gpu/host1x/memmgr.c
@@ -156,6 +156,9 @@ int host1x_memmgr_pin_array_ids(struct
platform_device *dev,
count, &unpin_data[pin_count],
phys_addr);

+   /* I don't think the current "host1x_cma_pin_array_ids"
+  is able to return a negative value. So this "if" doesn't
+  make sense...*/
if (cma_count < 0) {
/* clean up previous handles */
while (pin_count) {

Mark
On 12/21/2012 07:39 PM, Terje Bergstrom wrote:
> This set of patches adds support for Tegra20 and Tegra30 host1x and
> 2D. It is based on linux-next-20121220.
> 
> The fourth version has only few changes compared to previous version:
>  * Fixed some sparse warnings
>  * Fixed host1x Makefile to allow building as module
>  * Fixed host1x module unload
>  * Fixed tegradrm unload sequence
>  * host1x creates DRM dummy device and tegradrm uses it for storing
>DRM related data.
> 
> Some of the issues left open:
>  * Register definitions still use static inline. There has been a
>debate about code style versus ability to use compiler type
>checking and code coverage analysis. There was no conclusion, so
>I left it as was.
>  * Uses

[RFC,libdrm 1/3] tegra: Add stream library

[Arto Merilainen]

On 12/28/2012 11:04 AM, Mark Zhang wrote:
> On 12/28/2012 04:50 PM, Arto Merilainen wrote:
>>
>> In my opinion asking tegra_stream_begin() to put a bad fence into the
>> stream is a case we should never be. assert() kills the application
>> immediately (in debug builds) and usually this helps the programmer for
>> 1) finding bugs 2) not doing bad code.
>>
>
> Yep, I agree. But in release builds, assert does nothing. So this
> checking doesn't make sense and also a wrong fence will be pushed into
> command buffer silently. And we always use release version in real
> products, so we can't count on this "assert".

The only pro of using assert is low (=no :-) ) overhead in release builds.

>
>> "Silencing" is not a good solution especially in this case:
>> tegra_stream_flush() returns an invalid fence when flushing fails. If
>> the application chains submits (i.e. do a blit and then do another using
>> the output of the first blit) it is crucial to be sure the first submit
>> has been performed before starting the second one.
>>
>
> Yes. So I suggest doing fence checking at the beginning of the
> "tegra_stream_begin", if invalid fence found, return an error.
>

This sounds reasonable.

- Arto

[RFC v2 0/5] Common Display Framework

[Vikas Sajjan]

On 27 December 2012 20:13, Tomasz Figa  wrote:
> Hi Laurent,
>
> On Monday 24 of December 2012 15:12:28 Laurent Pinchart wrote:
>> Hi Tomasz,
>>
>> On Friday 21 December 2012 11:00:52 Tomasz Figa wrote:
>> > On Tuesday 18 of December 2012 08:31:30 Vikas Sajjan wrote:
>> > > On 17 December 2012 20:55, Laurent Pinchart wrote:
>> > > > Hi Vikas,
>> > > >
>> > > > Sorry for the late reply. I now have more time to work on CDF, so
>> > > > delays should be much shorter.
>> > > >
>> > > > On Thursday 06 December 2012 10:51:15 Vikas Sajjan wrote:
>> > > > > Hi Laurent,
>> > > > >
>> > > > > I was thinking of porting CDF to samsung EXYNOS 5250 platform,
>> > > > > what
>> > > > > I found is that, the exynos display controller is MIPI DSI based
>> > > > > controller.
>> > > > >
>> > > > > But if I look at CDF patches, it has only support for MIPI DBI
>> > > > > based
>> > > > > Display controller.
>> > > > >
>> > > > > So my question is, do we have any generic framework for MIPI DSI
>> > > > > based display controller? basically I wanted to know, how to go
>> > > > > about
>> > > > > porting CDF for such kind of display controller.
>> > > >
>> > > > MIPI DSI support is not available yet. The only reason for that is
>> > > > that I don't have any MIPI DSI hardware to write and test the code
>> > > > with :-)
>> > > >
>> > > > The common display framework should definitely support MIPI DSI. I
>> > > > think the existing MIPI DBI code could be used as a base, so the
>> > > > implementation shouldn't be too high.
>> > > >
>> > > > Yeah, i was also thinking in similar lines, below is my though for
>> > > > MIPI DSI support in CDF.
>> > >
>> > > o   MIPI DSI support as part of CDF framework will expose
>> > > ?  mipi_dsi_register_device(mpi_device) (will be called
>> > > mach-xxx-dt.c
>> > > file )
>> > > ?  mipi_dsi_register_driver(mipi_driver, bus ops) (will be called
>> > > from
>> > > platform specific init driver call )
>> > > ?bus ops will be
>> > > o   read data
>> > > o   write data
>> > > o   write command
>> > > ?  MIPI DSI will be registered as bus_register()
>> > >
>> > > When MIPI DSI probe is called, it (e.g., Exynos or OMAP MIPI DSI)
>> > > will
>> > > initialize the MIPI DSI HW IP.
>> > >
>> > > This probe will also parse the DT file for MIPI DSI based panel, add
>> > > the panel device (device_add() ) to kernel and register the display
>> > > entity with its control and  video ops with CDF.
>> > >
>> > > I can give this a try.
>> >
>> > I am currently in progress of reworking Exynos MIPI DSIM code and
>> > s6e8ax0 LCD driver to use the v2 RFC of Common Display Framework. I
>> > have most of the work done, I have just to solve several remaining
>> > problems.
>> Do you already have code that you can publish ? I'm particularly
>> interested (and I think Tomi Valkeinen would be as well) in looking at
>> the DSI operations you expose to DSI sinks (panels, transceivers, ...).
>
> Well, I'm afraid this might be little below your expectations, but here's
> an initial RFC of the part defining just the DSI bus. I need a bit more
> time for patches for Exynos MIPI DSI master and s6e8ax0 LCD.
>
> The implementation is very simple and heavily based on your MIPI DBI
> support and existing Exynos MIPI DSIM framework. Provided operation set is
> based on operation set used by Exynos s6e8ax0 LCD driver. Unfortunately
> this is my only source of information about MIPI DSI.
>
> Best regards,
> --
> Tomasz Figa
> Samsung Poland R&D Center
> SW Solution Development, Linux Platform
>
> From bad07d8bdce0ff76cbc81a9da597c0d01e5244f7 Mon Sep 17 00:00:00 2001
> From: Tomasz Figa 
> Date: Thu, 27 Dec 2012 12:36:15 +0100
> Subject: [RFC] video: display: Add generic MIPI DSI bus
>
> Signed-off-by: Tomasz Figa 
> ---
>  drivers/video/display/Kconfig|   4 +
>  drivers/video/display/Makefile   |   1 +
>  drivers/video/display/mipi-dsi-bus.c | 214
> +++
>  include/video/display.h  |   1 +
>  include/video/mipi-dsi-bus.h |  98 
>  5 files changed, 318 insertions(+)
>  create mode 100644 drivers/video/display/mipi-dsi-bus.c
>  create mode 100644 include/video/mipi-dsi-bus.h
>
> diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
> index 13b6aaf..dbaff9d 100644
> --- a/drivers/video/display/Kconfig
> +++ b/drivers/video/display/Kconfig
> @@ -9,6 +9,10 @@ config DISPLAY_MIPI_DBI
> tristate
> default n
>
> +config DISPLAY_MIPI_DSI
> +   tristate
> +   default n
> +
>  config DISPLAY_PANEL_DPI
> tristate "DPI (Parallel) Display Panels"
> ---help---
> diff --git a/drivers/video/display/Makefile
> b/drivers/video/display/Makefile
> index 482bec7..429b3ac8 100644
> --- a/drivers/video/display/Makefile
> +++ b/drivers/video/display/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_DISPLAY_CORE) += display-core.o
>  obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
> +obj-$(CONFIG_DISPLAY_MIPI_DSI) += mipi-dsi-

[PATCH] drm/exynos: let drm handle edid allocations

[Rahul Sharma]

There's no need to allocate edid twice and do a memcpy when drm helpers
exist to do just that. This patch cleans that interaction up, and
doesn't keep the edid hanging around in the connector.

Signed-off-by: Sean Paul 
Signed-off-by: Rahul Sharma 
---
This patch is based on branch "exynos-drm-next" at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

 drivers/gpu/drm/exynos/exynos_drm_connector.c | 36 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 +--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c  |  9 +++
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h  |  4 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 25 ---
 5 files changed, 37 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index ab37437..7ee43aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -96,7 +96,9 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
to_exynos_connector(connector);
struct exynos_drm_manager *manager = exynos_connector->manager;
struct exynos_drm_display_ops *display_ops = manager->display_ops;
-   unsigned int count;
+   unsigned int count = 0;
+   struct edid *edid = NULL;
+   int ret;

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

@@ -114,27 +116,25 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
 * because lcd panel has only one mode.
 */
if (display_ops->get_edid) {
-   int ret;
-   void *edid;
-
-   edid = kzalloc(MAX_EDID, GFP_KERNEL);
-   if (!edid) {
-   DRM_ERROR("failed to allocate edid\n");
-   return 0;
+   edid = display_ops->get_edid(manager->dev, connector);
+   if (IS_ERR_OR_NULL(edid)) {
+   ret = PTR_ERR(edid);
+   edid = NULL;
+   DRM_ERROR("Panel operation get_edid failed %d\n", ret);
+   goto out;
}

-   ret = display_ops->get_edid(manager->dev, connector,
-   edid, MAX_EDID);
-   if (ret < 0) {
-   DRM_ERROR("failed to get edid data.\n");
-   kfree(edid);
-   edid = NULL;
-   return 0;
+   ret = drm_mode_connector_update_edid_property(connector, edid);
+   if (ret) {
+   DRM_ERROR("update edid property failed(%d)\n", ret);
+   goto out;
}

-   drm_mode_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
-   kfree(edid);
+   if (count < 0) {
+   DRM_ERROR("Add edid modes failed %d\n", count);
+   goto out;
+   }
} else {
struct exynos_drm_panel_info *panel;
struct drm_display_mode *mode = drm_mode_create(connector->dev);
@@ -161,6 +161,8 @@ static int exynos_drm_connector_get_modes(struct 
drm_connector *connector)
count = 1;
}

+out:
+   kfree(edid);
return count;
 }

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b9e51bc..4606fac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -148,8 +148,8 @@ struct exynos_drm_overlay {
 struct exynos_drm_display_ops {
enum exynos_drm_output_type type;
bool (*is_connected)(struct device *dev);
-   int (*get_edid)(struct device *dev, struct drm_connector *connector,
-   u8 *edid, int len);
+   struct edid *(*get_edid)(struct device *dev,
+   struct drm_connector *connector);
void *(*get_panel)(struct device *dev);
int (*check_timing)(struct device *dev, void *timing);
int (*power_on)(struct device *dev, int mode);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 3a8eea6..681a4cb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -108,18 +108,17 @@ static bool drm_hdmi_is_connected(struct device *dev)
return false;
 }

-static int drm_hdmi_get_edid(struct device *dev,
-   struct drm_connector *connector, u8 *edid, int len)
+struct edid *drm_hdmi_get_edid(struct device *dev,
+   struct drm_connector *connector)
 {
struct drm_hdmi_context *ctx = to_context(dev);

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

if (hdmi_ops && hdmi_ops->get_edid)
-   return hdmi_ops->get_edid(ctx->hdmi_ct

[Bug 43829] Resuming my AMD A4-3300 based laptop leaves the screen black

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

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

--- Comment #17 from klausenbusk at hotmail.com ---
(In reply to comment #16)
> (In reply to comment #15)
> > A patch referencing this bug report has been merged in Linux v3.7-rc1:
> > 
> > commit bced76f27165ca7733437715185c3a1aa526f7a1
> > Author: Alex Deucher 
> > Date:   Fri Sep 14 09:45:50 2012 -0400
> > 
> > drm/radeon: restore backlight level on resume
> 
> appears to be the same patch as mentioned in comment #10, and (at least for
> me) still does not fix the issue

I have think i have same problem with a Radeon HD 6520G (AMD A6-3410MX), it
have "nothing" with backlight to do, if i use a flashlight i can see the screen
is 100% off.

-- 
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/20121228/df02a4fb/attachment.html>

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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

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

--- Comment #24 from Anthony Waters  ---
On a HD6950 this patches causes the GPU to lock up if the GPU is in the low
power profile and the x server is started with multiple monitors attached.  The
x server doesn't crash immediatly, but crashes upon opening anything. I am
unable to SSH in so I cannot obtain a dmesg upon the crash.

Here are more details
1. Start up computer
2. Put gpu into low power profile through `echo low >
/sys/class/drm/card0/device/power_profile`
3. radeon_pm_info shows something like
default engine clock: 80 kHz
current engine clock: 249990 kHz
default memory clock: 125 kHz
current memory clock: 125 kHz
voltage: 900 mV
(as expected because the patch pushesh the memory clock to the maximum with
multiple heads)
4. start the x server and open an application, GPU locks up/crashes and
displays corruption some times

However, if the GPU is set to be in the high power profile it doesn't crash. 
Here are the power tables from the GPU

[0.814049] [drm:radeon_pm_print_states], 4 Power State(s)
[0.814050] [drm:radeon_pm_print_states], State 0: 
[0.814051] [drm:radeon_pm_print_states],Default
[0.814052] [drm:radeon_pm_print_states], 
[0.814053]  16 PCIE Lanes
[0.814138] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814138] [drm:radeon_pm_print_states],0 e: 80 m:
125  v: 1175
[0.814140] [drm:radeon_pm_print_states],1 e: 80 m:
125  v: 1175
[0.814141] [drm:radeon_pm_print_states],2 e: 80 m:
125  v: 1175
[0.814142] [drm:radeon_pm_print_states], State 1: Performance
[0.814143] [drm:radeon_pm_print_states],16 PCIE Lanes
[0.814144] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814145] [drm:radeon_pm_print_states],0 e: 25 m:
15   v: 900
[0.814146] [drm:radeon_pm_print_states],1 e: 50 m:
125  v: 1000
[0.814147] [drm:radeon_pm_print_states],2 e: 87 m:
125  v: 1175
[0.814148] [drm:radeon_pm_print_states], State 2: 
[0.814149] [drm:radeon_pm_print_states],16 PCIE Lanes
[0.814150] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814150] [drm:radeon_pm_print_states],0 e: 50 m:
125  v: 1000
[0.814151] [drm:radeon_pm_print_states],1 e: 50 m:
125  v: 1000
[0.814152] [drm:radeon_pm_print_states],2 e: 87 m:
125  v: 1175
[0.814154] [drm:radeon_pm_print_states], State 3: 
[0.814154] [drm:radeon_pm_print_states],16 PCIE Lanes
[0.814155] [drm:radeon_pm_print_states],3 Clock Mode(s)
[0.814156] [drm:radeon_pm_print_states],0 e: 50 m:
125  v: 1000
[0.814157] [drm:radeon_pm_print_states],1 e: 50 m:
125  v: 1000
[0.814158] [drm:radeon_pm_print_states],2 e: 87 m:
125  v: 1175

To summarize (all with multiple heads)

1. e: 25 m: 125 v: 900 - crash
2. e: 80 m: 125 v: 1175 - no crash
3. e: 25 m: 15  v: 900 - no 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/20121228/712df5b9/attachment.html>

[Bug 43167] X intel driver causes wrong wraparound of console command line

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

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

--- Comment #43 from alupu at verizon.net ---
(In reply to comment #42)

> Does dropping 'm' from the modeline solve your problem?

Hi Jani,

I cannot believe this !!!

# The "old", subject machine:
#  "ASUS P5E-VM HDMI" with Intel G35/ICH9R, Intel Core 2 Duo E8400, 3.0 GHz
#  kernel-3.7.1

[]$ cat /boot/grub/menu.lst
 ...
 kernel /boot/LFSkernel root=/dev/sda3 video=640x400M at 70# without 
'm'!

[]$ startx ...
# After exiting from Xorg (runlevel 5) to this console text, runlevel 3:

[]$ stty -a
speed 38400 baud; rows 25; columns 80; line = 0;
 ...
[]$
123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-
-bash:
123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-123456789-:
command not found

(Note:  the Comments limited window does not give proper justice to the actual
command line, '123456789-123456789- ...'.
In real life, on the screen, the command text DOES wrap-around correctly to the
next row after the 80th column.)

THANK YOU VERY MUCH !

Unless you come up with other questions/suggestions/comments, etc., I think(?)
you can close this (I'm still in shock!)

Best Wishes,
-- Alex

PS  We'll never know why 640x400 works.  Could it be the "M" which moves us to
a different look-up table (than what xrandr shows as "natural" resolutions)?

-- 
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/20121228/58e44692/attachment.html>

[RFC,libdrm 1/3] tegra: Add stream library

[Thierry Reding]

On Fri, Dec 28, 2012 at 09:45:48AM +0200, Arto Merilainen wrote:
> On 12/28/2012 08:47 AM, Mark Zhang wrote:
> >>+int tegra_fence_is_valid(const struct tegra_fence *fence)
> >>+{
> >>+int valid = fence ? 1 : 0;
> >>+valid = valid && fence->id != (uint32_t) -1;
> >>+valid = valid && fence->id < 32;
> >
> >Hardcode here. Assume always has 32 syncpts.
> >Change to a micro wrapped with tegra version ifdef will be better.
> >
> 
> You are correct. I will fix this.

I disagree. We shouldn't be hiding this kind of detail behind an #ifdef.
Instead it should be detected at runtime. Otherwise you'll need to build
different versions of libdrm for every generation of Tegra. That may be
fine for NVIDIA provided BSPs, but distributions would have a very hard
time dealing with that. What we want is software that works unmodified
on as many generations of Tegra as possible.

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/20121228/57592198/attachment.pgp>

[Bug 33418] [RADEON:KMS:JUNIPER:HD6850:R600G] nexuiz continuous GPU soft resets

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

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

almos  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from almos  ---
The classic driver has been deprecated for a while now, since r600g has more
features and performance. I can play nexuiz on my HD6850 with r600g of mesa 9.0
and 9.1-dev just fine. BTW HD6850 is not Juniper, but Barts Pro.

I found that setting all CPU cores to performance while gaming gets rid of the
lag spikes. I use a startup script for all games that sets perfromance; runs
game; sets ondemand.

I think this one is safe to close.

-- 
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/20121228/0ee6584d/attachment.html>

[Bug 58839] New: errors about too many fences printed while playing neverball

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

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

  Priority: medium
Bug ID: 58839
  Assignee: dri-devel at lists.freedesktop.org
   Summary: errors about too many fences printed while playing
neverball
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: aaalmosss at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

This is printed in mass quantities:
EE r600_pipe.c:80 r600_create_fence - r600: too many concurrent fences

They don't cause any visible rendering error though.

-- 
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/20121228/680a544a/attachment.html>

[Bug 58840] New: rendering error with MSAA on HD6850

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

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

  Priority: medium
Bug ID: 58840
  Assignee: dri-devel at lists.freedesktop.org
   Summary: rendering error with MSAA on HD6850
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: aaalmosss at gmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

There are weird rendering errors when OpenGL applications use MSAA framebuffer.
The output is mostly noise. KDE 4.8 with OpenGL compositing is totally unusable
this way.

It is also interesting, that MS visuals are only advertised in glxinfo, if I
have the msaa-capable r600_dri.so installed on the system. If I only enable it
via LIBGL_DRIVERS_PATH and LD_LIBRARY_PATH, they are not advertised, but still
selectable. At least with __GL_FSAA_MODE=4 the applications are broken in the
same way.

-- 
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/20121228/dfc7d414/attachment.html>

[PATCHv4 5/8] drm: tegra: Remove redundant host1x

[Thierry Reding]

On Mon, Dec 24, 2012 at 10:25:00PM -0700, Stephen Warren wrote:
> On 12/21/2012 11:50 PM, Terje Bergstr?m wrote:
> > On 21.12.2012 16:36, Thierry Reding wrote:
> >> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
> >>> +static struct platform_driver tegra_drm_platform_driver = {
> >>> + .driver = {
> >>> + .name = "tegradrm",
> >>
> >> This should be "tegra-drm" to match the module name.
> > 
> > We've actually created two problems.
> > 
> > First is that the device name should match driver name which should
> > match module name. But host1x doesn't know the module name of tegradrm.
> 
> There's no hard requirement for the device/driver name to match the
> module name. It's good thing to do, but nothing will blow up if it don't
> (modules can use MODULE_ALIAS() to declare which drivers they expose).
> 
> But, what's the problem with host1x knowing the driver name; the host1x
> driver and tegradrm driver are both part of the same code-base, so this
> seems trivial to achieve.

Indeed. If we define the name to match the tegra-drm module name, then
just changing the above line is fine. This doesn't need to be automatic.
Making sure that both strings match in both drivers is enough.

> > Second problem is that host1x driver creates tegradrm device even if
> > tegradrm isn't loaded to system.
> 
> That's fine. If there's no driver, the device simply won't be probe()d.
> That's just like a device node existing in device tree, but the driver
> for it not being enabled in the kernel, or the relevant module not being
> inserted.
> 
> > These mean that the device has to be created in tegra-drm module to have
> 
> I definitely disagree here.

Instead of going over this back and forth, I've decided to rewrite this
patch from scratch the way I think it should be done. Maybe that'll make
things clearer. I haven't tested it on real hardware yet because I don't
have access over the holidays, but I'll post the patch once I've
verified that it actually works. The code is based on patches 1-4 of
this series and is meant to replace patch 5.

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/20121228/ab48c272/attachment.pgp>

[PATCH 04/10 Resend] drm/exynos: Use devm_clk_get in exynos_drm_fimc.c

[Sachin Kamat]

This eliminates the need for explicit clk_put and makes the
cleanup and exit path code simpler.

Cc: Eunchul Kim 
Signed-off-by: Sachin Kamat 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c |   45 ++
 1 files changed, 9 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index ef3a838..c52197b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1739,64 +1739,49 @@ static int fimc_probe(struct platform_device *pdev)
platform_get_device_id(pdev)->driver_data;

/* clock control */
-   ctx->sclk_fimc_clk = clk_get(dev, "sclk_fimc");
+   ctx->sclk_fimc_clk = devm_clk_get(dev, "sclk_fimc");
if (IS_ERR(ctx->sclk_fimc_clk)) {
dev_err(dev, "failed to get src fimc clock.\n");
return PTR_ERR(ctx->sclk_fimc_clk);
}
clk_enable(ctx->sclk_fimc_clk);

-   ctx->fimc_clk = clk_get(dev, "fimc");
+   ctx->fimc_clk = devm_clk_get(dev, "fimc");
if (IS_ERR(ctx->fimc_clk)) {
dev_err(dev, "failed to get fimc clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
return PTR_ERR(ctx->fimc_clk);
}

-   ctx->wb_clk = clk_get(dev, "pxl_async0");
+   ctx->wb_clk = devm_clk_get(dev, "pxl_async0");
if (IS_ERR(ctx->wb_clk)) {
dev_err(dev, "failed to get writeback a clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
return PTR_ERR(ctx->wb_clk);
}

-   ctx->wb_b_clk = clk_get(dev, "pxl_async1");
+   ctx->wb_b_clk = devm_clk_get(dev, "pxl_async1");
if (IS_ERR(ctx->wb_b_clk)) {
dev_err(dev, "failed to get writeback b clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
return PTR_ERR(ctx->wb_b_clk);
}

-   parent_clk = clk_get(dev, ddata->parent_clk);
+   parent_clk = devm_clk_get(dev, ddata->parent_clk);

if (IS_ERR(parent_clk)) {
dev_err(dev, "failed to get parent clock.\n");
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
return PTR_ERR(parent_clk);
}

if (clk_set_parent(ctx->sclk_fimc_clk, parent_clk)) {
dev_err(dev, "failed to set parent.\n");
-   clk_put(parent_clk);
clk_disable(ctx->sclk_fimc_clk);
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
return -EINVAL;
}

-   clk_put(parent_clk);
+   devm_clk_put(dev, parent_clk);
clk_set_rate(ctx->sclk_fimc_clk, pdata->clk_rate);

/* resource memory */
@@ -1804,16 +1789,14 @@ static int fimc_probe(struct platform_device *pdev)
ctx->regs = devm_request_and_ioremap(dev, ctx->regs_res);
if (!ctx->regs) {
dev_err(dev, "failed to map registers.\n");
-   ret = -ENXIO;
-   goto err_clk;
+   return -ENXIO;
}

/* resource irq */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to request irq resource.\n");
-   ret = -ENOENT;
-   goto err_clk;
+   return -ENOENT;
}

ctx->irq = res->start;
@@ -1821,7 +1804,7 @@ static int fimc_probe(struct platform_device *pdev)
IRQF_ONESHOT, "drm_fimc", ctx);
if (ret < 0) {
dev_err(dev, "failed to request irq.\n");
-   goto err_clk;
+   return ret;
}

/* context initailization */
@@ -1867,11 +1850,6 @@ err_ippdrv_register:
pm_runtime_disable(dev);
 err_get_irq:
free_irq(ctx->irq, ctx);
-err_clk:
-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);

return ret;
 }
@@ -1891,11 +1869,6 @@ static int fimc_remove(struct platform_device *pdev)

free_irq(ctx->irq, ctx);

-   clk_put(ctx->sclk_fimc_clk);
-   clk_put(ctx->fimc_clk);
-   clk_put(ctx->wb_clk);
-   clk_put(ctx->wb_b_clk);
-
return 0;
 }

-- 
1.7.4.1