* Re: [PATCH Re-send] pwm-backlight: Use devm_pwm_get in pwm_bl.c
From: Jingoo Han @ 2012-09-17 9:40 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347862847-2774-1-git-send-email-sachin.kamat@linaro.org>
On Monday, September 17, 2012 6:33 PM Thierry Reding wrote
>
> On Mon, Sep 17, 2012 at 11:50:47AM +0530, Sachin Kamat wrote:
> > This file already makes use of device managed functions.
> > Convert pwm_get() too to use it.
>
> I find this description a bit confusing. pwm_get() is not converted, but
> rather the driver is converted to use devm_pwm_get() instead of
> pwm_get().
>
> How about this:
>
> pwm-backlight: Use devm_pwm_get() instead of pwm_get()
>
> Managed versions of the pwm_get() and pwm_put() functions were recently
> added to the PWM framework. They can be used to simplify cleanup in the
> error paths and the device removal callback.
>
It looks good.
Sachin, how about you?
Best regards,
Jingoo Han
> If that's okay with you, I can just replace it before pushing so there's
> no need for you to resend.
>
> Thierry
^ permalink raw reply
* Re: [PATCH Re-send] pwm-backlight: Use devm_pwm_get in pwm_bl.c
From: Thierry Reding @ 2012-09-17 9:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347862847-2774-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
On Mon, Sep 17, 2012 at 11:50:47AM +0530, Sachin Kamat wrote:
> This file already makes use of device managed functions.
> Convert pwm_get() too to use it.
I find this description a bit confusing. pwm_get() is not converted, but
rather the driver is converted to use devm_pwm_get() instead of
pwm_get().
How about this:
pwm-backlight: Use devm_pwm_get() instead of pwm_get()
Managed versions of the pwm_get() and pwm_put() functions were recently
added to the PWM framework. They can be used to simplify cleanup in the
error paths and the device removal callback.
If that's okay with you, I can just replace it before pushing so there's
no need for you to resend.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 14/34] dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
From: Guennadi Liakhovetski @ 2012-09-17 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347860103-4141-15-git-send-email-shawn.guo@linaro.org>
On Mon, 17 Sep 2012, Shawn Guo wrote:
> The header ipu.h really belongs to dma subsystem rather than imx
> platform. Rename it to ipu-dma.h and put it into include/linux/dma/.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-media@vger.kernel.org
> Cc: linux-fbdev@vger.kernel.org
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Thanks
Guennadi
> ---
> drivers/dma/ipu/ipu_idmac.c | 3 +--
> drivers/dma/ipu/ipu_irq.c | 3 +--
> drivers/media/video/mx3_camera.c | 2 +-
> drivers/video/mx3fb.c | 2 +-
> .../mach/ipu.h => include/linux/dma/ipu-dma.h | 6 +++---
> 5 files changed, 7 insertions(+), 9 deletions(-)
> rename arch/arm/mach-imx/include/mach/ipu.h => include/linux/dma/ipu-dma.h (97%)
>
> diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
> index c7573e5..6585537 100644
> --- a/drivers/dma/ipu/ipu_idmac.c
> +++ b/drivers/dma/ipu/ipu_idmac.c
> @@ -22,8 +22,7 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/module.h>
> -
> -#include <mach/ipu.h>
> +#include <linux/dma/ipu-dma.h>
>
> #include "../dmaengine.h"
> #include "ipu_intern.h"
> diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
> index fa95bcc..a5ee37d 100644
> --- a/drivers/dma/ipu/ipu_irq.c
> +++ b/drivers/dma/ipu/ipu_irq.c
> @@ -15,8 +15,7 @@
> #include <linux/irq.h>
> #include <linux/io.h>
> #include <linux/module.h>
> -
> -#include <mach/ipu.h>
> +#include <linux/dma/ipu-dma.h>
>
> #include "ipu_intern.h"
>
> diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
> index 1481b0d..892cba5 100644
> --- a/drivers/media/video/mx3_camera.c
> +++ b/drivers/media/video/mx3_camera.c
> @@ -17,6 +17,7 @@
> #include <linux/vmalloc.h>
> #include <linux/interrupt.h>
> #include <linux/sched.h>
> +#include <linux/dma/ipu-dma.h>
>
> #include <media/v4l2-common.h>
> #include <media/v4l2-dev.h>
> @@ -24,7 +25,6 @@
> #include <media/soc_camera.h>
> #include <media/soc_mediabus.h>
>
> -#include <mach/ipu.h>
> #include <linux/platform_data/camera-mx3.h>
> #include <linux/platform_data/dma-imx.h>
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index d738108..3b63ad8 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -26,10 +26,10 @@
> #include <linux/console.h>
> #include <linux/clk.h>
> #include <linux/mutex.h>
> +#include <linux/dma/ipu-dma.h>
>
> #include <linux/platform_data/dma-imx.h>
> #include <mach/hardware.h>
> -#include <mach/ipu.h>
> #include <linux/platform_data/video-mx3fb.h>
>
> #include <asm/io.h>
> diff --git a/arch/arm/mach-imx/include/mach/ipu.h b/include/linux/dma/ipu-dma.h
> similarity index 97%
> rename from arch/arm/mach-imx/include/mach/ipu.h
> rename to include/linux/dma/ipu-dma.h
> index 539e559..1803111 100644
> --- a/arch/arm/mach-imx/include/mach/ipu.h
> +++ b/include/linux/dma/ipu-dma.h
> @@ -9,8 +9,8 @@
> * published by the Free Software Foundation.
> */
>
> -#ifndef _IPU_H_
> -#define _IPU_H_
> +#ifndef __LINUX_DMA_IPU_DMA_H
> +#define __LINUX_DMA_IPU_DMA_H
>
> #include <linux/types.h>
> #include <linux/dmaengine.h>
> @@ -174,4 +174,4 @@ struct idmac_channel {
> #define to_tx_desc(tx) container_of(tx, struct idmac_tx_desc, txd)
> #define to_idmac_chan(c) container_of(c, struct idmac_channel, dma_chan)
>
> -#endif
> +#endif /* __LINUX_DMA_IPU_DMA_H */
> --
> 1.7.9.5
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 00/34] i.MX multi-platform support
From: Sascha Hauer @ 2012-09-17 7:51 UTC (permalink / raw)
To: Shawn Guo
Cc: alsa-devel, Mark Brown, Artem Bityutskiy, linux-fbdev,
Wim Van Sebroeck, linux-mtd, linux-i2c, Arnd Bergmann,
Florian Tobias Schandinat, Paulius Zaleckas, Chris Ball,
linux-media, linux-watchdog, rtc-linux, Rob Herring,
linux-arm-kernel, Fabio Estevam, Vinod Koul, Greg Kroah-Hartman,
linux-usb, linux-mmc, Wolfram Sang, Javier Martin, Andrew Morton
In-Reply-To: <1347860103-4141-1-git-send-email-shawn.guo@linaro.org>
Hi Shawn,
On Mon, Sep 17, 2012 at 01:34:29PM +0800, Shawn Guo wrote:
> The series enables multi-platform support for imx. Since the required
> frameworks (clk, pwm) and spare_irq have already been adopted on imx,
> the series is all about cleaning up mach/* headers. Along with the
> changes, arch/arm/plat-mxc gets merged into arch/arm/mach-imx.
>
> It's based on a bunch of branches (works from others), Rob's initial
> multi-platform series, Arnd's platform-data and smp_ops (Marc's) and
> imx 3.7 material (Sascha and myself).
>
> It's available on branch below.
>
> git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform
>
> It's been tested on imx5 and imx6, and only compile-tested on imx2 and
> imx3, so testing on imx2/3 are appreciated.
Great work! This really pushes the i.MX architecture one step closer to
a clean code base.
I gave it a test on i.MX1, i.MX27, i.MX31 and i.MX35. All run fine, but
the last patch breaks the imx_v4_v5_defconfig: Somehow it now defaults
to ARMv7 based machines. I haven't looked into it, just reenabled
ARMv4/ARMv5 and the boards again -> works. The config should be updated
with the last patch.
I'm fine with the changes to mx2-camera, but Javier should give his ok
to it, he has worked on it quite a lot recently.
One other issue related to imx-dma, see comment to that patch.
Otherwise:
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Thanks
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-5555 |
^ permalink raw reply
* [PATCH Re-send] pwm-backlight: Use devm_pwm_get in pwm_bl.c
From: Sachin Kamat @ 2012-09-17 6:32 UTC (permalink / raw)
To: linux-fbdev
This file already makes use of device managed functions.
Convert pwm_get() too to use it.
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/backlight/pwm_bl.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 4965408..0c91023 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -218,7 +218,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->exit = data->exit;
pb->dev = &pdev->dev;
- pb->pwm = pwm_get(&pdev->dev, NULL);
+ pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm)) {
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
@@ -251,7 +251,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
if (IS_ERR(bl)) {
dev_err(&pdev->dev, "failed to register backlight\n");
ret = PTR_ERR(bl);
- goto err_bl;
+ goto err_alloc;
}
bl->props.brightness = data->dft_brightness;
@@ -260,8 +260,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, bl);
return 0;
-err_bl:
- pwm_put(pb->pwm);
err_alloc:
if (data->exit)
data->exit(&pdev->dev);
@@ -276,7 +274,6 @@ static int pwm_backlight_remove(struct platform_device *pdev)
backlight_device_unregister(bl);
pwm_config(pb->pwm, 0, pb->period);
pwm_disable(pb->pwm);
- pwm_put(pb->pwm);
if (pb->exit)
pb->exit(&pdev->dev);
return 0;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] pwm-backlight: Use devm_pwm_get in pwm_bl.c
From: Sachin Kamat @ 2012-09-17 6:25 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347352949-17515-1-git-send-email-sachin.kamat@linaro.org>
Hi Thierry,
On 17 September 2012 11:34, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Wed, Sep 12, 2012 at 09:55:48AM +0900, Jingoo Han wrote:
>> On Tuesday, September 11, 2012 5:42 PM Sachin Kamat wrote
>> >
>> > This file already makes use of device managed functions.
>> > Convert pwm_get() too to use it.
>> >
>> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>>
>> CC'ed Thierry Reding.
>>
>> Acked-by: Jingoo Han <jg1.han@samsung.com>
>
> Hi Sachin,
>
> As discussed elsewhere I'm taking over maintenance of the pwm-backlight
> driver as part of the PWM subsystem.
That is really nice :)
I hadn't been Cc'ed on your first
> send and I'm not subscribed to linux-fbdev so I didn't receive a copy of
> the patch.
Yes. I obtained the list from get_maintainers.pl, so missed out CCing you.
I will re-send the patch with you in CC now.
>
> Thanks,
> Thierry
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH] pwm-backlight: Use devm_pwm_get in pwm_bl.c
From: Thierry Reding @ 2012-09-17 6:16 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347352949-17515-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
On Mon, Sep 17, 2012 at 11:43:11AM +0530, Sachin Kamat wrote:
> Hi Thierry,
>
> On 17 September 2012 11:34, Thierry Reding
> <thierry.reding@avionic-design.de> wrote:
> > On Wed, Sep 12, 2012 at 09:55:48AM +0900, Jingoo Han wrote:
> >> On Tuesday, September 11, 2012 5:42 PM Sachin Kamat wrote
> >> >
> >> > This file already makes use of device managed functions.
> >> > Convert pwm_get() too to use it.
> >> >
> >> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> >>
> >> CC'ed Thierry Reding.
> >>
> >> Acked-by: Jingoo Han <jg1.han@samsung.com>
> >
> > Hi Sachin,
> >
> > As discussed elsewhere I'm taking over maintenance of the pwm-backlight
> > driver as part of the PWM subsystem.
>
> That is really nice :)
>
> I hadn't been Cc'ed on your first
> > send and I'm not subscribed to linux-fbdev so I didn't receive a copy of
> > the patch.
>
> Yes. I obtained the list from get_maintainers.pl, so missed out CCing you.
> I will re-send the patch with you in CC now.
Yes, I've contacted Richard to get his approval as the backlight
subsystem maintainer. If he's okay I'll send a patch shortly to add the
corresponding files to MAINTAINERS so that next time I'll wind up in
that list.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] pwm-backlight: Use devm_pwm_get in pwm_bl.c
From: Thierry Reding @ 2012-09-17 6:04 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1347352949-17515-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Wed, Sep 12, 2012 at 09:55:48AM +0900, Jingoo Han wrote:
> On Tuesday, September 11, 2012 5:42 PM Sachin Kamat wrote
> >
> > This file already makes use of device managed functions.
> > Convert pwm_get() too to use it.
> >
> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>
> CC'ed Thierry Reding.
>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
Hi Sachin,
As discussed elsewhere I'm taking over maintenance of the pwm-backlight
driver as part of the PWM subsystem. I hadn't been Cc'ed on your first
send and I'm not subscribed to linux-fbdev so I didn't receive a copy of
the patch.
Thanks,
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 30/34] video: imxfb: remove mach/hardware.h inclusion
From: Shawn Guo @ 2012-09-17 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347860103-4141-1-git-send-email-shawn.guo@linaro.org>
It changes the driver to use platform_device_id rather than cpu_is_xxx
to determine the controller type, and updates the platform code
accordingly.
As the result, mach/hardware.h inclusion gets removed from the driver.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
arch/arm/mach-imx/clk-imx1.c | 6 ++---
arch/arm/mach-imx/clk-imx21.c | 6 ++---
arch/arm/mach-imx/clk-imx25.c | 6 ++---
arch/arm/mach-imx/clk-imx27.c | 6 ++---
arch/arm/mach-imx/devices/devices-common.h | 1 +
arch/arm/mach-imx/devices/platform-imx-fb.c | 11 ++++----
drivers/video/imxfb.c | 38 ++++++++++++++++++++++-----
7 files changed, 51 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx1.c b/arch/arm/mach-imx/clk-imx1.c
index 6b9407b..4bff66a 100644
--- a/arch/arm/mach-imx/clk-imx1.c
+++ b/arch/arm/mach-imx/clk-imx1.c
@@ -100,9 +100,9 @@ int __init mx1_clocks_init(unsigned long fref)
clk_register_clkdev(clk[per2], "per", "imx1-cspi.1");
clk_register_clkdev(clk[dummy], "ipg", "imx1-cspi.1");
clk_register_clkdev(clk[per2], NULL, "imx-mmc.0");
- clk_register_clkdev(clk[per2], "per", "imx-fb.0");
- clk_register_clkdev(clk[dummy], "ipg", "imx-fb.0");
- clk_register_clkdev(clk[dummy], "ahb", "imx-fb.0");
+ clk_register_clkdev(clk[per2], "per", "imx1-fb.0");
+ clk_register_clkdev(clk[dummy], "ipg", "imx1-fb.0");
+ clk_register_clkdev(clk[dummy], "ahb", "imx1-fb.0");
clk_register_clkdev(clk[hclk], "mshc", NULL);
clk_register_clkdev(clk[per3], "ssi", NULL);
clk_register_clkdev(clk[clk32], NULL, "imx1-rtc.0");
diff --git a/arch/arm/mach-imx/clk-imx21.c b/arch/arm/mach-imx/clk-imx21.c
index 96a4788..e981b48 100644
--- a/arch/arm/mach-imx/clk-imx21.c
+++ b/arch/arm/mach-imx/clk-imx21.c
@@ -157,9 +157,9 @@ int __init mx21_clocks_init(unsigned long lref, unsigned long href)
clk_register_clkdev(clk[cspi2_ipg_gate], "ipg", "imx21-cspi.1");
clk_register_clkdev(clk[per2], "per", "imx21-cspi.2");
clk_register_clkdev(clk[cspi3_ipg_gate], "ipg", "imx21-cspi.2");
- clk_register_clkdev(clk[per3], "per", "imx-fb.0");
- clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx-fb.0");
- clk_register_clkdev(clk[lcdc_hclk_gate], "ahb", "imx-fb.0");
+ clk_register_clkdev(clk[per3], "per", "imx21-fb.0");
+ clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx21-fb.0");
+ clk_register_clkdev(clk[lcdc_hclk_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[usb_gate], "per", "imx21-hcd.0");
clk_register_clkdev(clk[usb_hclk_gate], "ahb", "imx21-hcd.0");
clk_register_clkdev(clk[nfc_gate], NULL, "imx21-nand.0");
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 71fe521..da7155d 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -219,9 +219,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[fec_ipg], "ipg", "imx25-fec.0");
clk_register_clkdev(clk[fec_ahb], "ahb", "imx25-fec.0");
clk_register_clkdev(clk[dryice_ipg], NULL, "imxdi_rtc.0");
- clk_register_clkdev(clk[lcdc_ipg_per], "per", "imx-fb.0");
- clk_register_clkdev(clk[lcdc_ipg], "ipg", "imx-fb.0");
- clk_register_clkdev(clk[lcdc_ahb], "ahb", "imx-fb.0");
+ clk_register_clkdev(clk[lcdc_ipg_per], "per", "imx21-fb.0");
+ clk_register_clkdev(clk[lcdc_ipg], "ipg", "imx21-fb.0");
+ clk_register_clkdev(clk[lcdc_ahb], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[wdt_ipg], NULL, "imx2-wdt.0");
clk_register_clkdev(clk[ssi1_ipg], NULL, "imx-ssi.0");
clk_register_clkdev(clk[ssi2_ipg], NULL, "imx-ssi.1");
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 114be46..f3a66a9 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -221,9 +221,9 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[cspi1_ipg_gate], NULL, "imx27-cspi.0");
clk_register_clkdev(clk[cspi2_ipg_gate], NULL, "imx27-cspi.1");
clk_register_clkdev(clk[cspi3_ipg_gate], NULL, "imx27-cspi.2");
- clk_register_clkdev(clk[per3_gate], "per", "imx-fb.0");
- clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx-fb.0");
- clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx-fb.0");
+ clk_register_clkdev(clk[per3_gate], "per", "imx21-fb.0");
+ clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx21-fb.0");
+ clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
diff --git a/arch/arm/mach-imx/devices/devices-common.h b/arch/arm/mach-imx/devices/devices-common.h
index 7fa3ef7..c32279b 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -100,6 +100,7 @@ struct platform_device *__init imx_add_imxdi_rtc(
#include <linux/platform_data/video-imxfb.h>
struct imx_imx_fb_data {
+ const char *devid;
resource_size_t iobase;
resource_size_t iosize;
resource_size_t irq;
diff --git a/arch/arm/mach-imx/devices/platform-imx-fb.c b/arch/arm/mach-imx/devices/platform-imx-fb.c
index 4e6f857..abea28b 100644
--- a/arch/arm/mach-imx/devices/platform-imx-fb.c
+++ b/arch/arm/mach-imx/devices/platform-imx-fb.c
@@ -10,8 +10,9 @@
#include <mach/hardware.h>
#include "devices-common.h"
-#define imx_imx_fb_data_entry_single(soc, _size) \
+#define imx_imx_fb_data_entry_single(soc, _devid, _size) \
{ \
+ .devid = _devid, \
.iobase = soc ## _LCDC_BASE_ADDR, \
.iosize = _size, \
.irq = soc ## _INT_LCDC, \
@@ -19,22 +20,22 @@
#ifdef CONFIG_SOC_IMX1
const struct imx_imx_fb_data imx1_imx_fb_data __initconst - imx_imx_fb_data_entry_single(MX1, SZ_4K);
+ imx_imx_fb_data_entry_single(MX1, "imx1-fb", SZ_4K);
#endif /* ifdef CONFIG_SOC_IMX1 */
#ifdef CONFIG_SOC_IMX21
const struct imx_imx_fb_data imx21_imx_fb_data __initconst - imx_imx_fb_data_entry_single(MX21, SZ_4K);
+ imx_imx_fb_data_entry_single(MX21, "imx21-fb", SZ_4K);
#endif /* ifdef CONFIG_SOC_IMX21 */
#ifdef CONFIG_SOC_IMX25
const struct imx_imx_fb_data imx25_imx_fb_data __initconst - imx_imx_fb_data_entry_single(MX25, SZ_16K);
+ imx_imx_fb_data_entry_single(MX25, "imx21-fb", SZ_16K);
#endif /* ifdef CONFIG_SOC_IMX25 */
#ifdef CONFIG_SOC_IMX27
const struct imx_imx_fb_data imx27_imx_fb_data __initconst - imx_imx_fb_data_entry_single(MX27, SZ_4K);
+ imx_imx_fb_data_entry_single(MX27, "imx21-fb", SZ_4K);
#endif /* ifdef CONFIG_SOC_IMX27 */
struct platform_device *__init imx_add_imx_fb(
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 53ffdfc..64a39e7 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -33,7 +33,6 @@
#include <linux/math64.h>
#include <linux/platform_data/video-imxfb.h>
-#include <mach/hardware.h>
/*
* Complain if VAR is out of range.
@@ -53,8 +52,8 @@
#define LCDC_SIZE 0x04
#define SIZE_XMAX(x) ((((x) >> 4) & 0x3f) << 20)
-#define YMAX_MASK (cpu_is_mx1() ? 0x1ff : 0x3ff)
-#define SIZE_YMAX(y) ((y) & YMAX_MASK)
+#define YMAX_MASK_IMX1 0x1ff
+#define YMAX_MASK_IMX21 0x3ff
#define LCDC_VPW 0x08
#define VPW_VPW(x) ((x) & 0x3ff)
@@ -128,12 +127,18 @@ struct imxfb_rgb {
struct fb_bitfield transp;
};
+enum imxfb_type {
+ IMX1_FB,
+ IMX21_FB,
+};
+
struct imxfb_info {
struct platform_device *pdev;
void __iomem *regs;
struct clk *clk_ipg;
struct clk *clk_ahb;
struct clk *clk_per;
+ enum imxfb_type devtype;
/*
* These are the addresses we mapped
@@ -168,6 +173,24 @@ struct imxfb_info {
void (*backlight_power)(int);
};
+static struct platform_device_id imxfb_devtype[] = {
+ {
+ .name = "imx1-fb",
+ .driver_data = IMX1_FB,
+ }, {
+ .name = "imx21-fb",
+ .driver_data = IMX21_FB,
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(platform, imxfb_devtype);
+
+static inline int is_imx1_fb(struct imxfb_info *fbi)
+{
+ return fbi->devtype = IMX1_FB;
+}
+
#define IMX_NAME "IMX"
/*
@@ -366,7 +389,7 @@ static int imxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
break;
case 16:
default:
- if (cpu_is_mx1())
+ if (is_imx1_fb(fbi))
pcr |= PCR_BPIX_12;
else
pcr |= PCR_BPIX_16;
@@ -596,6 +619,7 @@ static struct fb_ops imxfb_ops = {
static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct imxfb_info *fbi = info->par;
+ u32 ymax_mask = is_imx1_fb(fbi) ? YMAX_MASK_IMX1 : YMAX_MASK_IMX21;
pr_debug("var: xres=%d hslen=%d lm=%d rm=%d\n",
var->xres, var->hsync_len,
@@ -617,7 +641,7 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
if (var->right_margin > 255)
printk(KERN_ERR "%s: invalid right_margin %d\n",
info->fix.id, var->right_margin);
- if (var->yres < 1 || var->yres > YMAX_MASK)
+ if (var->yres < 1 || var->yres > ymax_mask)
printk(KERN_ERR "%s: invalid yres %d\n",
info->fix.id, var->yres);
if (var->vsync_len > 100)
@@ -645,7 +669,7 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
VCR_V_WAIT_2(var->upper_margin),
fbi->regs + LCDC_VCR);
- writel(SIZE_XMAX(var->xres) | SIZE_YMAX(var->yres),
+ writel(SIZE_XMAX(var->xres) | (var->yres & ymax_mask),
fbi->regs + LCDC_SIZE);
writel(fbi->pcr, fbi->regs + LCDC_PCR);
@@ -765,6 +789,7 @@ static int __init imxfb_probe(struct platform_device *pdev)
return -ENOMEM;
fbi = info->par;
+ fbi->devtype = pdev->id_entry->driver_data;
if (!fb_mode)
fb_mode = pdata->mode[0].mode.name;
@@ -938,6 +963,7 @@ static struct platform_driver imxfb_driver = {
.driver = {
.name = DRIVER_NAME,
},
+ .id_table = imxfb_devtype,
};
static int imxfb_setup(void)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 18/34] video: mx3fb: remove unneeded mach/hardware.h inclusion
From: Shawn Guo @ 2012-09-17 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347860103-4141-1-git-send-email-shawn.guo@linaro.org>
The inclusion of mach/hardware.h is not used by the driver at all.
Remove it.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/mx3fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index 3b63ad8..fc50320 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -29,7 +29,6 @@
#include <linux/dma/ipu-dma.h>
#include <linux/platform_data/dma-imx.h>
-#include <mach/hardware.h>
#include <linux/platform_data/video-mx3fb.h>
#include <asm/io.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/34] dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
From: Shawn Guo @ 2012-09-17 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347860103-4141-1-git-send-email-shawn.guo@linaro.org>
The header ipu.h really belongs to dma subsystem rather than imx
platform. Rename it to ipu-dma.h and put it into include/linux/dma/.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-media@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
---
drivers/dma/ipu/ipu_idmac.c | 3 +--
drivers/dma/ipu/ipu_irq.c | 3 +--
drivers/media/video/mx3_camera.c | 2 +-
drivers/video/mx3fb.c | 2 +-
.../mach/ipu.h => include/linux/dma/ipu-dma.h | 6 +++---
5 files changed, 7 insertions(+), 9 deletions(-)
rename arch/arm/mach-imx/include/mach/ipu.h => include/linux/dma/ipu-dma.h (97%)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index c7573e5..6585537 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -22,8 +22,7 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/module.h>
-
-#include <mach/ipu.h>
+#include <linux/dma/ipu-dma.h>
#include "../dmaengine.h"
#include "ipu_intern.h"
diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index fa95bcc..a5ee37d 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -15,8 +15,7 @@
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/module.h>
-
-#include <mach/ipu.h>
+#include <linux/dma/ipu-dma.h>
#include "ipu_intern.h"
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 1481b0d..892cba5 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -17,6 +17,7 @@
#include <linux/vmalloc.h>
#include <linux/interrupt.h>
#include <linux/sched.h>
+#include <linux/dma/ipu-dma.h>
#include <media/v4l2-common.h>
#include <media/v4l2-dev.h>
@@ -24,7 +25,6 @@
#include <media/soc_camera.h>
#include <media/soc_mediabus.h>
-#include <mach/ipu.h>
#include <linux/platform_data/camera-mx3.h>
#include <linux/platform_data/dma-imx.h>
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d738108..3b63ad8 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -26,10 +26,10 @@
#include <linux/console.h>
#include <linux/clk.h>
#include <linux/mutex.h>
+#include <linux/dma/ipu-dma.h>
#include <linux/platform_data/dma-imx.h>
#include <mach/hardware.h>
-#include <mach/ipu.h>
#include <linux/platform_data/video-mx3fb.h>
#include <asm/io.h>
diff --git a/arch/arm/mach-imx/include/mach/ipu.h b/include/linux/dma/ipu-dma.h
similarity index 97%
rename from arch/arm/mach-imx/include/mach/ipu.h
rename to include/linux/dma/ipu-dma.h
index 539e559..1803111 100644
--- a/arch/arm/mach-imx/include/mach/ipu.h
+++ b/include/linux/dma/ipu-dma.h
@@ -9,8 +9,8 @@
* published by the Free Software Foundation.
*/
-#ifndef _IPU_H_
-#define _IPU_H_
+#ifndef __LINUX_DMA_IPU_DMA_H
+#define __LINUX_DMA_IPU_DMA_H
#include <linux/types.h>
#include <linux/dmaengine.h>
@@ -174,4 +174,4 @@ struct idmac_channel {
#define to_tx_desc(tx) container_of(tx, struct idmac_tx_desc, txd)
#define to_idmac_chan(c) container_of(c, struct idmac_channel, dma_chan)
-#endif
+#endif /* __LINUX_DMA_IPU_DMA_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 00/34] i.MX multi-platform support
From: Shawn Guo @ 2012-09-17 5:34 UTC (permalink / raw)
To: linux-arm-kernel
Cc: alsa-devel, linux-usb, Artem Bityutskiy, linux-fbdev,
Wim Van Sebroeck, linux-mtd, linux-i2c, Arnd Bergmann,
Florian Tobias Schandinat, Paulius Zaleckas, Chris Ball,
linux-media, linux-watchdog, rtc-linux, Sascha Hauer, Rob Herring,
Fabio Estevam, Vinod Koul, Greg Kroah-Hartman, Mark Brown,
linux-mmc, Wolfram Sang, Javier Martin, Andrew Morton <akpm@
The series enables multi-platform support for imx. Since the required
frameworks (clk, pwm) and spare_irq have already been adopted on imx,
the series is all about cleaning up mach/* headers. Along with the
changes, arch/arm/plat-mxc gets merged into arch/arm/mach-imx.
It's based on a bunch of branches (works from others), Rob's initial
multi-platform series, Arnd's platform-data and smp_ops (Marc's) and
imx 3.7 material (Sascha and myself).
It's available on branch below.
git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform
It's been tested on imx5 and imx6, and only compile-tested on imx2 and
imx3, so testing on imx2/3 are appreciated.
Subsystem maintainers,
I plan to send the whole series via arm-soc tree at the end of 3.7
merge window when all dependant bits hit mainline. Please have a
look at the patches you get copied and provide ACKs if the changes
are good. Thanks.
Shawn Guo (34):
ARM: imx: include board headers in the same folder
ASoC: mx27vis: retrieve gpio numbers from platform_data
ARM: imx: move iomux drivers and headers into mach-imx
ARM: imx: remove unnecessary inclusion from device-imx*.h
ARM: imx: move platform device code into mach-imx
ARM: imx: merge plat-mxc into mach-imx
ARM: imx: include common.h rather than mach/common.h
ARM: imx: ARM: imx: include cpuidle.h rather than mach/cpuidle.h
ARM: imx: include iim.h rather than mach/iim.h
ARM: imx: include iram.h rather than mach/iram.h
ARM: imx: include ulpi.h rather than mach/ulpi.h
media: mx1_camera: remove the driver
ARM: imx: remove mach/dma-mx1-mx2.h
dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
dma: imx-sdma: remove unneeded mach/hardware.h inclusion
ASoC: imx-ssi: remove unneeded mach/hardware.h inclusion
usb: ehci-mxc: remove unneeded mach/hardware.h inclusion
video: mx3fb: remove unneeded mach/hardware.h inclusion
watchdog: imx2_wdt: remove unneeded mach/hardware.h inclusion
i2c: imx: remove mach/hardware.h inclusion
mtd: mxc_nand: remove mach/hardware.h inclusion
rtc: mxc_rtc: remove mach/hardware.h inclusion
dma: imx-dma: use devm_kzalloc and devm_request_irq
dma: imx-dma: retrieve MEM and IRQ from resources
dma: imx-dma: remove mach/hardware.h inclusion
media: mx2_camera: remove dead code in mx2_camera_add_device
media: mx2_camera: use managed functions to clean up code
media: mx2_camera: remove mach/hardware.h inclusion
mmc: mxcmmc: remove mach/hardware.h inclusion
video: imxfb: remove mach/hardware.h inclusion
ARM: imx: move debug macros to include/debug
ARM: imx: include hardware.h rather than mach/hardware.h
ARM: imx: remove header file mach/irqs.h
ARM: imx: enable multi-platform build
.../devicetree/bindings/i2c/fsl-imx-i2c.txt | 4 +-
arch/arm/Kconfig | 15 +-
arch/arm/Kconfig.debug | 8 +
arch/arm/Makefile | 1 -
arch/arm/boot/dts/imx27.dtsi | 4 +-
arch/arm/boot/dts/imx51.dtsi | 4 +-
arch/arm/boot/dts/imx53.dtsi | 6 +-
arch/arm/boot/dts/imx6q.dtsi | 6 +-
.../mach/debug-macro.S => include/debug/imx.S} | 33 +-
arch/arm/{plat-mxc => mach-imx}/3ds_debugboard.c | 2 +-
.../include/mach => mach-imx}/3ds_debugboard.h | 0
arch/arm/mach-imx/Kconfig | 86 ++
arch/arm/mach-imx/Makefile | 23 +-
arch/arm/{plat-mxc => mach-imx}/avic.c | 5 +-
.../include/mach => mach-imx}/board-mx31lilly.h | 0
.../include/mach => mach-imx}/board-mx31lite.h | 0
.../include/mach => mach-imx}/board-mx31moboard.h | 0
.../include/mach => mach-imx}/board-pcm038.h | 0
arch/arm/mach-imx/clk-imx1.c | 15 +-
arch/arm/mach-imx/clk-imx21.c | 14 +-
arch/arm/mach-imx/clk-imx25.c | 26 +-
arch/arm/mach-imx/clk-imx27.c | 36 +-
arch/arm/mach-imx/clk-imx31.c | 21 +-
arch/arm/mach-imx/clk-imx35.c | 13 +-
arch/arm/mach-imx/clk-imx51-imx53.c | 15 +-
arch/arm/mach-imx/clk-imx6q.c | 3 +-
arch/arm/mach-imx/clk-pllv1.c | 4 +-
.../{plat-mxc/include/mach => mach-imx}/common.h | 0
arch/arm/mach-imx/cpu-imx25.c | 5 +-
arch/arm/mach-imx/cpu-imx27.c | 2 +-
arch/arm/mach-imx/cpu-imx31.c | 7 +-
arch/arm/mach-imx/cpu-imx35.c | 5 +-
arch/arm/mach-imx/cpu-imx5.c | 3 +-
arch/arm/{plat-mxc => mach-imx}/cpu.c | 3 +-
arch/arm/mach-imx/cpu_op-mx51.c | 3 +-
arch/arm/{plat-mxc => mach-imx}/cpufreq.c | 3 +-
arch/arm/{plat-mxc => mach-imx}/cpuidle.c | 0
.../{plat-mxc/include/mach => mach-imx}/cpuidle.h | 0
arch/arm/mach-imx/devices-imx1.h | 3 +-
arch/arm/mach-imx/devices-imx21.h | 3 +-
arch/arm/mach-imx/devices-imx25.h | 3 +-
arch/arm/mach-imx/devices-imx27.h | 3 +-
arch/arm/mach-imx/devices-imx31.h | 3 +-
arch/arm/mach-imx/devices-imx35.h | 3 +-
arch/arm/mach-imx/devices-imx50.h | 3 +-
arch/arm/mach-imx/devices-imx51.h | 3 +-
arch/arm/{plat-mxc => mach-imx}/devices/Kconfig | 3 -
arch/arm/{plat-mxc => mach-imx}/devices/Makefile | 3 +-
.../mach => mach-imx/devices}/devices-common.h | 19 +-
arch/arm/{plat-mxc => mach-imx/devices}/devices.c | 1 -
.../devices/platform-ahci-imx.c | 5 +-
.../{plat-mxc => mach-imx}/devices/platform-fec.c | 5 +-
.../devices/platform-flexcan.c | 4 +-
.../devices/platform-fsl-usb2-udc.c | 5 +-
.../devices/platform-gpio-mxc.c | 2 +-
.../devices/platform-gpio_keys.c | 5 +-
.../devices/platform-imx-dma.c | 23 +-
.../devices/platform-imx-fb.c | 16 +-
.../devices/platform-imx-i2c.c | 31 +-
.../devices/platform-imx-keypad.c | 4 +-
.../devices/platform-imx-ssi.c | 4 +-
.../devices/platform-imx-uart.c | 4 +-
.../devices/platform-imx2-wdt.c | 5 +-
.../devices/platform-imx21-hcd.c | 4 +-
.../devices/platform-imx_udc.c | 4 +-
.../devices/platform-imxdi_rtc.c | 5 +-
.../devices/platform-ipu-core.c | 5 +-
.../devices/platform-mx2-camera.c | 16 +-
.../devices/platform-mxc-ehci.c | 5 +-
.../devices/platform-mxc-mmc.c | 20 +-
.../devices/platform-mxc_nand.c | 25 +-
.../devices/platform-mxc_pwm.c | 4 +-
.../devices/platform-mxc_rnga.c | 4 +-
.../devices/platform-mxc_rtc.c | 13 +-
.../devices/platform-mxc_w1.c | 4 +-
.../devices/platform-pata_imx.c | 4 +-
.../devices/platform-sdhci-esdhc-imx.c | 5 +-
.../devices/platform-spi_imx.c | 4 +-
arch/arm/mach-imx/ehci-imx25.c | 4 +-
arch/arm/mach-imx/ehci-imx27.c | 4 +-
arch/arm/mach-imx/ehci-imx31.c | 4 +-
arch/arm/mach-imx/ehci-imx35.c | 4 +-
arch/arm/mach-imx/ehci-imx5.c | 4 +-
arch/arm/{plat-mxc => mach-imx}/epit.c | 6 +-
.../include/mach => mach-imx}/eukrea-baseboards.h | 0
arch/arm/mach-imx/eukrea_mbimx27-baseboard.c | 7 +-
arch/arm/mach-imx/eukrea_mbimxsd25-baseboard.c | 8 +-
arch/arm/mach-imx/eukrea_mbimxsd35-baseboard.c | 7 +-
arch/arm/mach-imx/eukrea_mbimxsd51-baseboard.c | 7 +-
.../{plat-mxc/include/mach => mach-imx}/hardware.h | 26 +-
arch/arm/mach-imx/hotplug.c | 3 +-
arch/arm/{plat-mxc/include/mach => mach-imx}/iim.h | 0
arch/arm/mach-imx/imx27-dt.c | 11 +-
arch/arm/mach-imx/imx31-dt.c | 5 +-
arch/arm/mach-imx/imx51-dt.c | 9 +-
arch/arm/mach-imx/include/mach/dma-mx1-mx2.h | 10 -
arch/arm/mach-imx/iomux-imx31.c | 5 +-
.../include/mach => mach-imx}/iomux-mx1.h | 2 +-
.../include/mach => mach-imx}/iomux-mx21.h | 4 +-
.../include/mach => mach-imx}/iomux-mx25.h | 2 +-
.../include/mach => mach-imx}/iomux-mx27.h | 4 +-
.../include/mach => mach-imx}/iomux-mx2x.h | 0
.../include/mach => mach-imx}/iomux-mx3.h | 0
.../include/mach => mach-imx}/iomux-mx35.h | 2 +-
.../include/mach => mach-imx}/iomux-mx50.h | 2 +-
.../include/mach => mach-imx}/iomux-mx51.h | 2 +-
arch/arm/{plat-mxc => mach-imx}/iomux-v1.c | 5 +-
.../{plat-mxc/include/mach => mach-imx}/iomux-v1.h | 0
arch/arm/{plat-mxc => mach-imx}/iomux-v3.c | 5 +-
.../{plat-mxc/include/mach => mach-imx}/iomux-v3.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/iram.h | 0
arch/arm/{plat-mxc => mach-imx}/iram_alloc.c | 3 +-
arch/arm/{plat-mxc => mach-imx}/irq-common.c | 0
arch/arm/{plat-mxc => mach-imx}/irq-common.h | 3 +
arch/arm/mach-imx/lluart.c | 3 +-
arch/arm/mach-imx/mach-apf9328.c | 7 +-
arch/arm/mach-imx/mach-armadillo5x0.c | 9 +-
arch/arm/mach-imx/mach-bug.c | 7 +-
arch/arm/mach-imx/mach-cpuimx27.c | 11 +-
arch/arm/mach-imx/mach-cpuimx35.c | 9 +-
arch/arm/mach-imx/mach-cpuimx51sd.c | 9 +-
arch/arm/mach-imx/mach-eukrea_cpuimx25.c | 10 +-
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 48 +-
arch/arm/mach-imx/mach-imx27ipcam.c | 6 +-
arch/arm/mach-imx/mach-imx27lite.c | 6 +-
arch/arm/mach-imx/mach-imx53.c | 11 +-
arch/arm/mach-imx/mach-imx6q.c | 6 +-
arch/arm/mach-imx/mach-kzm_arm11_01.c | 7 +-
arch/arm/mach-imx/mach-mx1ads.c | 7 +-
arch/arm/mach-imx/mach-mx21ads.c | 6 +-
arch/arm/mach-imx/mach-mx25_3ds.c | 8 +-
arch/arm/mach-imx/mach-mx27_3ds.c | 10 +-
arch/arm/mach-imx/mach-mx27ads.c | 6 +-
arch/arm/mach-imx/mach-mx31_3ds.c | 12 +-
arch/arm/mach-imx/mach-mx31ads.c | 5 +-
arch/arm/mach-imx/mach-mx31lilly.c | 11 +-
arch/arm/mach-imx/mach-mx31lite.c | 11 +-
arch/arm/mach-imx/mach-mx31moboard.c | 14 +-
arch/arm/mach-imx/mach-mx35_3ds.c | 8 +-
arch/arm/mach-imx/mach-mx50_rdp.c | 7 +-
arch/arm/mach-imx/mach-mx51_3ds.c | 9 +-
arch/arm/mach-imx/mach-mx51_babbage.c | 7 +-
arch/arm/mach-imx/mach-mxt_td60.c | 6 +-
arch/arm/mach-imx/mach-pca100.c | 8 +-
arch/arm/mach-imx/mach-pcm037.c | 8 +-
arch/arm/mach-imx/mach-pcm037_eet.c | 5 +-
arch/arm/mach-imx/mach-pcm038.c | 13 +-
arch/arm/mach-imx/mach-pcm043.c | 9 +-
arch/arm/mach-imx/mach-qong.c | 6 +-
arch/arm/mach-imx/mach-scb9328.c | 7 +-
arch/arm/mach-imx/mach-vpr200.c | 7 +-
arch/arm/mach-imx/mm-imx1.c | 9 +-
arch/arm/mach-imx/mm-imx21.c | 12 +-
arch/arm/mach-imx/mm-imx25.c | 10 +-
arch/arm/mach-imx/mm-imx27.c | 12 +-
arch/arm/mach-imx/mm-imx3.c | 9 +-
arch/arm/mach-imx/mm-imx5.c | 8 +-
arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 -
arch/arm/mach-imx/mx1-camera-fiq.S | 35 -
arch/arm/{plat-mxc/include/mach => mach-imx}/mx1.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx21.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx25.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx27.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx2x.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx31.h | 0
arch/arm/mach-imx/mx31lilly-db.c | 9 +-
arch/arm/mach-imx/mx31lite-db.c | 9 +-
arch/arm/mach-imx/mx31moboard-devboard.c | 9 +-
arch/arm/mach-imx/mx31moboard-marxbot.c | 9 +-
arch/arm/mach-imx/mx31moboard-smartbot.c | 11 +-
.../arm/{plat-mxc/include/mach => mach-imx}/mx35.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx3x.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx50.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx51.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx53.h | 0
.../arm/{plat-mxc/include/mach => mach-imx}/mx6q.h | 0
arch/arm/{plat-mxc/include/mach => mach-imx}/mxc.h | 0
arch/arm/mach-imx/pcm970-baseboard.c | 7 +-
arch/arm/mach-imx/platsmp.c | 5 +-
arch/arm/mach-imx/pm-imx27.c | 3 +-
arch/arm/mach-imx/pm-imx3.c | 7 +-
arch/arm/mach-imx/pm-imx5.c | 7 +-
arch/arm/mach-imx/pm-imx6q.c | 5 +-
arch/arm/{plat-mxc => mach-imx}/ssi-fiq-ksym.c | 0
arch/arm/{plat-mxc => mach-imx}/ssi-fiq.S | 0
arch/arm/{plat-mxc => mach-imx}/system.c | 5 +-
arch/arm/{plat-mxc => mach-imx}/time.c | 5 +-
arch/arm/{plat-mxc => mach-imx}/tzic.c | 6 +-
arch/arm/{plat-mxc => mach-imx}/ulpi.c | 2 +-
.../arm/{plat-mxc/include/mach => mach-imx}/ulpi.h | 0
arch/arm/plat-mxc/Kconfig | 89 --
arch/arm/plat-mxc/Makefile | 24 -
arch/arm/plat-mxc/devices/platform-mx1-camera.c | 42 -
arch/arm/plat-mxc/include/mach/irqs.h | 21 -
arch/arm/plat-mxc/include/mach/timex.h | 22 -
arch/arm/plat-mxc/include/mach/uncompress.h | 132 ---
drivers/dma/imx-dma.c | 137 +--
drivers/dma/imx-sdma.c | 1 -
drivers/dma/ipu/ipu_idmac.c | 3 +-
drivers/dma/ipu/ipu_irq.c | 3 +-
drivers/i2c/busses/i2c-imx.c | 40 +-
drivers/media/video/Kconfig | 12 -
drivers/media/video/Makefile | 1 -
drivers/media/video/mx1_camera.c | 889 --------------------
drivers/media/video/mx2_camera.c | 240 +++---
drivers/media/video/mx3_camera.c | 2 +-
drivers/mmc/host/mxcmmc.c | 31 +-
drivers/mtd/nand/mxc_nand.c | 86 +-
drivers/rtc/rtc-mxc.c | 34 +-
drivers/usb/host/ehci-mxc.c | 1 -
drivers/video/imxfb.c | 38 +-
drivers/video/mx3fb.c | 3 +-
drivers/watchdog/imx2_wdt.c | 1 -
.../mach/ipu.h => include/linux/dma/ipu-dma.h | 6 +-
include/linux/platform_data/asoc-mx27vis.h | 11 +
include/linux/platform_data/camera-mx1.h | 35 -
sound/soc/fsl/imx-pcm-fiq.c | 3 +-
sound/soc/fsl/imx-ssi.c | 1 -
sound/soc/fsl/mx27vis-aic32x4.c | 42 +-
219 files changed, 1149 insertions(+), 2170 deletions(-)
rename arch/arm/{plat-mxc/include/mach/debug-macro.S => include/debug/imx.S} (59%)
rename arch/arm/{plat-mxc => mach-imx}/3ds_debugboard.c (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/3ds_debugboard.h (100%)
rename arch/arm/{plat-mxc => mach-imx}/avic.c (98%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/board-mx31lilly.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/board-mx31lite.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/board-mx31moboard.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/board-pcm038.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/common.h (100%)
rename arch/arm/{plat-mxc => mach-imx}/cpu.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/cpufreq.c (99%)
rename arch/arm/{plat-mxc => mach-imx}/cpuidle.c (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/cpuidle.h (100%)
rename arch/arm/{plat-mxc => mach-imx}/devices/Kconfig (96%)
rename arch/arm/{plat-mxc => mach-imx}/devices/Makefile (96%)
rename arch/arm/{plat-mxc/include/mach => mach-imx/devices}/devices-common.h (96%)
rename arch/arm/{plat-mxc => mach-imx/devices}/devices.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-ahci-imx.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-fec.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-flexcan.c (96%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-fsl-usb2-udc.c (96%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-gpio-mxc.c (96%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-gpio_keys.c (94%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx-dma.c (63%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx-fb.c (79%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx-i2c.c (77%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx-keypad.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx-ssi.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx-uart.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx2-wdt.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx21-hcd.c (94%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imx_udc.c (96%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-imxdi_rtc.c (94%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-ipu-core.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mx2-camera.c (83%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc-ehci.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc-mmc.c (76%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc_nand.c (74%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc_pwm.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc_rnga.c (95%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc_rtc.c (77%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-mxc_w1.c (95%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-pata_imx.c (96%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-sdhci-esdhc-imx.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/devices/platform-spi_imx.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/epit.c (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/eukrea-baseboards.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/hardware.h (94%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iim.h (100%)
delete mode 100644 arch/arm/mach-imx/include/mach/dma-mx1-mx2.h
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx1.h (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx21.h (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx25.h (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx27.h (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx2x.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx3.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx35.h (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx50.h (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-mx51.h (99%)
rename arch/arm/{plat-mxc => mach-imx}/iomux-v1.c (98%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-v1.h (100%)
rename arch/arm/{plat-mxc => mach-imx}/iomux-v3.c (97%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iomux-v3.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/iram.h (100%)
rename arch/arm/{plat-mxc => mach-imx}/iram_alloc.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/irq-common.c (100%)
rename arch/arm/{plat-mxc => mach-imx}/irq-common.h (94%)
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx1.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx21.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx25.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx27.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx2x.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx31.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx35.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx3x.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx50.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx51.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx53.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mx6q.h (100%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/mxc.h (100%)
rename arch/arm/{plat-mxc => mach-imx}/ssi-fiq-ksym.c (100%)
rename arch/arm/{plat-mxc => mach-imx}/ssi-fiq.S (100%)
rename arch/arm/{plat-mxc => mach-imx}/system.c (97%)
rename arch/arm/{plat-mxc => mach-imx}/time.c (99%)
rename arch/arm/{plat-mxc => mach-imx}/tzic.c (98%)
rename arch/arm/{plat-mxc => mach-imx}/ulpi.c (99%)
rename arch/arm/{plat-mxc/include/mach => mach-imx}/ulpi.h (100%)
delete mode 100644 arch/arm/plat-mxc/Kconfig
delete mode 100644 arch/arm/plat-mxc/Makefile
delete mode 100644 arch/arm/plat-mxc/devices/platform-mx1-camera.c
delete mode 100644 arch/arm/plat-mxc/include/mach/irqs.h
delete mode 100644 arch/arm/plat-mxc/include/mach/timex.h
delete mode 100644 arch/arm/plat-mxc/include/mach/uncompress.h
delete mode 100644 drivers/media/video/mx1_camera.c
rename arch/arm/plat-mxc/include/mach/ipu.h => include/linux/dma/ipu-dma.h (97%)
create mode 100644 include/linux/platform_data/asoc-mx27vis.h
delete mode 100644 include/linux/platform_data/camera-mx1.h
--
1.7.9.5
^ permalink raw reply
* [PATCH 23/24] video: da8xx-fb: use __iomem pointers for MMIO
From: Arnd Bergmann @ 2012-09-14 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347658492-11608-1-git-send-email-arnd@arndb.de>
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/video/da8xx-fb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7ae9d53..113d43a 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -131,7 +131,7 @@
#define UPPER_MARGIN 32
#define LOWER_MARGIN 32
-static resource_size_t da8xx_fb_reg_base;
+static void __iomem *da8xx_fb_reg_base;
static struct resource *lcdc_regs;
static unsigned int lcd_revision;
static irq_handler_t lcdc_irq_handler;
@@ -951,7 +951,7 @@ static int __devexit fb_remove(struct platform_device *dev)
clk_disable(par->lcdc_clk);
clk_put(par->lcdc_clk);
framebuffer_release(info);
- iounmap((void __iomem *)da8xx_fb_reg_base);
+ iounmap(da8xx_fb_reg_base);
release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
}
@@ -1171,7 +1171,7 @@ static int __devinit fb_probe(struct platform_device *device)
if (!lcdc_regs)
return -EBUSY;
- da8xx_fb_reg_base = (resource_size_t)ioremap(lcdc_regs->start, len);
+ da8xx_fb_reg_base = ioremap(lcdc_regs->start, len);
if (!da8xx_fb_reg_base) {
ret = -EBUSY;
goto err_request_mem;
@@ -1392,7 +1392,7 @@ err_clk_put:
clk_put(fb_clk);
err_ioremap:
- iounmap((void __iomem *)da8xx_fb_reg_base);
+ iounmap(da8xx_fb_reg_base);
err_request_mem:
release_mem_region(lcdc_regs->start, len);
--
1.7.10
^ permalink raw reply related
* [PATCH v3] of: Add videomode helper
From: Steffen Trumtrar @ 2012-09-14 16:24 UTC (permalink / raw)
To: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Steffen Trumtrar,
Sascha Hauer, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Hi!
The original patch was done by Sascha Hauer. I reworked his v2 a "little" bit.
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (<min,typ,max>)
- functions to get display_mode or fb_videomode
Regards,
Steffen
.../devicetree/bindings/video/displaymode | 74 ++++++
drivers/of/Kconfig | 5 +
drivers/of/Makefile | 1 +
drivers/of/of_videomode.c | 236 ++++++++++++++++++++
include/linux/of_videomode.h | 56 +++++
5 files changed, 372 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/displaymode
create mode 100644 drivers/of/of_videomode.c
create mode 100644 include/linux/of_videomode.h
diff --git a/Documentation/devicetree/bindings/video/displaymode b/Documentation/devicetree/bindings/video/displaymode
new file mode 100644
index 0000000..990ca52
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/displaymode
@@ -0,0 +1,74 @@
+videomode bindings
+=========
+
+Required properties:
+ - hactive, vactive: Display resolution
+ - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
+ in pixels
+ vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
+ lines
+ - clock: displayclock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse is active high
+ - interlaced (bool): This is an interlaced mode
+ - doublescan (bool): This is a doublescan mode
+
+There are different ways of describing a display mode. The devicetree representation
+corresponds to the one commonly found in datasheets for displays.
+The description of the display and its mode is split in two parts: first the display
+properties like size in mm and (optionally) multiple subnodes with the supported modes.
+
+Example:
+
+ display@0 {
+ width-mm = <800>;
+ height-mm = <480>;
+ modes {
+ mode0: mode@0 {
+ /* 1920x1080p24 */
+ clock = <52000000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <25>;
+ hback-porch = <25>;
+ hsync-len = <25>;
+ vback-porch = <2>;
+ vfront-porch = <2>;
+ vsync-len = <2>;
+ hsync-active-high;
+ };
+ };
+ };
+
+Every property also supports the use of ranges, so the commonly used datasheet
+description with <min typ max>-tuples can be used.
+
+Example:
+
+ mode1: mode@1 {
+ /* 1920x1080p24 */
+ clock = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hsync-len = <0 44 60>;
+ hfront-porch = <80 88 95>;
+ hback-porch = <100 148 160>;
+ vfront-porch = <0 4 6>;
+ vback-porch = <0 36 50>;
+ vsync-len = <0 5 6>;
+ };
+
+The videomode can be linked to a connector via phandles. The connector has to
+support the display- and default-mode-property to link to and select a mode.
+
+Example:
+
+ hdmi@00120000 {
+ status = "okay";
+ display = <&benq>;
+ default-mode = <&mode1>;
+ };
+
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..a3acaa3 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -83,4 +83,9 @@ config OF_MTD
depends on MTD
def_bool y
+config OF_VIDEOMODE
+ def_bool y
+ help
+ helper to parse videomodes from the devicetree
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..80e6db3 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
+obj-$(CONFIG_OF_VIDEOMODE) += of_videomode.o
diff --git a/drivers/of/of_videomode.c b/drivers/of/of_videomode.c
new file mode 100644
index 0000000..217edf8
--- /dev/null
+++ b/drivers/of/of_videomode.c
@@ -0,0 +1,236 @@
+/*
+ * OF helpers for parsing display modes
+ *
+ * Copyright (c) 2012 Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix
+ * Copyright (c) 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/of.h>
+#include <linux/fb.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <drm/drmP.h>
+#include <drm/drm_crtc.h>
+#include <linux/of_videomode.h>
+
+/* FIXME */
+static u32 of_video_get_value(struct mode_property *prop)
+{
+ return (prop->min >= prop->typ) ? prop->min : prop->typ;
+}
+
+/* read property into new mode_property */
+static int of_video_parse_property(struct device_node *np, char *name,
+ struct mode_property *result)
+{
+ struct property *prop;
+ int length;
+ int cells;
+ int ret;
+
+ prop = of_find_property(np, name, &length);
+ if (!prop)
+ return -EINVAL;
+
+ cells = length / sizeof(u32);
+
+ memset(result, 0, sizeof(*result));
+
+ ret = of_property_read_u32_array(np, name, &result->min, cells);
+ of_video_get_value(result);
+ return ret;
+}
+
+int videomode_to_display_mode(struct display *disp, struct drm_display_mode *dmode, int index)
+{
+ struct videomode *vm;
+
+ memset(dmode, 0, sizeof(*dmode));
+
+ if (index > disp->num_modes)
+ return -EINVAL;
+ vm = disp->modes[index];
+
+ dmode->hdisplay = of_video_get_value(&vm->hactive);
+ dmode->hsync_start = of_video_get_value(&vm->hactive) + of_video_get_value(&vm->hfront_porch);
+ dmode->hsync_end = of_video_get_value(&vm->hactive) + of_video_get_value(&vm->hfront_porch)
+ + of_video_get_value(&vm->hsync_len);
+ dmode->htotal = of_video_get_value(&vm->hactive) + of_video_get_value(&vm->hfront_porch)
+ + of_video_get_value(&vm->hsync_len) + of_video_get_value(&vm->hback_porch);
+
+ dmode->vdisplay = of_video_get_value(&vm->vactive);
+ dmode->vsync_start = of_video_get_value(&vm->vactive) + of_video_get_value(&vm->vfront_porch);
+ dmode->vsync_end = of_video_get_value(&vm->vactive) + of_video_get_value(&vm->vfront_porch)
+ + of_video_get_value(&vm->vsync_len);
+ dmode->vtotal = of_video_get_value(&vm->vactive) + of_video_get_value(&vm->vfront_porch) +
+ of_video_get_value(&vm->vsync_len) + of_video_get_value(&vm->vback_porch);
+
+ dmode->width_mm = disp->width_mm;
+ dmode->height_mm = disp->height_mm;
+
+ dmode->clock = of_video_get_value(&vm->clock) / 1000;
+
+ if (vm->hah)
+ dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm->vah)
+ dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else
+ dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm->interlaced)
+ dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm->doublescan)
+ dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+
+ drm_mode_set_name(dmode);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_display_mode);
+
+int videomode_to_fb_mode(struct display *disp, struct fb_videomode *fbmode, int index)
+{
+ struct videomode *vm;
+ memset(fbmode, 0, sizeof(*fbmode));
+
+ vm = disp->modes[index];
+
+ fbmode->xres = of_video_get_value(&vm->hactive);
+ fbmode->left_margin = of_video_get_value(&vm->hback_porch);
+ fbmode->right_margin = of_video_get_value(&vm->hfront_porch);
+ fbmode->hsync_len = of_video_get_value(&vm->hsync_len);
+
+ fbmode->yres = of_video_get_value(&vm->vactive);
+ fbmode->upper_margin = of_video_get_value(&vm->vback_porch);
+ fbmode->lower_margin = of_video_get_value(&vm->vfront_porch);
+ fbmode->vsync_len = of_video_get_value(&vm->vsync_len);
+
+ fbmode->pixclock = KHZ2PICOS(of_video_get_value(&vm->clock) / 1000);
+
+ if (vm->hah)
+ fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm->vah)
+ fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->interlaced)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+ if (vm->doublescan)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(videomode_to_fb_mode);
+
+int of_get_video_mode(struct device_node *np, struct display *disp)
+{
+ struct device_node *display_np;
+ struct device_node *mode_np;
+ struct device_node *modes_np;
+ char *default_mode;
+
+ int ret = 0;
+
+ memset(disp, 0, sizeof(*disp));
+ disp->modes = kmalloc(sizeof(struct videomode*), GFP_KERNEL);
+ if (!np)
+ return -EINVAL;
+
+ display_np = of_parse_phandle(np, "display", 0);
+
+ if (!display_np)
+ return -EINVAL;
+
+ of_property_read_u32(display_np, "width-mm", &disp->width_mm);
+ of_property_read_u32(display_np, "height-mm", &disp->height_mm);
+
+ mode_np = of_parse_phandle(np, "default-mode", 0);
+
+ if (!mode_np)
+ mode_np = of_find_node_by_name(np, "mode");
+
+ if (!mode_np)
+ return -EINVAL;
+
+ default_mode = (char *)mode_np->full_name;
+
+ modes_np = of_find_node_by_name(np, "modes");
+ for_each_child_of_node(modes_np, mode_np) {
+ struct videomode *vm;
+ vm = kmalloc(sizeof(struct videomode), GFP_KERNEL);
+ disp->modes[disp->num_modes] = kmalloc(sizeof(struct videomode*), GFP_KERNEL);
+
+ ret |= of_video_parse_property(mode_np, "hback-porch", &vm->hback_porch);
+ ret |= of_video_parse_property(mode_np, "hfront-porch", &vm->hfront_porch);
+ ret |= of_video_parse_property(mode_np, "hactive", &vm->hactive);
+ ret |= of_video_parse_property(mode_np, "hsync-len", &vm->hsync_len);
+ ret |= of_video_parse_property(mode_np, "vback-porch", &vm->vback_porch);
+ ret |= of_video_parse_property(mode_np, "vfront-porch", &vm->vfront_porch);
+ ret |= of_video_parse_property(mode_np, "vactive", &vm->vactive);
+ ret |= of_video_parse_property(mode_np, "vsync-len", &vm->vsync_len);
+ ret |= of_video_parse_property(mode_np, "clock", &vm->clock);
+
+ if (ret)
+ return -EINVAL;
+
+ vm->hah = of_property_read_bool(mode_np, "hsync-active-high");
+ vm->vah = of_property_read_bool(mode_np, "vsync-active-high");
+ vm->interlaced = of_property_read_bool(mode_np, "interlaced");
+ vm->doublescan = of_property_read_bool(mode_np, "doublescan");
+
+ if (strcmp(default_mode,mode_np->full_name) = 0) {
+ printk("%s: default_node = %d\n", __func__, disp->num_modes);
+ disp->default_mode = disp->num_modes;
+ }
+
+ disp->modes[disp->num_modes] = vm;
+ disp->num_modes++;
+ }
+ of_node_put(display_np);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_video_mode);
+
+int of_video_mode_exists(struct device_node *np)
+{
+ struct device_node *display_np;
+ struct device_node *mode_np;
+
+ if (!np)
+ return -EINVAL;
+
+ display_np = of_parse_phandle(np, "display", 0);
+ if (!display_np)
+ return -EINVAL;
+ mode_np = of_parse_phandle(np, "default-mode", 0);
+ if (mode_np)
+ return 0;
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(of_video_mode_exists);
+
+int of_get_display_mode(struct device_node *np, struct drm_display_mode *dmode, int index)
+{
+ struct display disp;
+
+ of_get_video_mode(np, &disp);
+ if (index = OF_MODE_SELECTION)
+ index = disp.default_mode;
+ if (dmode)
+ videomode_to_display_mode(&disp, dmode, index);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_display_mode);
+
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fbmode, int index)
+{
+ struct display disp;
+
+ of_get_video_mode(np, &disp);
+
+ if (fbmode)
+ videomode_to_fb_mode(&disp, fbmode, index);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
diff --git a/include/linux/of_videomode.h b/include/linux/of_videomode.h
new file mode 100644
index 0000000..a6b4da0
--- /dev/null
+++ b/include/linux/of_videomode.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2012 Sascha Hauer <s.hauer@pengutronix.de>
+ * Copyright 2012 Steffen Trumtrar <s.trumtrar@pengutronix.de>
+ *
+ * OF helpers for videomodes.
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_VIDEOMODE_H
+#define __LINUX_OF_VIDEOMODE_H
+
+#define OF_MODE_SELECTION -1
+
+struct mode_property {
+ u32 min;
+ u32 typ;
+ u32 max;
+};
+
+struct display {
+ u32 width_mm;
+ u32 height_mm;
+ struct videomode **modes;
+ int default_mode;
+ int num_modes;
+};
+
+/* describe videomode in terms of hardware parameters */
+struct videomode {
+ struct mode_property hback_porch;
+ struct mode_property hfront_porch;
+ struct mode_property hactive;
+ struct mode_property hsync_len;
+
+ struct mode_property vback_porch;
+ struct mode_property vfront_porch;
+ struct mode_property vactive;
+ struct mode_property vsync_len;
+
+ struct mode_property clock;
+
+ bool hah;
+ bool vah;
+ bool interlaced;
+ bool doublescan;
+};
+
+int of_video_mode_exists(struct device_node *np);
+int videomode_to_display_mode(struct display *disp, struct drm_display_mode *dmode, int index);
+int videomode_to_fb_mode(struct display *disp, struct fb_videomode *fbmode, int index);
+int of_get_video_mode(struct device_node *np, struct display *disp);
+int of_video_mode_exists(struct device_node *np);
+int of_get_display_mode(struct device_node *np, struct drm_display_mode *dmode, int index);
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fbmode, int index);
+#endif /* __LINUX_OF_VIDEOMODE_H */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 10:57 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <505305F2.4000602@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]
On Fri, 2012-09-14 at 15:54 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote:
> > On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
> >> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> >
> >>> This series prepares the low level DISPC driver(dispc.c) to configure writeback
> >>> registers. The aim is to reuse most of the code as most of its registers are
> >>> like overlay or manager registers, and are configured in the same way in most
> >>> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
> >>
> >> I'm not sure if the renaming causes more confusion than clarity... It
> >> kinda creates a mishmash of ovl/plane names, and the term "plane"
> >> doesn't really sound like it's a base for both overlays and wb. Could we
> >> consider the wb as a special case, and keep the ovl name for most of the
> >> things and have "wb" used for wb specific things?
> >
> > And while WB is a combination of overlays and ovl managers, do you think
> > it'd be difficult to consider WB as a special, extended overlay? So just
> > call it an overlay, and consider it as an overlay with special features,
> > at least inside dispc.c. We probably need to have it as a totally
> > different entity from user's point of view (i.e. the list of overlays
> > wouldn't return WB, etc).
>
> Yes, we could do that within dispc.c, we would still need some manager
> like functions which set GO or ENABLE. But apart from that it should be
> okay.
Yep, I was going through the WB registers, and to me it looks like 99%
of them are like overlay regs. Then there are a few bits like GO which
are special.
> I think for dispc.c in general, for future, it might be a good idea to
> represent each piece of HW(like scalar or color converter, or a timing
Scal_e_r! ;)
> FSM) as a little function/module, and construct
> overlay/writeback/manager out of those, it might be cleaner. However,
> this may be an overkill, and not needed much if there aren't any new
> blocks comprising of these little blocks.
I agree. In the minimum we should try to somehow group functions related
to certain block, perhaps with name prefixes etc. I think it'll also
help understanding the code.
We probably currently have functions that touch multiple different
blocks. Those funcs should be split to handle only one of the blocks.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 10:53 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50530367.5030303@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
On Fri, 2012-09-14 at 15:43 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote:
> I initially kept all of this the same, but I changed my mind at some
> point, not totally sure why. Even if we stick to the dispc_ovl_* names,
> we would still need to create q common function which dispc_ovl_setup()
> and dispc_wb_setup() could call. I called this dispc_plane_setup(), and
> then it felt weird to call everything else ovl specifuic, hence renamed
> all of them to dispc_plane_*.
>
> Could you suggest a better name than dispc_plane_setup?
Well... dispc_ovl_setup_common?
The function is also quite big, with huge number of arguments. Makes me
wonder if we could split it up to some sensible parts. Would it be
possible to have functions to setup, say, input related parameters
(base-address, pix format, etc.), output related parameters (ovl
position, ...).
Well, it could just make it more confusing, as some things are shared
between input and output, like scaling related things. But just an idea.
>
> >
> >> functions. The next few patches change how overlay caps are used within the
> >> dispc functions, this helps reusing more functions between overlays and
> >
> > I dislike this a bit, I think dispc driver should know what HW it has,
> > you shouldn't need to pass caps to it. So I'd prefer the dispc driver to
> > to have this information in dispc_features. I believe all OVL_CAPS
> > should be there, and then exported to other drivers via some means. I
> > guess this means could for now be just initializing ovl->caps with data
> > from dispc.c.
>
> Currently, we pass the plane id to these low level functions, it
> extracts out the ovl struct usingthe plane id, and checks the ovl caps.
>
> What I'm doing now is just passing the caps directly to these low level
> functions. So that I don't need to have complicated checks in every
> function to extract caps between overlays or writeback.
Yep, I see. It's ok.
My main dislike is the use of omap_dss_get_overlay() in dispc.c. I'd
like dispc.c to be self-contained, so what I mean is that instead of
initializing the caps in dss_features.c, and calling the above function
in dispc.c, we should have a dispc.c internal table for dispc's HW,
which would contain the caps and other necessary information.
But that's not really related to this series.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Archit Taneja @ 2012-09-14 10:36 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347612392.2559.54.camel@deskari>
On Friday 14 September 2012 02:16 PM, Tomi Valkeinen wrote:
> On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
>> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>
>>> This series prepares the low level DISPC driver(dispc.c) to configure writeback
>>> registers. The aim is to reuse most of the code as most of its registers are
>>> like overlay or manager registers, and are configured in the same way in most
>>> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
>>
>> I'm not sure if the renaming causes more confusion than clarity... It
>> kinda creates a mishmash of ovl/plane names, and the term "plane"
>> doesn't really sound like it's a base for both overlays and wb. Could we
>> consider the wb as a special case, and keep the ovl name for most of the
>> things and have "wb" used for wb specific things?
>
> And while WB is a combination of overlays and ovl managers, do you think
> it'd be difficult to consider WB as a special, extended overlay? So just
> call it an overlay, and consider it as an overlay with special features,
> at least inside dispc.c. We probably need to have it as a totally
> different entity from user's point of view (i.e. the list of overlays
> wouldn't return WB, etc).
Yes, we could do that within dispc.c, we would still need some manager
like functions which set GO or ENABLE. But apart from that it should be
okay.
I think for dispc.c in general, for future, it might be a good idea to
represent each piece of HW(like scalar or color converter, or a timing
FSM) as a little function/module, and construct
overlay/writeback/manager out of those, it might be cleaner. However,
this may be an overkill, and not needed much if there aren't any new
blocks comprising of these little blocks.
Archit
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Archit Taneja @ 2012-09-14 10:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347611263.2559.44.camel@deskari>
On Friday 14 September 2012 01:57 PM, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>> DSS HW on OMAP4 onwards supports a new pipeline called writeback. Unlike other
>> pipelines(called overlays in OMAPDSS), writeback takes pixel data from an
>> overlay output or a overlay manager output and writes it back into a specified
>> address in memory.
>>
>> writeback pipeline allows us to take benefit of the hardware processing
>> available inside the DISPC like color space conversion, rescaling, compositing
>> etc and do either a) perform memory-to-memory transfer with data processing,
>> b) capture a displayed frame. The former is known as memory to memory mode of
>> the writeback pipeline, and the latter is known as capture mode. More details
>> about writeback can be found in the Display Subsystem section of the OMAP4/5 TRMs.
>>
>> witeback has properties of both overlays and overlay managers. It is like an
>> overlay as it has programmable base addresses and contains blocks like scalar,
>
> You consistently use the term "scalar" in the patches, but I believe the
> correct term is "scaler".
Yes, my bad, I'll fix this.
>
>> color conversion unit, truncation unit, DISPC DMA FIFO. It is like a manager as
>> enabling it immediately starts transfer to the memory, and it has a GO bit to use
>> a new writeback configuration.
>>
>> This series prepares the low level DISPC driver(dispc.c) to configure writeback
>> registers. The aim is to reuse most of the code as most of its registers are
>> like overlay or manager registers, and are configured in the same way in most
>> cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
>
> I'm not sure if the renaming causes more confusion than clarity... It
> kinda creates a mishmash of ovl/plane names, and the term "plane"
> doesn't really sound like it's a base for both overlays and wb. Could we
> consider the wb as a special case, and keep the ovl name for most of the
> things and have "wb" used for wb specific things?
I initially kept all of this the same, but I changed my mind at some
point, not totally sure why. Even if we stick to the dispc_ovl_* names,
we would still need to create q common function which dispc_ovl_setup()
and dispc_wb_setup() could call. I called this dispc_plane_setup(), and
then it felt weird to call everything else ovl specifuic, hence renamed
all of them to dispc_plane_*.
Could you suggest a better name than dispc_plane_setup?
>
>> functions. The next few patches change how overlay caps are used within the
>> dispc functions, this helps reusing more functions between overlays and
>
> I dislike this a bit, I think dispc driver should know what HW it has,
> you shouldn't need to pass caps to it. So I'd prefer the dispc driver to
> to have this information in dispc_features. I believe all OVL_CAPS
> should be there, and then exported to other drivers via some means. I
> guess this means could for now be just initializing ovl->caps with data
> from dispc.c.
Currently, we pass the plane id to these low level functions, it
extracts out the ovl struct usingthe plane id, and checks the ovl caps.
What I'm doing now is just passing the caps directly to these low level
functions. So that I don't need to have complicated checks in every
function to extract caps between overlays or writeback.
Archit
>
> Tomi
>
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Tomi Valkeinen @ 2012-09-14 10:18 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <505300FC.3020706@ti.com>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Fri, 2012-09-14 at 15:33 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
> > I see your reasoning. I'm a bit reluctant to add a new clock term to
> > omapdss. You can't (probably) find it in the TRM. Does the TRM talk
> > about clocks with regard to WB?
>
> Yes, you can't find the word pixel clock linked to WB in the TRM.
Is there some other term for the clock related to WB?
> Yes, we could do that. I can check if zero leads to some bad results, or
> we could just bypass the scaler clock stuff if the pixel clock is 0.
I think 0 value would make more sense than a dummy 1. 1 is still a valid
clock, and it could go unnoticed in some other code paths that would use
the function to get the clock.
Of course, the scaler check function could internally check if the pck
is 0, and then use 1 in its calculations, if that makes the function
simpler.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Archit Taneja @ 2012-09-14 10:15 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347616145.2559.70.camel@deskari>
On Friday 14 September 2012 03:19 PM, Tomi Valkeinen wrote:
> On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
>> On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
>>> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>>>> Scaling calculations for an overlay are done by comparing pixel clock of the
>>>> connected overlay manager and the core clock of DISPC. The pixel clock is the
>>>> output rate of the scalar. The scalar block needs to provide pixels at this rate
>>>> since the manager is connected to a panel, which has real time constraints.
>>>>
>>>> In the case of writeback in memory to memory mode, the output of the scalar
>>>> blocks aren't connected to a display, and hence there isn't a pixel clock which
>>>> causes downscaling limitations.
>>>>
>>>> Make the input to scaling calculations a bit more generic by passing the scalar
>>>> output rate rather than passing pixel clock of the overlay manager connected to
>>>> the pipeline, as we now have use cases where the scalar's output may not go to
>>>> a manager connected to a panel.
>>>
>>> Pixel clock is the rate at which pixels are processed. I don't see it
>>> only meaning a clock that's related to actual video signal going out of
>>> OMAP. So if in normal case the scaler outputs pixels at the rate of
>>> pixel clock, we can call it pixel clock with WB's case also, instead of
>>> renaming it to output clock.
>>
>> Pixel clock, in OMAP DSS terms, is the rate at which the video port of
>> an overlay manager provides pixels to an output. It is a fixed rate at
>> which the scaler needs to push out data.
>>
>> If we stick to this terminology of pixel clock, I don't think it applies
>> to writeback. As far as I see it, there is no specific rate at which the
>> scaler outputs data, it adjusts itself based on how much scaling is
>> done, and at the rate we can get/push data to the interconnect. That's
>> why I didn't want to call it pixel clock. Because, that sounds a lot
>> like a fixed rate at which pixels need to be output.
>
> I see your reasoning. I'm a bit reluctant to add a new clock term to
> omapdss. You can't (probably) find it in the TRM. Does the TRM talk
> about clocks with regard to WB?
Yes, you can't find the word pixel clock linked to WB in the TRM.
>
> I do think pixel clock can be used as well here. While normally used for
> output, it's just a clock used for pixels, and at each tick we process
> one pixel, which is exactly what happens with WB also.
>
> Also, if I understood right, this pixel clock is not even used for WB,
> and in a later patch you just use a dummy value of 1 for the clock for
> WB. So even if pixel clock would not be the best name, would it make
> sense to use the name of pixel clock, but return 0 as the pck for WB,
> implying that pck is not valid/does not exist, and the scaling
> restrictions can be skipped for that?
Yes, we could do that. I can check if zero leads to some bad results, or
we could just bypass the scaler clock stuff if the pixel clock is 0.
Archit
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Tomi Valkeinen @ 2012-09-14 9:49 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <5052F547.9090102@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2782 bytes --]
On Fri, 2012-09-14 at 14:43 +0530, Archit Taneja wrote:
> On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
> > On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> >> Scaling calculations for an overlay are done by comparing pixel clock of the
> >> connected overlay manager and the core clock of DISPC. The pixel clock is the
> >> output rate of the scalar. The scalar block needs to provide pixels at this rate
> >> since the manager is connected to a panel, which has real time constraints.
> >>
> >> In the case of writeback in memory to memory mode, the output of the scalar
> >> blocks aren't connected to a display, and hence there isn't a pixel clock which
> >> causes downscaling limitations.
> >>
> >> Make the input to scaling calculations a bit more generic by passing the scalar
> >> output rate rather than passing pixel clock of the overlay manager connected to
> >> the pipeline, as we now have use cases where the scalar's output may not go to
> >> a manager connected to a panel.
> >
> > Pixel clock is the rate at which pixels are processed. I don't see it
> > only meaning a clock that's related to actual video signal going out of
> > OMAP. So if in normal case the scaler outputs pixels at the rate of
> > pixel clock, we can call it pixel clock with WB's case also, instead of
> > renaming it to output clock.
>
> Pixel clock, in OMAP DSS terms, is the rate at which the video port of
> an overlay manager provides pixels to an output. It is a fixed rate at
> which the scaler needs to push out data.
>
> If we stick to this terminology of pixel clock, I don't think it applies
> to writeback. As far as I see it, there is no specific rate at which the
> scaler outputs data, it adjusts itself based on how much scaling is
> done, and at the rate we can get/push data to the interconnect. That's
> why I didn't want to call it pixel clock. Because, that sounds a lot
> like a fixed rate at which pixels need to be output.
I see your reasoning. I'm a bit reluctant to add a new clock term to
omapdss. You can't (probably) find it in the TRM. Does the TRM talk
about clocks with regard to WB?
I do think pixel clock can be used as well here. While normally used for
output, it's just a clock used for pixels, and at each tick we process
one pixel, which is exactly what happens with WB also.
Also, if I understood right, this pixel clock is not even used for WB,
and in a later patch you just use a dummy value of 1 for the clock for
WB. So even if pixel clock would not be the best name, would it make
sense to use the name of pixel clock, but return 0 as the pck for WB,
implying that pck is not valid/does not exist, and the scaling
restrictions can be skipped for that?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Archit Taneja @ 2012-09-14 9:25 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347612788.2559.57.camel@deskari>
On Friday 14 September 2012 02:23 PM, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
>> Scaling calculations for an overlay are done by comparing pixel clock of the
>> connected overlay manager and the core clock of DISPC. The pixel clock is the
>> output rate of the scalar. The scalar block needs to provide pixels at this rate
>> since the manager is connected to a panel, which has real time constraints.
>>
>> In the case of writeback in memory to memory mode, the output of the scalar
>> blocks aren't connected to a display, and hence there isn't a pixel clock which
>> causes downscaling limitations.
>>
>> Make the input to scaling calculations a bit more generic by passing the scalar
>> output rate rather than passing pixel clock of the overlay manager connected to
>> the pipeline, as we now have use cases where the scalar's output may not go to
>> a manager connected to a panel.
>
> Pixel clock is the rate at which pixels are processed. I don't see it
> only meaning a clock that's related to actual video signal going out of
> OMAP. So if in normal case the scaler outputs pixels at the rate of
> pixel clock, we can call it pixel clock with WB's case also, instead of
> renaming it to output clock.
Pixel clock, in OMAP DSS terms, is the rate at which the video port of
an overlay manager provides pixels to an output. It is a fixed rate at
which the scaler needs to push out data.
If we stick to this terminology of pixel clock, I don't think it applies
to writeback. As far as I see it, there is no specific rate at which the
scaler outputs data, it adjusts itself based on how much scaling is
done, and at the rate we can get/push data to the interconnect. That's
why I didn't want to call it pixel clock. Because, that sounds a lot
like a fixed rate at which pixels need to be output.
>
> Or was there some other reason for the rename, that I missed?
The main aim of this patch was to pass pixel clock rate/or output rate
as an argument to scaler functions, rather than passing the overlay
manager's channel id to calculate this rate. I can rename it to pixel
clock if that seems better.
Archit
^ permalink raw reply
* Re: [PATCH 21/21] OMAPDSS: DISPC: Configure color conversion coefficients for writeback
From: Tomi Valkeinen @ 2012-09-14 9:07 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347538505-25359-22-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]
On Thu, 2012-09-13 at 17:45 +0530, Archit Taneja wrote:
> Writeback pipeline receives RGB data from one of the overlays or one of the
> overlay managers. If the target color mode is YUV422 or NV12, we need to convert
> the RGB pixels to YUV. The scalar in WB then converts it to the target color
> mode.
>
> Hence, the color conversion coefficients that need to be programmed are the ones
> which convert a RGB24 pixel to YUV444. Program these coefficients for writeback
> pipeline.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 1623c9b..5811a18 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -681,20 +681,30 @@ static void dispc_plane_set_scale_coef(enum omap_plane plane, int fir_hinc,
> static void _dispc_setup_color_conv_coef(void)
> {
> int i;
> + int num_ovl = dss_feat_get_num_ovls();
> + int num_wb = dss_feat_get_num_wbs();
> +
> const struct color_conv_coef {
> int ry, rcr, rcb, gy, gcr, gcb, by, bcr, bcb;
> int full_range;
> - } ctbl_bt601_5 = {
> - 298, 409, 0, 298, -208, -100, 298, 0, 517, 0,
> + } ctbl_bt601_5[2] = {
> + { 298, 409, 0, 298, -208, -100, 298, 0, 517, 0, },
> + { 66, 112, -38, 129, -94, -74, 25, -18, 112, 0, },
> };
>
> const struct color_conv_coef *ct;
>
> #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
> +#define YUVTORGB 0
> +#define RGBTOYUV 1
>
> - ct = &ctbl_bt601_5;
> + ct = &ctbl_bt601_5[YUVTORGB];
> +
> + for (i = 1; i < num_ovl + num_wb; i++) {
> +
> + if (i >= num_ovl)
> + ct = &ctbl_bt601_5[RGBTOYUV];
>
> - for (i = 1; i < dss_feat_get_num_ovls(); i++) {
> dispc_write_reg(DISPC_OVL_CONV_COEF(i, 0),
> CVAL(ct->rcr, ct->ry));
> dispc_write_reg(DISPC_OVL_CONV_COEF(i, 1),
This looks a bit funny. I'd suggest to take the actual register writes
to a separate function, and have a separate tables for ovls and wb, and
have two for loops, first for ovls and then for wbs.
Btw, I wonder if we could consider WB as a single special entity, i.e.
no need for "num_wbs" or such. I know things may change in the future
HW, but I got the impression that adding overlays to DSS is costly, and
single WB is enough.
Then again, I'm not sure if handling only single WB would simplify much.
If you think it's no issue to have support for multiple WBs, perhaps we
can have it, just in case.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 09/21] OMAPDSS: DISPC: Calculate scaling limits in a more generic way
From: Tomi Valkeinen @ 2012-09-14 8:53 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347538505-25359-10-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> Scaling calculations for an overlay are done by comparing pixel clock of the
> connected overlay manager and the core clock of DISPC. The pixel clock is the
> output rate of the scalar. The scalar block needs to provide pixels at this rate
> since the manager is connected to a panel, which has real time constraints.
>
> In the case of writeback in memory to memory mode, the output of the scalar
> blocks aren't connected to a display, and hence there isn't a pixel clock which
> causes downscaling limitations.
>
> Make the input to scaling calculations a bit more generic by passing the scalar
> output rate rather than passing pixel clock of the overlay manager connected to
> the pipeline, as we now have use cases where the scalar's output may not go to
> a manager connected to a panel.
Pixel clock is the rate at which pixels are processed. I don't see it
only meaning a clock that's related to actual video signal going out of
OMAP. So if in normal case the scaler outputs pixels at the rate of
pixel clock, we can call it pixel clock with WB's case also, instead of
renaming it to output clock.
Or was there some other reason for the rename, that I missed?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] OMAPDSS: DISPC changes for writeback pipeline
From: Tomi Valkeinen @ 2012-09-14 8:46 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1347611263.2559.44.camel@deskari>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
On Fri, 2012-09-14 at 11:27 +0300, Tomi Valkeinen wrote:
> On Thu, 2012-09-13 at 17:44 +0530, Archit Taneja wrote:
> > This series prepares the low level DISPC driver(dispc.c) to configure writeback
> > registers. The aim is to reuse most of the code as most of its registers are
> > like overlay or manager registers, and are configured in the same way in most
> > cases. The first few patches rename dispc_ovl_* functions to dispc_plane_*
>
> I'm not sure if the renaming causes more confusion than clarity... It
> kinda creates a mishmash of ovl/plane names, and the term "plane"
> doesn't really sound like it's a base for both overlays and wb. Could we
> consider the wb as a special case, and keep the ovl name for most of the
> things and have "wb" used for wb specific things?
And while WB is a combination of overlays and ovl managers, do you think
it'd be difficult to consider WB as a special, extended overlay? So just
call it an overlay, and consider it as an overlay with special features,
at least inside dispc.c. We probably need to have it as a totally
different entity from user's point of view (i.e. the list of overlays
wouldn't return WB, etc).
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox