* Re: [PATCH 2/5] drivers/video/bfin-t350mcqb-fb.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 16:18 UTC (permalink / raw)
To: Mike Frysinger
Cc: Florian Tobias Schandinat, kernel-janitors, linux-fbdev,
linux-kernel
In-Reply-To: <CAMjpGUdo0SavFWR_tk50_6nZMsJmxYO5BxH9Fp=UTw5sW-0+Rw@mail.gmail.com>
On Tue, Jul 31, 2012 at 3:57 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tue, Jul 31, 2012 at 9:54 AM, Damien Cassou <damien.cassou@lifl.fr> wrote:
>> The various devm_ functions allocate memory that is released when a driver
>> detaches. This patch uses these functions for data that is allocated in
>> the probe function of a platform device and is only freed in the remove
>> function.
>
> Acked-by: Mike Frysinger <vapier@gentoo.org>
This whole patch is invalid, because of this part:
- info->fb_buffer = dma_alloc_coherent(NULL, fbinfo->fix.smem_len +
- ACTIVE_VIDEO_MEM_OFFSET,
- &info->dma_handle, GFP_KERNEL);
+ info->fb_buffer = dmam_alloc_coherent(&pdev->dev, NULL,
+ fbinfo->fix.smem_len +
+ ACTIVE_VIDEO_MEM_OFFSET,
+ &info->dma_handle, GFP_KERNEL);
dmam_alloc_coherent() is called with 5 arguments but only accepts 4.
Please ignore this whole patch altogether.
I am sorry about that.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
^ permalink raw reply
* Re: [PATCH 4/5] drivers/video/da8xx-fb.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 16:01 UTC (permalink / raw)
To: Sachin Kamat
Cc: Florian Tobias Schandinat, kernel-janitors, linux-fbdev,
linux-kernel
In-Reply-To: <CAK9yfHxy4DGCwZjDCdc3A-a3oKoMGQruDMhfq0uR+2+7nfFHoA@mail.gmail.com>
The whole patch is incorrect because of:
On Tue, Jul 31, 2012 at 5:47 PM, Sachin Kamat <sachin.kamat@linaro.org> wrote:
>> - ret = request_irq(par->irq, lcdc_irq_handler, 0,
>> - DRIVER_NAME, par);
>> + ret = devm_request_irq(&device->dev, par->irq, lcdc_irq_handler, 0,
>> + DRIVER_NAME, par);
The following message explains why this is problematic:
http://marc.info/?l=kernel-janitors&m\x134374464625591&w=2
Please ignore this whole patch altogether.
Sorry about that.
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
^ permalink raw reply
* Re: [PATCH 4/5] drivers/video/da8xx-fb.c: use devm_ functions
From: Sachin Kamat @ 2012-07-31 15:59 UTC (permalink / raw)
To: Damien Cassou
Cc: Florian Tobias Schandinat, kernel-janitors, linux-fbdev,
linux-kernel
In-Reply-To: <1343742860-16213-3-git-send-email-damien.cassou@lifl.fr>
On 31 July 2012 19:24, Damien Cassou <damien.cassou@lifl.fr> wrote:
> From: Damien Cassou <damien.cassou@lifl.fr>
>
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
>
> Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
>
> ---
> drivers/video/da8xx-fb.c | 34 ++++++++--------------------------
> 1 file changed, 8 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
> index 7ae9d53..0429431 100644
> --- a/drivers/video/da8xx-fb.c
> +++ b/drivers/video/da8xx-fb.c
> @@ -947,12 +947,9 @@ static int __devexit fb_remove(struct platform_device *dev)
> par->p_palette_base);
> dma_free_coherent(NULL, par->vram_size, par->vram_virt,
> par->vram_phys);
> - free_irq(par->irq, par);
> clk_disable(par->lcdc_clk);
> clk_put(par->lcdc_clk);
> framebuffer_release(info);
> - iounmap((void __iomem *)da8xx_fb_reg_base);
> - release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
>
> }
> return 0;
> @@ -1149,7 +1146,7 @@ static int __devinit fb_probe(struct platform_device *device)
> struct fb_info *da8xx_fb_info;
> struct clk *fb_clk = NULL;
> struct da8xx_fb_par *par;
> - resource_size_t len;
> +
> int ret, i;
> unsigned long ulcm;
>
> @@ -1159,29 +1156,20 @@ static int __devinit fb_probe(struct platform_device *device)
> }
>
> lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
> - if (!lcdc_regs) {
> - dev_err(&device->dev,
> - "Can not get memory resource for LCD controller\n");
> - return -ENOENT;
> - }
> -
> - len = resource_size(lcdc_regs);
>
> - lcdc_regs = request_mem_region(lcdc_regs->start, len, lcdc_regs->name);
> - if (!lcdc_regs)
> - return -EBUSY;
> -
> - da8xx_fb_reg_base = (resource_size_t)ioremap(lcdc_regs->start, len);
> + da8xx_fb_reg_base > + (resource_size_t) devm_request_and_ioremap(&device->dev,
> + lcdc_regs);
> if (!da8xx_fb_reg_base) {
> ret = -EBUSY;
> - goto err_request_mem;
> + return ret;
You can directly do
return -EBUSY;
and remove the braces.
> }
>
> fb_clk = clk_get(&device->dev, NULL);
> if (IS_ERR(fb_clk)) {
> dev_err(&device->dev, "Can not get device clock\n");
> ret = -ENODEV;
> - goto err_ioremap;
> + return ret;
ditto
> }
> ret = clk_enable(fb_clk);
> if (ret)
> @@ -1359,8 +1347,8 @@ static int __devinit fb_probe(struct platform_device *device)
> else
> lcdc_irq_handler = lcdc_irq_handler_rev02;
>
> - ret = request_irq(par->irq, lcdc_irq_handler, 0,
> - DRIVER_NAME, par);
> + ret = devm_request_irq(&device->dev, par->irq, lcdc_irq_handler, 0,
> + DRIVER_NAME, par);
> if (ret)
> goto irq_freq;
> return 0;
> @@ -1391,12 +1379,6 @@ err_clk_disable:
> err_clk_put:
> clk_put(fb_clk);
>
> -err_ioremap:
> - iounmap((void __iomem *)da8xx_fb_reg_base);
> -
> -err_request_mem:
> - release_mem_region(lcdc_regs->start, len);
> -
> return ret;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-07-31 15:39 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Alex Courbot, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120731143235.GA21126-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Tue, Jul 31, 2012 at 04:32:35PM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 03:26:07PM +0100, Mark Brown wrote:
> > This is framework code - it doesn't have much option. Disabling HOTPLUG
> > is totally reasonable on space constrained systems, there's no reason
> > for the code to break things for people.
> Still if you use this code and disable HOTPLUG, then you shouldn't be
> using modules either. I mean there is no way you can write a driver that
Of course.
> can gracefully handle its platform data being discarded.
Sure there is - take a copy of the platform data in probe().
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-07-31 14:32 UTC (permalink / raw)
To: Mark Brown
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120731142607.GV4468-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
On Tue, Jul 31, 2012 at 03:26:07PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 04:22:17PM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 03:13:29PM +0100, Mark Brown wrote:
>
> > > __devinit can be discarded if you disable enough kernel features,
> > > HOTPLUG is the main one IIRC, modules might also need to go - drivers
> > > really ought to take a copy of platform data they plan to use at
> > > runtime, though practically speaking you have to try to trigger any
> > > problems.
>
> > HOTPLUG is marked EXPERT and explicitly states that it should only be
> > disabled if you're not using modules or dynamic device discovery. I
> > think if you've ignored all of that you're no longer entitled to
> > complain.
>
> This is framework code - it doesn't have much option. Disabling HOTPLUG
> is totally reasonable on space constrained systems, there's no reason
> for the code to break things for people.
Still if you use this code and disable HOTPLUG, then you shouldn't be
using modules either. I mean there is no way you can write a driver that
can gracefully handle its platform data being discarded.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-07-31 14:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20120731142216.GA19591@avionic-0098.adnet.avionic-design.de>
On Tue, Jul 31, 2012 at 04:22:17PM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 03:13:29PM +0100, Mark Brown wrote:
> > __devinit can be discarded if you disable enough kernel features,
> > HOTPLUG is the main one IIRC, modules might also need to go - drivers
> > really ought to take a copy of platform data they plan to use at
> > runtime, though practically speaking you have to try to trigger any
> > problems.
> HOTPLUG is marked EXPERT and explicitly states that it should only be
> disabled if you're not using modules or dynamic device discovery. I
> think if you've ignored all of that you're no longer entitled to
> complain.
This is framework code - it doesn't have much option. Disabling HOTPLUG
is totally reasonable on space constrained systems, there's no reason
for the code to break things for people.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-07-31 14:23 UTC (permalink / raw)
To: Alex Courbot
Cc: Simon Glass, Stephen Warren, Thierry Reding, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <50179933.9090501@nvidia.com>
On Tue, Jul 31, 2012 at 05:37:07PM +0900, Alex Courbot wrote:
> On 07/30/2012 08:00 PM, Simon Glass wrote:
> >For the delay, I think milliseconds is reasonable. I suppose there is
> >no reasonable need for microseconds?
> I don't see any need for microseconds myself - anybody sees use for
> finer-grained delays?
Bouncing reset lines, often the time required for reset is down in the
microseconds.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-07-31 14:22 UTC (permalink / raw)
To: Mark Brown
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <20120731141328.GS4468@opensource.wolfsonmicro.com>
[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]
On Tue, Jul 31, 2012 at 03:13:29PM +0100, Mark Brown wrote:
> On Tue, Jul 31, 2012 at 12:56:40PM +0200, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>
> > > The thing is that I am not sure what happens to the platform data
> > > once probe() is done. Isn't it customary to mark it with __devinit
> > > and have it freed after probing is successful?
>
> > No, platform data should stay around forever. Otherwise, consider what
> > would happen if your driver is built as a module and you unload and load
> > it again.
>
> __devinit can be discarded if you disable enough kernel features,
> HOTPLUG is the main one IIRC, modules might also need to go - drivers
> really ought to take a copy of platform data they plan to use at
> runtime, though practically speaking you have to try to trigger any
> problems.
HOTPLUG is marked EXPERT and explicitly states that it should only be
disabled if you're not using modules or dynamic device discovery. I
think if you've ignored all of that you're no longer entitled to
complain.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-07-31 14:13 UTC (permalink / raw)
To: Thierry Reding
Cc: Alex Courbot, Stephen Warren, Stephen Warren, Simon Glass,
Grant Likely, Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <20120731105640.GD16155-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On Tue, Jul 31, 2012 at 12:56:40PM +0200, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> > The thing is that I am not sure what happens to the platform data
> > once probe() is done. Isn't it customary to mark it with __devinit
> > and have it freed after probing is successful?
> No, platform data should stay around forever. Otherwise, consider what
> would happen if your driver is built as a module and you unload and load
> it again.
__devinit can be discarded if you disable enough kernel features,
HOTPLUG is the main one IIRC, modules might also need to go - drivers
really ought to take a copy of platform data they plan to use at
runtime, though practically speaking you have to try to trigger any
problems.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-07-31 14:11 UTC (permalink / raw)
To: Alex Courbot
Cc: Thierry Reding, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org
In-Reply-To: <5017AA87.2040503@nvidia.com>
On Tue, Jul 31, 2012 at 06:51:03PM +0900, Alex Courbot wrote:
> 2) On cleanup, it cleans the resources that needs to be freed (i.e.
> those that are not devm-handled).
> 2) can certainly be removed either by enforcing use of devm, or by
> doing reference counting. 1) seems more difficult to avoid - we need
I'd just add devm_ for everything that's not got it.
^ permalink raw reply
* Re: [PATCH 2/5] drivers/video/bfin-t350mcqb-fb.c: use devm_ functions
From: Mike Frysinger @ 2012-07-31 13:57 UTC (permalink / raw)
To: Damien Cassou
Cc: Florian Tobias Schandinat, kernel-janitors, linux-fbdev,
linux-kernel
In-Reply-To: <1343742860-16213-5-git-send-email-damien.cassou@lifl.fr>
On Tue, Jul 31, 2012 at 9:54 AM, Damien Cassou <damien.cassou@lifl.fr> wrote:
> The various devm_ functions allocate memory that is released when a driver
> detaches. This patch uses these functions for data that is allocated in
> the probe function of a platform device and is only freed in the remove
> function.
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
* [PATCH 1/5] drivers/video/bf537-lq035.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 13:54 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/bf537-lq035.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/video/bf537-lq035.c b/drivers/video/bf537-lq035.c
index befbc80..7347aa1 100644
--- a/drivers/video/bf537-lq035.c
+++ b/drivers/video/bf537-lq035.c
@@ -760,18 +760,20 @@ static int __devinit bfin_lq035_probe(struct platform_device *pdev)
bfin_lq035_fb.flags = FBINFO_DEFAULT;
- bfin_lq035_fb.pseudo_palette = kzalloc(sizeof(u32) * 16, GFP_KERNEL);
+ bfin_lq035_fb.pseudo_palette = devm_kzalloc(&pdev->dev,
+ sizeof(u32) * 16,
+ GFP_KERNEL);
if (bfin_lq035_fb.pseudo_palette = NULL) {
pr_err("failed to allocate pseudo_palette\n");
ret = -ENOMEM;
- goto out_palette;
+ goto out_table;
}
if (fb_alloc_cmap(&bfin_lq035_fb.cmap, NBR_PALETTE, 0) < 0) {
pr_err("failed to allocate colormap (%d entries)\n",
NBR_PALETTE);
ret = -EFAULT;
- goto out_cmap;
+ goto out_table;
}
if (register_framebuffer(&bfin_lq035_fb) < 0) {
@@ -804,9 +806,6 @@ out_lcd:
unregister_framebuffer(&bfin_lq035_fb);
out_reg:
fb_dealloc_cmap(&bfin_lq035_fb.cmap);
-out_cmap:
- kfree(bfin_lq035_fb.pseudo_palette);
-out_palette:
out_table:
dma_free_coherent(NULL, TOTAL_VIDEO_MEM_SIZE, fb_buffer, 0);
fb_buffer = NULL;
@@ -834,7 +833,6 @@ static int __devexit bfin_lq035_remove(struct platform_device *pdev)
free_dma(CH_PPI);
- kfree(bfin_lq035_fb.pseudo_palette);
fb_dealloc_cmap(&bfin_lq035_fb.cmap);
^ permalink raw reply related
* [PATCH 2/5] drivers/video/bfin-t350mcqb-fb.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 13:54 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/bfin-t350mcqb-fb.c | 28 +++++++++-------------------
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index 7a0c05f..43e0d1b 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -490,9 +490,10 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
fbinfo->fbops = &bfin_t350mcqb_fb_ops;
fbinfo->flags = FBINFO_FLAG_DEFAULT;
- info->fb_buffer = dma_alloc_coherent(NULL, fbinfo->fix.smem_len +
- ACTIVE_VIDEO_MEM_OFFSET,
- &info->dma_handle, GFP_KERNEL);
+ info->fb_buffer = dmam_alloc_coherent(&pdev->dev, NULL,
+ fbinfo->fix.smem_len +
+ ACTIVE_VIDEO_MEM_OFFSET,
+ &info->dma_handle, GFP_KERNEL);
if (NULL = info->fb_buffer) {
printk(KERN_ERR DRIVER_NAME
@@ -514,7 +515,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
"Fail to allocate colormap (%d entries)\n",
BFIN_LCD_NBR_PALETTE_ENTRIES);
ret = -EFAULT;
- goto out4;
+ goto out3;
}
if (bfin_t350mcqb_request_ports(1)) {
@@ -529,8 +530,8 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
goto out7;
}
- ret = request_irq(info->irq, bfin_t350mcqb_irq_error, 0,
- "PPI ERROR", info);
+ ret = devm_request_irq(&pdev->dev, info->irq, bfin_t350mcqb_irq_error,
+ 0, "PPI ERROR", info);
if (ret < 0) {
printk(KERN_ERR DRIVER_NAME
": unable to request PPI ERROR IRQ\n");
@@ -541,7 +542,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
printk(KERN_ERR DRIVER_NAME
": unable to register framebuffer.\n");
ret = -EINVAL;
- goto out8;
+ goto out7;
}
#ifndef NO_BL_SUPPORT
memset(&props, 0, sizeof(struct backlight_properties));
@@ -554,7 +555,7 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
": unable to register backlight.\n");
ret = -EINVAL;
unregister_framebuffer(fbinfo);
- goto out8;
+ goto out7;
}
lcd_dev = lcd_device_register(DRIVER_NAME, NULL, &bfin_lcd_ops);
@@ -563,15 +564,10 @@ static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev)
return 0;
-out8:
- free_irq(info->irq, info);
out7:
bfin_t350mcqb_request_ports(0);
out6:
fb_dealloc_cmap(&fbinfo->cmap);
-out4:
- dma_free_coherent(NULL, fbinfo->fix.smem_len + ACTIVE_VIDEO_MEM_OFFSET,
- info->fb_buffer, info->dma_handle);
out3:
framebuffer_release(fbinfo);
out2:
@@ -591,12 +587,6 @@ static int __devexit bfin_t350mcqb_remove(struct platform_device *pdev)
unregister_framebuffer(fbinfo);
free_dma(CH_PPI);
- free_irq(info->irq, info);
-
- if (info->fb_buffer != NULL)
- dma_free_coherent(NULL, fbinfo->fix.smem_len +
- ACTIVE_VIDEO_MEM_OFFSET, info->fb_buffer,
- info->dma_handle);
fb_dealloc_cmap(&fbinfo->cmap);
^ permalink raw reply related
* [PATCH 3/5] drivers/video/cobalt_lcdfb.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 13:54 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/cobalt_lcdfb.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/video/cobalt_lcdfb.c b/drivers/video/cobalt_lcdfb.c
index eae46f6..01a4ee7 100644
--- a/drivers/video/cobalt_lcdfb.c
+++ b/drivers/video/cobalt_lcdfb.c
@@ -348,7 +348,8 @@ static int __devinit cobalt_lcdfb_probe(struct platform_device *dev)
}
info->screen_size = resource_size(res);
- info->screen_base = ioremap(res->start, info->screen_size);
+ info->screen_base = devm_ioremap(&dev->dev, res->start,
+ info->screen_size);
info->fbops = &cobalt_lcd_fbops;
info->fix = cobalt_lcdfb_fix;
info->fix.smem_start = res->start;
@@ -359,7 +360,6 @@ static int __devinit cobalt_lcdfb_probe(struct platform_device *dev)
retval = register_framebuffer(info);
if (retval < 0) {
- iounmap(info->screen_base);
framebuffer_release(info);
return retval;
}
@@ -380,7 +380,6 @@ static int __devexit cobalt_lcdfb_remove(struct platform_device *dev)
info = platform_get_drvdata(dev);
if (info) {
- iounmap(info->screen_base);
unregister_framebuffer(info);
framebuffer_release(info);
}
^ permalink raw reply related
* [PATCH 4/5] drivers/video/da8xx-fb.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 13:54 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/da8xx-fb.c | 34 ++++++++--------------------------
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 7ae9d53..0429431 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -947,12 +947,9 @@ static int __devexit fb_remove(struct platform_device *dev)
par->p_palette_base);
dma_free_coherent(NULL, par->vram_size, par->vram_virt,
par->vram_phys);
- free_irq(par->irq, par);
clk_disable(par->lcdc_clk);
clk_put(par->lcdc_clk);
framebuffer_release(info);
- iounmap((void __iomem *)da8xx_fb_reg_base);
- release_mem_region(lcdc_regs->start, resource_size(lcdc_regs));
}
return 0;
@@ -1149,7 +1146,7 @@ static int __devinit fb_probe(struct platform_device *device)
struct fb_info *da8xx_fb_info;
struct clk *fb_clk = NULL;
struct da8xx_fb_par *par;
- resource_size_t len;
+
int ret, i;
unsigned long ulcm;
@@ -1159,29 +1156,20 @@ static int __devinit fb_probe(struct platform_device *device)
}
lcdc_regs = platform_get_resource(device, IORESOURCE_MEM, 0);
- if (!lcdc_regs) {
- dev_err(&device->dev,
- "Can not get memory resource for LCD controller\n");
- return -ENOENT;
- }
-
- len = resource_size(lcdc_regs);
- lcdc_regs = request_mem_region(lcdc_regs->start, len, lcdc_regs->name);
- if (!lcdc_regs)
- return -EBUSY;
-
- da8xx_fb_reg_base = (resource_size_t)ioremap(lcdc_regs->start, len);
+ da8xx_fb_reg_base + (resource_size_t) devm_request_and_ioremap(&device->dev,
+ lcdc_regs);
if (!da8xx_fb_reg_base) {
ret = -EBUSY;
- goto err_request_mem;
+ return ret;
}
fb_clk = clk_get(&device->dev, NULL);
if (IS_ERR(fb_clk)) {
dev_err(&device->dev, "Can not get device clock\n");
ret = -ENODEV;
- goto err_ioremap;
+ return ret;
}
ret = clk_enable(fb_clk);
if (ret)
@@ -1359,8 +1347,8 @@ static int __devinit fb_probe(struct platform_device *device)
else
lcdc_irq_handler = lcdc_irq_handler_rev02;
- ret = request_irq(par->irq, lcdc_irq_handler, 0,
- DRIVER_NAME, par);
+ ret = devm_request_irq(&device->dev, par->irq, lcdc_irq_handler, 0,
+ DRIVER_NAME, par);
if (ret)
goto irq_freq;
return 0;
@@ -1391,12 +1379,6 @@ err_clk_disable:
err_clk_put:
clk_put(fb_clk);
-err_ioremap:
- iounmap((void __iomem *)da8xx_fb_reg_base);
-
-err_request_mem:
- release_mem_region(lcdc_regs->start, len);
-
return ret;
}
^ permalink raw reply related
* [PATCH 5/5] drivers/video/ep93xx-fb.c: use devm_ functions
From: Damien Cassou @ 2012-07-31 13:54 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1343742860-16213-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/ep93xx-fb.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/video/ep93xx-fb.c b/drivers/video/ep93xx-fb.c
index 345d962..69c89f2 100644
--- a/drivers/video/ep93xx-fb.c
+++ b/drivers/video/ep93xx-fb.c
@@ -529,7 +529,8 @@ static int __devinit ep93xxfb_probe(struct platform_device *pdev)
* any of the framebuffer registers.
*/
fbi->res = res;
- fbi->mmio_base = ioremap(res->start, resource_size(res));
+ fbi->mmio_base = devm_ioremap(&pdev->dev, res->start,
+ resource_size(res));
if (!fbi->mmio_base) {
err = -ENXIO;
goto failed_resource;
@@ -553,20 +554,20 @@ static int __devinit ep93xxfb_probe(struct platform_device *pdev)
if (err = 0) {
dev_err(info->dev, "No suitable video mode found\n");
err = -EINVAL;
- goto failed_mode;
+ goto failed_resource;
}
if (mach_info->setup) {
err = mach_info->setup(pdev);
if (err)
- goto failed_mode;
+ goto failed_resource;
}
err = ep93xxfb_check_var(&info->var, info);
if (err)
goto failed_check;
- fbi->clk = clk_get(info->dev, NULL);
+ fbi->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(fbi->clk)) {
err = PTR_ERR(fbi->clk);
fbi->clk = NULL;
@@ -578,19 +579,15 @@ static int __devinit ep93xxfb_probe(struct platform_device *pdev)
err = register_framebuffer(info);
if (err)
- goto failed;
+ goto failed_check;
dev_info(info->dev, "registered. Mode = %dx%d-%d\n",
info->var.xres, info->var.yres, info->var.bits_per_pixel);
return 0;
-failed:
- clk_put(fbi->clk);
failed_check:
if (fbi->mach_info->teardown)
fbi->mach_info->teardown(pdev);
-failed_mode:
- iounmap(fbi->mmio_base);
failed_resource:
ep93xxfb_dealloc_videomem(info);
failed_videomem:
@@ -609,8 +606,6 @@ static int __devexit ep93xxfb_remove(struct platform_device *pdev)
unregister_framebuffer(info);
clk_disable(fbi->clk);
- clk_put(fbi->clk);
- iounmap(fbi->mmio_base);
ep93xxfb_dealloc_videomem(info);
fb_dealloc_cmap(&info->cmap);
^ permalink raw reply related
* [PATCH 0/5] use devm_ functions
From: Damien Cassou @ 2012-07-31 13:54 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
These patches introduce devm_ functions in some video drivers.
^ permalink raw reply
* Re: [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
From: Sylwester Nawrocki @ 2012-07-31 13:03 UTC (permalink / raw)
To: Sergei Shtylyov, Leela Krishna Amudala
Cc: linux-arm-kernel, linux-samsung-soc, linux-fbdev, kgene.kim,
jg1.han, joshi, dri-devel, inki.dae, ben-linux, m.szyprowski
In-Reply-To: <5017D4D7.3040303@mvista.com>
Hi,
On 07/31/2012 02:51 PM, Sergei Shtylyov wrote:
>> +/*EXYNOS5 FIMD REG OFFSET */
How about changing it to, e.g.
/* EXYNOS5 specific register offset definitions */
(but just in case you happen to resend this patch series)
>> +#define EXYNOS5_VIDTCON0 (0x20010)
>> +#define EXYNOS5_VIDTCON1 (0x20014)
>> +#define EXYNOS5_VIDTCON2 (0x20018)
>> +#define EXYNOS5_VIDTCON3 (0x2001C)
>> +#define EXYNOS5_VIDCON1 (0x20004)
>
> Parens not needed around simple literals.
Yes, I agree it looks insane. But, I think we could allow
this for consistency with the remaining definitions.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mitch Bradley @ 2012-07-31 12:55 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rob Herring, Alex Courbot,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20120731123811.GA25855-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
On 7/31/2012 8:38 PM, Thierry Reding wrote:
> On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
>> On 7/31/2012 6:56 PM, Thierry Reding wrote:
>>> On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
>>>> On 07/31/2012 07:45 AM, Stephen Warren wrote:
>>>>> I wonder if using the same structure/array as input and output would
>>>>> simplify the API; the platform data would fill in the fields mentioned
>>>>> above, and power_seq_build() would parse those, then set other fields in
>>>>> the same structs to the looked-up handle values?
>>>>
>>>> The thing is that I am not sure what happens to the platform data
>>>> once probe() is done. Isn't it customary to mark it with __devinit
>>>> and have it freed after probing is successful?
>>>
>>> No, platform data should stay around forever. Otherwise, consider what
>>> would happen if your driver is built as a module and you unload and load
>>> it again.
>>>
>>>> More generally, I think it is a good practice to have data
>>>> structures tailored right for what they need to do - code with
>>>> members that are meaningful only at given points of an instance's
>>>> life tends to be more confusing.
>>>
>>> I agree. Furthermore the driver unload/reload would be another reason
>>> not to reuse platform data as the output of the build() function.
>>>
>>> But maybe what Stephen meant was more like filling a structure with data
>>> taken from the platform data and pass that to a resolve() function which
>>> would fill in the missing pieces like pointers to actual resources. I
>>> imagine a managed interface would become a little trickier to do using
>>> such an approach.
>>>
>>>>> If the nodes have a unit address (i.e. end in "@n"), which they will
>>>>> have to if all named "step" and there's more than one of them, then they
>>>>> will need a matching reg property. Equally, the parent node will need
>>>>> #address-cells and #size-cells too. So, the last couple lines would be:
>>>>>
>>>>> power-on-sequence {
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>> step@0 {
>>>>> reg = <0>;
>>>>
>>>> That's precisely what I would like to avoid - I don't need the steps
>>>> to be numbered and I certainly have no use for a reg property. Isn't
>>>> there a way to make it simpler?
>>>
>>> It's not technically valid to not have the reg property. Or
>>> #address-cells and #size-cells properties for that matter.
>>
>> I'm not keen on this representation where individual steps are nodes.
>> That seems like it could end up being too "heavyweight" for a long sequence.
>
> The other alternative would involve using a single property to encode
> one sequence. I think that was the initial proposal, though using proper
> phandle encoding it could probably be enhanced a bit. However anything
> that involves a single property has the problem that we need to encode
> the type of resource as an integer, and that makes things very hard to
> read.
>
> So it would look something like this:
>
> power-on = <1 &gpio 6 0 1
> 0 10000
> 2 ® 1
> 3 &pwm 0 5000000 1>;
>
> power-off = <3 &pwm 0 5000000 0
> 2 ® 0
> 0 10000
> 1 &gpio 6 0 0>;
>
> So the first cell would encode the type:
> 0: delay
> 1: gpio
> 2: regulator
> 3: PWM
>
> The next n cells would be the phandle and the specifier, while the last
> cell would encode a resource-specific parameter:
> delay: time in microseconds
> gpio: set level (0: low, 1: high)
> regulator: 0: disable, 1: enable
> pwm: 0: disable, 1: enable
>
> I guess this would be more compact, but it is also very hard to read. Is
> that something you would be happier with? Perhaps you were thinking of
> something completely different?
Perhaps a compact/flexible encoding could be designed, with a textual
encoding that is easy to read. A separate tool could convert the text
encoding to the integer format, annotated with comments containing
the "source text". A file containing that output could be #included
into the dts file.
>
> Thierry
>
^ permalink raw reply
* Re: [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
From: Sergei Shtylyov @ 2012-07-31 12:51 UTC (permalink / raw)
To: Leela Krishna Amudala
Cc: linux-arm-kernel, linux-samsung-soc, linux-fbdev, kgene.kim,
jg1.han, joshi, dri-devel, inki.dae, ben-linux, m.szyprowski
In-Reply-To: <1343737385-23337-3-git-send-email-l.krishna@samsung.com>
Hello.
On 31-07-2012 16:23, Leela Krishna Amudala wrote:
> Exynos5 has VIDTCON and VIDCON registers at different offsets
> from the previous SOCs. Hence, adding the macros.
> Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
> ---
> include/video/samsung_fimd.h | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
> index e979f42..820f190 100644
> --- a/include/video/samsung_fimd.h
> +++ b/include/video/samsung_fimd.h
> @@ -524,3 +524,10 @@
> * 1110 -none- -none- -none- -none- -none-
> * 1111 -none- -none- -none- -none- -none-
> */
> +
> +/*EXYNOS5 FIMD REG OFFSET */
> +#define EXYNOS5_VIDTCON0 (0x20010)
> +#define EXYNOS5_VIDTCON1 (0x20014)
> +#define EXYNOS5_VIDTCON2 (0x20018)
> +#define EXYNOS5_VIDTCON3 (0x2001C)
> +#define EXYNOS5_VIDCON1 (0x20004)
Parens not needed around simple literals.
WBR, Sergei
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-07-31 12:38 UTC (permalink / raw)
To: Mitch Bradley
Cc: Alex Courbot, linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, Greg Kroah-Hartman, Mark Brown,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <5017CDF9.2060304-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3825 bytes --]
On Tue, Jul 31, 2012 at 08:22:17PM +0800, Mitch Bradley wrote:
> On 7/31/2012 6:56 PM, Thierry Reding wrote:
> > On Tue, Jul 31, 2012 at 07:32:20PM +0900, Alex Courbot wrote:
> >> On 07/31/2012 07:45 AM, Stephen Warren wrote:
> >>> I wonder if using the same structure/array as input and output would
> >>> simplify the API; the platform data would fill in the fields mentioned
> >>> above, and power_seq_build() would parse those, then set other fields in
> >>> the same structs to the looked-up handle values?
> >>
> >> The thing is that I am not sure what happens to the platform data
> >> once probe() is done. Isn't it customary to mark it with __devinit
> >> and have it freed after probing is successful?
> >
> > No, platform data should stay around forever. Otherwise, consider what
> > would happen if your driver is built as a module and you unload and load
> > it again.
> >
> >> More generally, I think it is a good practice to have data
> >> structures tailored right for what they need to do - code with
> >> members that are meaningful only at given points of an instance's
> >> life tends to be more confusing.
> >
> > I agree. Furthermore the driver unload/reload would be another reason
> > not to reuse platform data as the output of the build() function.
> >
> > But maybe what Stephen meant was more like filling a structure with data
> > taken from the platform data and pass that to a resolve() function which
> > would fill in the missing pieces like pointers to actual resources. I
> > imagine a managed interface would become a little trickier to do using
> > such an approach.
> >
> >>> If the nodes have a unit address (i.e. end in "@n"), which they will
> >>> have to if all named "step" and there's more than one of them, then they
> >>> will need a matching reg property. Equally, the parent node will need
> >>> #address-cells and #size-cells too. So, the last couple lines would be:
> >>>
> >>> power-on-sequence {
> >>> #address-cells = <1>;
> >>> #size-cells = <0>;
> >>> step@0 {
> >>> reg = <0>;
> >>
> >> That's precisely what I would like to avoid - I don't need the steps
> >> to be numbered and I certainly have no use for a reg property. Isn't
> >> there a way to make it simpler?
> >
> > It's not technically valid to not have the reg property. Or
> > #address-cells and #size-cells properties for that matter.
>
> I'm not keen on this representation where individual steps are nodes.
> That seems like it could end up being too "heavyweight" for a long sequence.
The other alternative would involve using a single property to encode
one sequence. I think that was the initial proposal, though using proper
phandle encoding it could probably be enhanced a bit. However anything
that involves a single property has the problem that we need to encode
the type of resource as an integer, and that makes things very hard to
read.
So it would look something like this:
power-on = <1 &gpio 6 0 1
0 10000
2 ® 1
3 &pwm 0 5000000 1>;
power-off = <3 &pwm 0 5000000 0
2 ® 0
0 10000
1 &gpio 6 0 0>;
So the first cell would encode the type:
0: delay
1: gpio
2: regulator
3: PWM
The next n cells would be the phandle and the specifier, while the last
cell would encode a resource-specific parameter:
delay: time in microseconds
gpio: set level (0: low, 1: high)
regulator: 0: disable, 1: enable
pwm: 0: disable, 1: enable
I guess this would be more compact, but it is also very hard to read. Is
that something you would be happier with? Perhaps you were thinking of
something completely different?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
From: Leela Krishna Amudala @ 2012-07-31 12:35 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc
Cc: dri-devel, linux-fbdev, ben-linux, inki.dae, kgene.kim, joshi,
jg1.han, m.szyprowski
In-Reply-To: <1343737385-23337-1-git-send-email-l.krishna@samsung.com>
The FIMD register headers are moved to include/video/
hence, deleting these files from platform side
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
---
arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 ---------
arch/arm/plat-samsung/include/plat/regs-fb.h | 403 -----------------------
2 files changed, 0 insertions(+), 562 deletions(-)
delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h
diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
deleted file mode 100644
index 4c3647f..0000000
--- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h
+++ /dev/null
@@ -1,159 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- * http://armlinux.simtec.co.uk/
- * Ben Dooks <ben@simtec.co.uk>
- *
- * S3C64XX - new-style framebuffer register definitions
- *
- * This is the register set for the new style framebuffer interface
- * found from the S3C2443 onwards and specifically the S3C64XX series
- * S3C6400 and S3C6410.
- *
- * The file contains the cpu specific items which change between whichever
- * architecture is selected. See <plat/regs-fb.h> for the core definitions
- * that are the same.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-/* include the core definitions here, in case we really do need to
- * override them at a later date.
-*/
-
-#include <plat/regs-fb.h>
-
-#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */
-#define VIDCON1_FSTATUS_EVEN (1 << 15)
-
-/* Video timing controls */
-#define VIDTCON0 (0x10)
-#define VIDTCON1 (0x14)
-#define VIDTCON2 (0x18)
-
-/* Window position controls */
-
-#define WINCON(_win) (0x20 + ((_win) * 4))
-
-/* OSD1 and OSD4 do not have register D */
-
-#define VIDOSD_BASE (0x40)
-
-#define VIDINTCON0 (0x130)
-
-/* WINCONx */
-
-#define WINCONx_CSCWIDTH_MASK (0x3 << 26)
-#define WINCONx_CSCWIDTH_SHIFT (26)
-#define WINCONx_CSCWIDTH_WIDE (0x0 << 26)
-#define WINCONx_CSCWIDTH_NARROW (0x3 << 26)
-
-#define WINCONx_ENLOCAL (1 << 22)
-#define WINCONx_BUFSTATUS (1 << 21)
-#define WINCONx_BUFSEL (1 << 20)
-#define WINCONx_BUFAUTOEN (1 << 19)
-#define WINCONx_YCbCr (1 << 13)
-
-#define WINCON1_LOCALSEL_CAMIF (1 << 23)
-
-#define WINCON2_LOCALSEL_CAMIF (1 << 23)
-#define WINCON2_BLD_PIX (1 << 6)
-
-#define WINCON2_ALPHA_SEL (1 << 1)
-#define WINCON2_BPPMODE_MASK (0xf << 2)
-#define WINCON2_BPPMODE_SHIFT (2)
-#define WINCON2_BPPMODE_1BPP (0x0 << 2)
-#define WINCON2_BPPMODE_2BPP (0x1 << 2)
-#define WINCON2_BPPMODE_4BPP (0x2 << 2)
-#define WINCON2_BPPMODE_8BPP_1232 (0x4 << 2)
-#define WINCON2_BPPMODE_16BPP_565 (0x5 << 2)
-#define WINCON2_BPPMODE_16BPP_A1555 (0x6 << 2)
-#define WINCON2_BPPMODE_16BPP_I1555 (0x7 << 2)
-#define WINCON2_BPPMODE_18BPP_666 (0x8 << 2)
-#define WINCON2_BPPMODE_18BPP_A1665 (0x9 << 2)
-#define WINCON2_BPPMODE_19BPP_A1666 (0xa << 2)
-#define WINCON2_BPPMODE_24BPP_888 (0xb << 2)
-#define WINCON2_BPPMODE_24BPP_A1887 (0xc << 2)
-#define WINCON2_BPPMODE_25BPP_A1888 (0xd << 2)
-#define WINCON2_BPPMODE_28BPP_A4888 (0xd << 2)
-
-#define WINCON3_BLD_PIX (1 << 6)
-
-#define WINCON3_ALPHA_SEL (1 << 1)
-#define WINCON3_BPPMODE_MASK (0xf << 2)
-#define WINCON3_BPPMODE_SHIFT (2)
-#define WINCON3_BPPMODE_1BPP (0x0 << 2)
-#define WINCON3_BPPMODE_2BPP (0x1 << 2)
-#define WINCON3_BPPMODE_4BPP (0x2 << 2)
-#define WINCON3_BPPMODE_16BPP_565 (0x5 << 2)
-#define WINCON3_BPPMODE_16BPP_A1555 (0x6 << 2)
-#define WINCON3_BPPMODE_16BPP_I1555 (0x7 << 2)
-#define WINCON3_BPPMODE_18BPP_666 (0x8 << 2)
-#define WINCON3_BPPMODE_18BPP_A1665 (0x9 << 2)
-#define WINCON3_BPPMODE_19BPP_A1666 (0xa << 2)
-#define WINCON3_BPPMODE_24BPP_888 (0xb << 2)
-#define WINCON3_BPPMODE_24BPP_A1887 (0xc << 2)
-#define WINCON3_BPPMODE_25BPP_A1888 (0xd << 2)
-#define WINCON3_BPPMODE_28BPP_A4888 (0xd << 2)
-
-#define VIDINTCON0_FIFIOSEL_WINDOW2 (0x10 << 5)
-#define VIDINTCON0_FIFIOSEL_WINDOW3 (0x20 << 5)
-#define VIDINTCON0_FIFIOSEL_WINDOW4 (0x40 << 5)
-
-#define DITHMODE (0x170)
-#define WINxMAP(_win) (0x180 + ((_win) * 4))
-
-
-#define DITHMODE_R_POS_MASK (0x3 << 5)
-#define DITHMODE_R_POS_SHIFT (5)
-#define DITHMODE_R_POS_8BIT (0x0 << 5)
-#define DITHMODE_R_POS_6BIT (0x1 << 5)
-#define DITHMODE_R_POS_5BIT (0x2 << 5)
-
-#define DITHMODE_G_POS_MASK (0x3 << 3)
-#define DITHMODE_G_POS_SHIFT (3)
-#define DITHMODE_G_POS_8BIT (0x0 << 3)
-#define DITHMODE_G_POS_6BIT (0x1 << 3)
-#define DITHMODE_G_POS_5BIT (0x2 << 3)
-
-#define DITHMODE_B_POS_MASK (0x3 << 1)
-#define DITHMODE_B_POS_SHIFT (1)
-#define DITHMODE_B_POS_8BIT (0x0 << 1)
-#define DITHMODE_B_POS_6BIT (0x1 << 1)
-#define DITHMODE_B_POS_5BIT (0x2 << 1)
-
-#define DITHMODE_DITH_EN (1 << 0)
-
-#define WPALCON (0x1A0)
-
-/* Palette control */
-/* Note for S5PC100: you can still use those macros on WPALCON (aka WPALCON_L),
- * but make sure that WPALCON_H W2PAL-W4PAL entries are zeroed out */
-#define WPALCON_W4PAL_16BPP_A555 (1 << 8)
-#define WPALCON_W3PAL_16BPP_A555 (1 << 7)
-#define WPALCON_W2PAL_16BPP_A555 (1 << 6)
-
-
-/* Notes on per-window bpp settings
- *
- * Value Win0 Win1 Win2 Win3 Win 4
- * 0000 1(P) 1(P) 1(P) 1(P) 1(P)
- * 0001 2(P) 2(P) 2(P) 2(P) 2(P)
- * 0010 4(P) 4(P) 4(P) 4(P) -none-
- * 0011 8(P) 8(P) -none- -none- -none-
- * 0100 -none- 8(A232) 8(A232) -none- -none-
- * 0101 16(565) 16(565) 16(565) 16(565) 16(565)
- * 0110 -none- 16(A555) 16(A555) 16(A555) 16(A555)
- * 0111 16(I555) 16(I565) 16(I555) 16(I555) 16(I555)
- * 1000 18(666) 18(666) 18(666) 18(666) 18(666)
- * 1001 -none- 18(A665) 18(A665) 18(A665) 16(A665)
- * 1010 -none- 19(A666) 19(A666) 19(A666) 19(A666)
- * 1011 24(888) 24(888) 24(888) 24(888) 24(888)
- * 1100 -none- 24(A887) 24(A887) 24(A887) 24(A887)
- * 1101 -none- 25(A888) 25(A888) 25(A888) 25(A888)
- * 1110 -none- -none- -none- -none- -none-
- * 1111 -none- -none- -none- -none- -none-
-*/
diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat-samsung/include/plat/regs-fb.h
deleted file mode 100644
index 9a78012..0000000
--- a/arch/arm/plat-samsung/include/plat/regs-fb.h
+++ /dev/null
@@ -1,403 +0,0 @@
-/* arch/arm/plat-samsung/include/plat/regs-fb.h
- *
- * Copyright 2008 Openmoko, Inc.
- * Copyright 2008 Simtec Electronics
- * http://armlinux.simtec.co.uk/
- * Ben Dooks <ben@simtec.co.uk>
- *
- * S3C Platform - new-style framebuffer register definitions
- *
- * This is the register set for the new style framebuffer interface
- * found from the S3C2443 onwards into the S3C2416, S3C2450 and the
- * S3C64XX series such as the S3C6400 and S3C6410.
- *
- * The file does not contain the cpu specific items which are based on
- * whichever architecture is selected, it only contains the core of the
- * register set. See <mach/regs-fb.h> to get the specifics.
- *
- * Note, we changed to using regs-fb.h as it avoids any clashes with
- * the original regs-lcd.h so out of the way of regs-lcd.h as well as
- * indicating the newer block is much more than just an LCD interface.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-/* Please do not include this file directly, use <mach/regs-fb.h> to
- * ensure all the localised SoC support is included as necessary.
-*/
-
-/* VIDCON0 */
-
-#define VIDCON0 (0x00)
-#define VIDCON0_INTERLACE (1 << 29)
-#define VIDCON0_VIDOUT_MASK (0x3 << 26)
-#define VIDCON0_VIDOUT_SHIFT (26)
-#define VIDCON0_VIDOUT_RGB (0x0 << 26)
-#define VIDCON0_VIDOUT_TV (0x1 << 26)
-#define VIDCON0_VIDOUT_I80_LDI0 (0x2 << 26)
-#define VIDCON0_VIDOUT_I80_LDI1 (0x3 << 26)
-
-#define VIDCON0_L1_DATA_MASK (0x7 << 23)
-#define VIDCON0_L1_DATA_SHIFT (23)
-#define VIDCON0_L1_DATA_16BPP (0x0 << 23)
-#define VIDCON0_L1_DATA_18BPP16 (0x1 << 23)
-#define VIDCON0_L1_DATA_18BPP9 (0x2 << 23)
-#define VIDCON0_L1_DATA_24BPP (0x3 << 23)
-#define VIDCON0_L1_DATA_18BPP (0x4 << 23)
-#define VIDCON0_L1_DATA_16BPP8 (0x5 << 23)
-
-#define VIDCON0_L0_DATA_MASK (0x7 << 20)
-#define VIDCON0_L0_DATA_SHIFT (20)
-#define VIDCON0_L0_DATA_16BPP (0x0 << 20)
-#define VIDCON0_L0_DATA_18BPP16 (0x1 << 20)
-#define VIDCON0_L0_DATA_18BPP9 (0x2 << 20)
-#define VIDCON0_L0_DATA_24BPP (0x3 << 20)
-#define VIDCON0_L0_DATA_18BPP (0x4 << 20)
-#define VIDCON0_L0_DATA_16BPP8 (0x5 << 20)
-
-#define VIDCON0_PNRMODE_MASK (0x3 << 17)
-#define VIDCON0_PNRMODE_SHIFT (17)
-#define VIDCON0_PNRMODE_RGB (0x0 << 17)
-#define VIDCON0_PNRMODE_BGR (0x1 << 17)
-#define VIDCON0_PNRMODE_SERIAL_RGB (0x2 << 17)
-#define VIDCON0_PNRMODE_SERIAL_BGR (0x3 << 17)
-
-#define VIDCON0_CLKVALUP (1 << 16)
-#define VIDCON0_CLKVAL_F_MASK (0xff << 6)
-#define VIDCON0_CLKVAL_F_SHIFT (6)
-#define VIDCON0_CLKVAL_F_LIMIT (0xff)
-#define VIDCON0_CLKVAL_F(_x) ((_x) << 6)
-#define VIDCON0_VLCKFREE (1 << 5)
-#define VIDCON0_CLKDIR (1 << 4)
-
-#define VIDCON0_CLKSEL_MASK (0x3 << 2)
-#define VIDCON0_CLKSEL_SHIFT (2)
-#define VIDCON0_CLKSEL_HCLK (0x0 << 2)
-#define VIDCON0_CLKSEL_LCD (0x1 << 2)
-#define VIDCON0_CLKSEL_27M (0x3 << 2)
-
-#define VIDCON0_ENVID (1 << 1)
-#define VIDCON0_ENVID_F (1 << 0)
-
-#define VIDCON1 (0x04)
-#define VIDCON1_LINECNT_MASK (0x7ff << 16)
-#define VIDCON1_LINECNT_SHIFT (16)
-#define VIDCON1_LINECNT_GET(_v) (((_v) >> 16) & 0x7ff)
-#define VIDCON1_VSTATUS_MASK (0x3 << 13)
-#define VIDCON1_VSTATUS_SHIFT (13)
-#define VIDCON1_VSTATUS_VSYNC (0x0 << 13)
-#define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13)
-#define VIDCON1_VSTATUS_ACTIVE (0x2 << 13)
-#define VIDCON1_VSTATUS_FRONTPORCH (0x0 << 13)
-#define VIDCON1_VCLK_MASK (0x3 << 9)
-#define VIDCON1_VCLK_HOLD (0x0 << 9)
-#define VIDCON1_VCLK_RUN (0x1 << 9)
-
-#define VIDCON1_INV_VCLK (1 << 7)
-#define VIDCON1_INV_HSYNC (1 << 6)
-#define VIDCON1_INV_VSYNC (1 << 5)
-#define VIDCON1_INV_VDEN (1 << 4)
-
-/* VIDCON2 */
-
-#define VIDCON2 (0x08)
-#define VIDCON2_EN601 (1 << 23)
-#define VIDCON2_TVFMTSEL_SW (1 << 14)
-
-#define VIDCON2_TVFMTSEL1_MASK (0x3 << 12)
-#define VIDCON2_TVFMTSEL1_SHIFT (12)
-#define VIDCON2_TVFMTSEL1_RGB (0x0 << 12)
-#define VIDCON2_TVFMTSEL1_YUV422 (0x1 << 12)
-#define VIDCON2_TVFMTSEL1_YUV444 (0x2 << 12)
-
-#define VIDCON2_ORGYCbCr (1 << 8)
-#define VIDCON2_YUVORDCrCb (1 << 7)
-
-/* PRTCON (S3C6410, S5PC100)
- * Might not be present in the S3C6410 documentation,
- * but tests prove it's there almost for sure; shouldn't hurt in any case.
- */
-#define PRTCON (0x0c)
-#define PRTCON_PROTECT (1 << 11)
-
-/* VIDTCON0 */
-
-#define VIDTCON0_VBPDE_MASK (0xff << 24)
-#define VIDTCON0_VBPDE_SHIFT (24)
-#define VIDTCON0_VBPDE_LIMIT (0xff)
-#define VIDTCON0_VBPDE(_x) ((_x) << 24)
-
-#define VIDTCON0_VBPD_MASK (0xff << 16)
-#define VIDTCON0_VBPD_SHIFT (16)
-#define VIDTCON0_VBPD_LIMIT (0xff)
-#define VIDTCON0_VBPD(_x) ((_x) << 16)
-
-#define VIDTCON0_VFPD_MASK (0xff << 8)
-#define VIDTCON0_VFPD_SHIFT (8)
-#define VIDTCON0_VFPD_LIMIT (0xff)
-#define VIDTCON0_VFPD(_x) ((_x) << 8)
-
-#define VIDTCON0_VSPW_MASK (0xff << 0)
-#define VIDTCON0_VSPW_SHIFT (0)
-#define VIDTCON0_VSPW_LIMIT (0xff)
-#define VIDTCON0_VSPW(_x) ((_x) << 0)
-
-/* VIDTCON1 */
-
-#define VIDTCON1_VFPDE_MASK (0xff << 24)
-#define VIDTCON1_VFPDE_SHIFT (24)
-#define VIDTCON1_VFPDE_LIMIT (0xff)
-#define VIDTCON1_VFPDE(_x) ((_x) << 24)
-
-#define VIDTCON1_HBPD_MASK (0xff << 16)
-#define VIDTCON1_HBPD_SHIFT (16)
-#define VIDTCON1_HBPD_LIMIT (0xff)
-#define VIDTCON1_HBPD(_x) ((_x) << 16)
-
-#define VIDTCON1_HFPD_MASK (0xff << 8)
-#define VIDTCON1_HFPD_SHIFT (8)
-#define VIDTCON1_HFPD_LIMIT (0xff)
-#define VIDTCON1_HFPD(_x) ((_x) << 8)
-
-#define VIDTCON1_HSPW_MASK (0xff << 0)
-#define VIDTCON1_HSPW_SHIFT (0)
-#define VIDTCON1_HSPW_LIMIT (0xff)
-#define VIDTCON1_HSPW(_x) ((_x) << 0)
-
-#define VIDTCON2 (0x18)
-#define VIDTCON2_LINEVAL_E(_x) ((((_x) & 0x800) >> 11) << 23)
-#define VIDTCON2_LINEVAL_MASK (0x7ff << 11)
-#define VIDTCON2_LINEVAL_SHIFT (11)
-#define VIDTCON2_LINEVAL_LIMIT (0x7ff)
-#define VIDTCON2_LINEVAL(_x) (((_x) & 0x7ff) << 11)
-
-#define VIDTCON2_HOZVAL_E(_x) ((((_x) & 0x800) >> 11) << 22)
-#define VIDTCON2_HOZVAL_MASK (0x7ff << 0)
-#define VIDTCON2_HOZVAL_SHIFT (0)
-#define VIDTCON2_HOZVAL_LIMIT (0x7ff)
-#define VIDTCON2_HOZVAL(_x) (((_x) & 0x7ff) << 0)
-
-/* WINCONx */
-
-
-#define WINCONx_BITSWP (1 << 18)
-#define WINCONx_BYTSWP (1 << 17)
-#define WINCONx_HAWSWP (1 << 16)
-#define WINCONx_WSWP (1 << 15)
-#define WINCONx_BURSTLEN_MASK (0x3 << 9)
-#define WINCONx_BURSTLEN_SHIFT (9)
-#define WINCONx_BURSTLEN_16WORD (0x0 << 9)
-#define WINCONx_BURSTLEN_8WORD (0x1 << 9)
-#define WINCONx_BURSTLEN_4WORD (0x2 << 9)
-
-#define WINCONx_ENWIN (1 << 0)
-#define WINCON0_BPPMODE_MASK (0xf << 2)
-#define WINCON0_BPPMODE_SHIFT (2)
-#define WINCON0_BPPMODE_1BPP (0x0 << 2)
-#define WINCON0_BPPMODE_2BPP (0x1 << 2)
-#define WINCON0_BPPMODE_4BPP (0x2 << 2)
-#define WINCON0_BPPMODE_8BPP_PALETTE (0x3 << 2)
-#define WINCON0_BPPMODE_16BPP_565 (0x5 << 2)
-#define WINCON0_BPPMODE_16BPP_1555 (0x7 << 2)
-#define WINCON0_BPPMODE_18BPP_666 (0x8 << 2)
-#define WINCON0_BPPMODE_24BPP_888 (0xb << 2)
-
-#define WINCON1_BLD_PIX (1 << 6)
-
-#define WINCON1_ALPHA_SEL (1 << 1)
-#define WINCON1_BPPMODE_MASK (0xf << 2)
-#define WINCON1_BPPMODE_SHIFT (2)
-#define WINCON1_BPPMODE_1BPP (0x0 << 2)
-#define WINCON1_BPPMODE_2BPP (0x1 << 2)
-#define WINCON1_BPPMODE_4BPP (0x2 << 2)
-#define WINCON1_BPPMODE_8BPP_PALETTE (0x3 << 2)
-#define WINCON1_BPPMODE_8BPP_1232 (0x4 << 2)
-#define WINCON1_BPPMODE_16BPP_565 (0x5 << 2)
-#define WINCON1_BPPMODE_16BPP_A1555 (0x6 << 2)
-#define WINCON1_BPPMODE_16BPP_I1555 (0x7 << 2)
-#define WINCON1_BPPMODE_18BPP_666 (0x8 << 2)
-#define WINCON1_BPPMODE_18BPP_A1665 (0x9 << 2)
-#define WINCON1_BPPMODE_19BPP_A1666 (0xa << 2)
-#define WINCON1_BPPMODE_24BPP_888 (0xb << 2)
-#define WINCON1_BPPMODE_24BPP_A1887 (0xc << 2)
-#define WINCON1_BPPMODE_25BPP_A1888 (0xd << 2)
-#define WINCON1_BPPMODE_28BPP_A4888 (0xd << 2)
-
-/* S5PV210 */
-#define SHADOWCON (0x34)
-#define SHADOWCON_WINx_PROTECT(_win) (1 << (10 + (_win)))
-/* DMA channels (all windows) */
-#define SHADOWCON_CHx_ENABLE(_win) (1 << (_win))
-/* Local input channels (windows 0-2) */
-#define SHADOWCON_CHx_LOCAL_ENABLE(_win) (1 << (5 + (_win)))
-
-#define VIDOSDxA_TOPLEFT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
-#define VIDOSDxA_TOPLEFT_X_MASK (0x7ff << 11)
-#define VIDOSDxA_TOPLEFT_X_SHIFT (11)
-#define VIDOSDxA_TOPLEFT_X_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_X(_x) (((_x) & 0x7ff) << 11)
-
-#define VIDOSDxA_TOPLEFT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
-#define VIDOSDxA_TOPLEFT_Y_MASK (0x7ff << 0)
-#define VIDOSDxA_TOPLEFT_Y_SHIFT (0)
-#define VIDOSDxA_TOPLEFT_Y_LIMIT (0x7ff)
-#define VIDOSDxA_TOPLEFT_Y(_x) (((_x) & 0x7ff) << 0)
-
-#define VIDOSDxB_BOTRIGHT_X_E(_x) ((((_x) & 0x800) >> 11) << 23)
-#define VIDOSDxB_BOTRIGHT_X_MASK (0x7ff << 11)
-#define VIDOSDxB_BOTRIGHT_X_SHIFT (11)
-#define VIDOSDxB_BOTRIGHT_X_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_X(_x) (((_x) & 0x7ff) << 11)
-
-#define VIDOSDxB_BOTRIGHT_Y_E(_x) ((((_x) & 0x800) >> 11) << 22)
-#define VIDOSDxB_BOTRIGHT_Y_MASK (0x7ff << 0)
-#define VIDOSDxB_BOTRIGHT_Y_SHIFT (0)
-#define VIDOSDxB_BOTRIGHT_Y_LIMIT (0x7ff)
-#define VIDOSDxB_BOTRIGHT_Y(_x) (((_x) & 0x7ff) << 0)
-
-/* For VIDOSD[1..4]C */
-#define VIDISD14C_ALPHA0_R(_x) ((_x) << 20)
-#define VIDISD14C_ALPHA0_G_MASK (0xf << 16)
-#define VIDISD14C_ALPHA0_G_SHIFT (16)
-#define VIDISD14C_ALPHA0_G_LIMIT (0xf)
-#define VIDISD14C_ALPHA0_G(_x) ((_x) << 16)
-#define VIDISD14C_ALPHA0_B_MASK (0xf << 12)
-#define VIDISD14C_ALPHA0_B_SHIFT (12)
-#define VIDISD14C_ALPHA0_B_LIMIT (0xf)
-#define VIDISD14C_ALPHA0_B(_x) ((_x) << 12)
-#define VIDISD14C_ALPHA1_R_MASK (0xf << 8)
-#define VIDISD14C_ALPHA1_R_SHIFT (8)
-#define VIDISD14C_ALPHA1_R_LIMIT (0xf)
-#define VIDISD14C_ALPHA1_R(_x) ((_x) << 8)
-#define VIDISD14C_ALPHA1_G_MASK (0xf << 4)
-#define VIDISD14C_ALPHA1_G_SHIFT (4)
-#define VIDISD14C_ALPHA1_G_LIMIT (0xf)
-#define VIDISD14C_ALPHA1_G(_x) ((_x) << 4)
-#define VIDISD14C_ALPHA1_B_MASK (0xf << 0)
-#define VIDISD14C_ALPHA1_B_SHIFT (0)
-#define VIDISD14C_ALPHA1_B_LIMIT (0xf)
-#define VIDISD14C_ALPHA1_B(_x) ((_x) << 0)
-
-/* Video buffer addresses */
-#define VIDW_BUF_START(_buff) (0xA0 + ((_buff) * 8))
-#define VIDW_BUF_START1(_buff) (0xA4 + ((_buff) * 8))
-#define VIDW_BUF_END(_buff) (0xD0 + ((_buff) * 8))
-#define VIDW_BUF_END1(_buff) (0xD4 + ((_buff) * 8))
-#define VIDW_BUF_SIZE(_buff) (0x100 + ((_buff) * 4))
-
-#define VIDW_BUF_SIZE_OFFSET_E(_x) ((((_x) & 0x2000) >> 13) << 27)
-#define VIDW_BUF_SIZE_OFFSET_MASK (0x1fff << 13)
-#define VIDW_BUF_SIZE_OFFSET_SHIFT (13)
-#define VIDW_BUF_SIZE_OFFSET_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_OFFSET(_x) (((_x) & 0x1fff) << 13)
-
-#define VIDW_BUF_SIZE_PAGEWIDTH_E(_x) ((((_x) & 0x2000) >> 13) << 26)
-#define VIDW_BUF_SIZE_PAGEWIDTH_MASK (0x1fff << 0)
-#define VIDW_BUF_SIZE_PAGEWIDTH_SHIFT (0)
-#define VIDW_BUF_SIZE_PAGEWIDTH_LIMIT (0x1fff)
-#define VIDW_BUF_SIZE_PAGEWIDTH(_x) (((_x) & 0x1fff) << 0)
-
-/* Interrupt controls and status */
-
-#define VIDINTCON0_FIFOINTERVAL_MASK (0x3f << 20)
-#define VIDINTCON0_FIFOINTERVAL_SHIFT (20)
-#define VIDINTCON0_FIFOINTERVAL_LIMIT (0x3f)
-#define VIDINTCON0_FIFOINTERVAL(_x) ((_x) << 20)
-
-#define VIDINTCON0_INT_SYSMAINCON (1 << 19)
-#define VIDINTCON0_INT_SYSSUBCON (1 << 18)
-#define VIDINTCON0_INT_I80IFDONE (1 << 17)
-
-#define VIDINTCON0_FRAMESEL0_MASK (0x3 << 15)
-#define VIDINTCON0_FRAMESEL0_SHIFT (15)
-#define VIDINTCON0_FRAMESEL0_BACKPORCH (0x0 << 15)
-#define VIDINTCON0_FRAMESEL0_VSYNC (0x1 << 15)
-#define VIDINTCON0_FRAMESEL0_ACTIVE (0x2 << 15)
-#define VIDINTCON0_FRAMESEL0_FRONTPORCH (0x3 << 15)
-
-#define VIDINTCON0_FRAMESEL1 (1 << 13)
-#define VIDINTCON0_FRAMESEL1_MASK (0x3 << 13)
-#define VIDINTCON0_FRAMESEL1_NONE (0x0 << 13)
-#define VIDINTCON0_FRAMESEL1_BACKPORCH (0x1 << 13)
-#define VIDINTCON0_FRAMESEL1_VSYNC (0x2 << 13)
-#define VIDINTCON0_FRAMESEL1_FRONTPORCH (0x3 << 13)
-
-#define VIDINTCON0_INT_FRAME (1 << 12)
-#define VIDINTCON0_FIFIOSEL_MASK (0x7f << 5)
-#define VIDINTCON0_FIFIOSEL_SHIFT (5)
-#define VIDINTCON0_FIFIOSEL_WINDOW0 (0x1 << 5)
-#define VIDINTCON0_FIFIOSEL_WINDOW1 (0x2 << 5)
-
-#define VIDINTCON0_FIFOLEVEL_MASK (0x7 << 2)
-#define VIDINTCON0_FIFOLEVEL_SHIFT (2)
-#define VIDINTCON0_FIFOLEVEL_TO25PC (0x0 << 2)
-#define VIDINTCON0_FIFOLEVEL_TO50PC (0x1 << 2)
-#define VIDINTCON0_FIFOLEVEL_TO75PC (0x2 << 2)
-#define VIDINTCON0_FIFOLEVEL_EMPTY (0x3 << 2)
-#define VIDINTCON0_FIFOLEVEL_FULL (0x4 << 2)
-
-#define VIDINTCON0_INT_FIFO_MASK (0x3 << 0)
-#define VIDINTCON0_INT_FIFO_SHIFT (0)
-#define VIDINTCON0_INT_ENABLE (1 << 0)
-
-#define VIDINTCON1 (0x134)
-#define VIDINTCON1_INT_I180 (1 << 2)
-#define VIDINTCON1_INT_FRAME (1 << 1)
-#define VIDINTCON1_INT_FIFO (1 << 0)
-
-/* Window colour-key control registers */
-#define WKEYCON (0x140) /* 6410,V210 */
-
-#define WKEYCON0 (0x00)
-#define WKEYCON1 (0x04)
-
-#define WxKEYCON0_KEYBL_EN (1 << 26)
-#define WxKEYCON0_KEYEN_F (1 << 25)
-#define WxKEYCON0_DIRCON (1 << 24)
-#define WxKEYCON0_COMPKEY_MASK (0xffffff << 0)
-#define WxKEYCON0_COMPKEY_SHIFT (0)
-#define WxKEYCON0_COMPKEY_LIMIT (0xffffff)
-#define WxKEYCON0_COMPKEY(_x) ((_x) << 0)
-#define WxKEYCON1_COLVAL_MASK (0xffffff << 0)
-#define WxKEYCON1_COLVAL_SHIFT (0)
-#define WxKEYCON1_COLVAL_LIMIT (0xffffff)
-#define WxKEYCON1_COLVAL(_x) ((_x) << 0)
-
-
-/* Window blanking (MAP) */
-
-#define WINxMAP_MAP (1 << 24)
-#define WINxMAP_MAP_COLOUR_MASK (0xffffff << 0)
-#define WINxMAP_MAP_COLOUR_SHIFT (0)
-#define WINxMAP_MAP_COLOUR_LIMIT (0xffffff)
-#define WINxMAP_MAP_COLOUR(_x) ((_x) << 0)
-
-#define WPALCON_PAL_UPDATE (1 << 9)
-#define WPALCON_W1PAL_MASK (0x7 << 3)
-#define WPALCON_W1PAL_SHIFT (3)
-#define WPALCON_W1PAL_25BPP_A888 (0x0 << 3)
-#define WPALCON_W1PAL_24BPP (0x1 << 3)
-#define WPALCON_W1PAL_19BPP_A666 (0x2 << 3)
-#define WPALCON_W1PAL_18BPP_A665 (0x3 << 3)
-#define WPALCON_W1PAL_18BPP (0x4 << 3)
-#define WPALCON_W1PAL_16BPP_A555 (0x5 << 3)
-#define WPALCON_W1PAL_16BPP_565 (0x6 << 3)
-
-#define WPALCON_W0PAL_MASK (0x7 << 0)
-#define WPALCON_W0PAL_SHIFT (0)
-#define WPALCON_W0PAL_25BPP_A888 (0x0 << 0)
-#define WPALCON_W0PAL_24BPP (0x1 << 0)
-#define WPALCON_W0PAL_19BPP_A666 (0x2 << 0)
-#define WPALCON_W0PAL_18BPP_A665 (0x3 << 0)
-#define WPALCON_W0PAL_18BPP (0x4 << 0)
-#define WPALCON_W0PAL_16BPP_A555 (0x5 << 0)
-#define WPALCON_W0PAL_16BPP_565 (0x6 << 0)
-
-/* Blending equation control */
-#define BLENDCON (0x260)
-#define BLENDCON_NEW_MASK (1 << 0)
-#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0)
-#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0)
-
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 4/5] driver: Include the modified FIMD header file
From: Leela Krishna Amudala @ 2012-07-31 12:35 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc
Cc: dri-devel, linux-fbdev, ben-linux, inki.dae, kgene.kim, joshi,
jg1.han, m.szyprowski
In-Reply-To: <1343737385-23337-1-git-send-email-l.krishna@samsung.com>
The fimd register headers have been moved to include/video/
hence, modifying the driver files accordingly.
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/video/s3c-fb.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 29fdbfe..8da90f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,7 +20,7 @@
#include <linux/pm_runtime.h>
#include <drm/exynos_drm.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "exynos_drm_drv.h"
#include "exynos_drm_fbdev.h"
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 69bf9d0..1226fdd 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -26,7 +26,7 @@
#include <linux/pm_runtime.h>
#include <mach/map.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/fb.h>
/* This driver will export a number of framebuffer interfaces depending
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
From: Leela Krishna Amudala @ 2012-07-31 12:35 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc
Cc: dri-devel, linux-fbdev, ben-linux, inki.dae, kgene.kim, joshi,
jg1.han, m.szyprowski
In-Reply-To: <1343737385-23337-1-git-send-email-l.krishna@samsung.com>
The fimd register headers have been moved to include/video/
hence, modifying the machine files accordingly.
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
---
arch/arm/mach-exynos/mach-nuri.c | 2 +-
arch/arm/mach-exynos/mach-origen.c | 2 +-
arch/arm/mach-exynos/mach-smdk4x12.c | 2 +-
arch/arm/mach-exynos/mach-smdkv310.c | 2 +-
arch/arm/mach-exynos/mach-universal_c210.c | 2 +-
arch/arm/mach-exynos/setup-fimd0.c | 2 +-
arch/arm/mach-s3c24xx/mach-smdk2416.c | 2 +-
arch/arm/mach-s3c64xx/mach-anw6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-crag6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-hmt.c | 2 +-
arch/arm/mach-s3c64xx/mach-mini6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-ncp.c | 2 +-
arch/arm/mach-s3c64xx/mach-real6410.c | 2 +-
arch/arm/mach-s3c64xx/mach-smartq5.c | 2 +-
arch/arm/mach-s3c64xx/mach-smartq7.c | 2 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
arch/arm/mach-s5p64x0/mach-smdk6440.c | 2 +-
arch/arm/mach-s5p64x0/mach-smdk6450.c | 2 +-
arch/arm/mach-s5pc100/mach-smdkc100.c | 2 +-
arch/arm/mach-s5pv210/mach-aquila.c | 2 +-
arch/arm/mach-s5pv210/mach-goni.c | 2 +-
arch/arm/mach-s5pv210/mach-smdkv210.c | 2 +-
22 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c
index f98a83a..573a0c4 100644
--- a/arch/arm/mach-exynos/mach-nuri.c
+++ b/arch/arm/mach-exynos/mach-nuri.c
@@ -39,7 +39,7 @@
#include <asm/mach-types.h>
#include <plat/adc.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/regs-serial.h>
#include <plat/cpu.h>
#include <plat/devs.h>
diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c
index 5a12dc2..c69707e 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -31,7 +31,7 @@
#include <video/platform_lcd.h>
#include <plat/regs-serial.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/cpu.h>
#include <plat/devs.h>
#include <plat/sdhci.h>
diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c
index b26beb1..8a8acff 100644
--- a/arch/arm/mach-exynos/mach-smdk4x12.c
+++ b/arch/arm/mach-exynos/mach-smdk4x12.c
@@ -35,7 +35,7 @@
#include <plat/iic.h>
#include <plat/keypad.h>
#include <plat/mfc.h>
-#include <plat/regs-fb.h>
+#include <video/samsung_fimd.h>
#include <plat/regs-serial.h>
#include <plat/sdhci.h>
diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c
index 3cfa688..c2df6e8 100644
--- a/arch/arm/mach-exynos/mach-smdkv310.c
+++ b/arch/arm/mach-exynos/mach-smdkv310.c
@@ -28,7 +28,7 @@
#include <video/platform_lcd.h>
#include <plat/regs-serial.h>
#include <plat/regs-srom.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/cpu.h>
#include <plat/devs.h>
#include <plat/fb.h>
diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c
index 4d1f40d..e6fb471 100644
--- a/arch/arm/mach-exynos/mach-universal_c210.c
+++ b/arch/arm/mach-exynos/mach-universal_c210.c
@@ -39,7 +39,7 @@
#include <plat/fb.h>
#include <plat/mfc.h>
#include <plat/sdhci.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/fimc-core.h>
#include <plat/s5p-time.h>
#include <plat/camport.h>
diff --git a/arch/arm/mach-exynos/setup-fimd0.c b/arch/arm/mach-exynos/setup-fimd0.c
index 07a6dbe..53c4c51 100644
--- a/arch/arm/mach-exynos/setup-fimd0.c
+++ b/arch/arm/mach-exynos/setup-fimd0.c
@@ -14,7 +14,7 @@
#include <linux/gpio.h>
#include <plat/gpio-cfg.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <mach/map.h>
diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c b/arch/arm/mach-s3c24xx/mach-smdk2416.c
index c3100a0..c8d5f51 100644
--- a/arch/arm/mach-s3c24xx/mach-smdk2416.c
+++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c
@@ -52,7 +52,7 @@
#include <plat/udc.h>
#include <linux/platform_data/s3c-hsudc.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/fb.h>
#include <plat/common-smdk.h>
diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c b/arch/arm/mach-s3c64xx/mach-anw6410.c
index ffa29dd..27e3087 100644
--- a/arch/arm/mach-s3c64xx/mach-anw6410.c
+++ b/arch/arm/mach-s3c64xx/mach-anw6410.c
@@ -44,7 +44,7 @@
#include <plat/regs-serial.h>
#include <plat/iic.h>
#include <plat/fb.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/clock.h>
#include <plat/devs.h>
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 09cd812..66e8c69 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -57,7 +57,7 @@
#include <mach/regs-gpio-memport.h>
#include <plat/regs-serial.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/fb.h>
#include <plat/sdhci.h>
#include <plat/gpio-cfg.h>
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index 6890881..ab78c5e 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -41,7 +41,7 @@
#include <plat/clock.h>
#include <plat/devs.h>
#include <plat/cpu.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
index 5539a25..4b9a9ff 100644
--- a/arch/arm/mach-s3c64xx/mach-mini6410.c
+++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
@@ -41,7 +41,7 @@
#include <plat/nand.h>
#include <plat/regs-serial.h>
#include <plat/ts.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <video/platform_lcd.h>
diff --git a/arch/arm/mach-s3c64xx/mach-ncp.c b/arch/arm/mach-s3c64xx/mach-ncp.c
index cad2e05..d4c8af0 100644
--- a/arch/arm/mach-s3c64xx/mach-ncp.c
+++ b/arch/arm/mach-s3c64xx/mach-ncp.c
@@ -43,7 +43,7 @@
#include <plat/clock.h>
#include <plat/devs.h>
#include <plat/cpu.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
index 326b216..05f05d2 100644
--- a/arch/arm/mach-s3c64xx/mach-real6410.c
+++ b/arch/arm/mach-s3c64xx/mach-real6410.c
@@ -42,7 +42,7 @@
#include <plat/nand.h>
#include <plat/regs-serial.h>
#include <plat/ts.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <video/platform_lcd.h>
diff --git a/arch/arm/mach-s3c64xx/mach-smartq5.c b/arch/arm/mach-s3c64xx/mach-smartq5.c
index d6266d8..aa225ff 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq5.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq5.c
@@ -28,7 +28,7 @@
#include <plat/devs.h>
#include <plat/fb.h>
#include <plat/gpio-cfg.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
#include "mach-smartq.h"
diff --git a/arch/arm/mach-s3c64xx/mach-smartq7.c b/arch/arm/mach-s3c64xx/mach-smartq7.c
index 0957d2a..6e9c070 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq7.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq7.c
@@ -28,7 +28,7 @@
#include <plat/devs.h>
#include <plat/fb.h>
#include <plat/gpio-cfg.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
#include "mach-smartq.h"
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 0fe4f15..1803192 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -72,7 +72,7 @@
#include <plat/ts.h>
#include <plat/keypad.h>
#include <plat/backlight.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6440.c b/arch/arm/mach-s5p64x0/mach-smdk6440.c
index 92fefad..0db0bdd 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6440.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6440.c
@@ -52,7 +52,7 @@
#include <plat/s5p-time.h>
#include <plat/backlight.h>
#include <plat/fb.h>
-#include <plat/regs-fb.h>
+#include <video/smasung_fimd.h>
#include <plat/sdhci.h>
#include "common.h"
diff --git a/arch/arm/mach-s5p64x0/mach-smdk6450.c b/arch/arm/mach-s5p64x0/mach-smdk6450.c
index e2335ec..c641d33 100644
--- a/arch/arm/mach-s5p64x0/mach-smdk6450.c
+++ b/arch/arm/mach-s5p64x0/mach-smdk6450.c
@@ -52,7 +52,7 @@
#include <plat/s5p-time.h>
#include <plat/backlight.h>
#include <plat/fb.h>
-#include <plat/regs-fb.h>
+#include <video/samsung_fimd.h>
#include <plat/sdhci.h>
#include "common.h"
diff --git a/arch/arm/mach-s5pc100/mach-smdkc100.c b/arch/arm/mach-s5pc100/mach-smdkc100.c
index 0c3ae38..e4df3d0 100644
--- a/arch/arm/mach-s5pc100/mach-smdkc100.c
+++ b/arch/arm/mach-s5pc100/mach-smdkc100.c
@@ -51,7 +51,7 @@
#include <plat/ts.h>
#include <plat/audio.h>
#include <plat/backlight.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
diff --git a/arch/arm/mach-s5pv210/mach-aquila.c b/arch/arm/mach-s5pv210/mach-aquila.c
index 78028df..8cbe4ac 100644
--- a/arch/arm/mach-s5pv210/mach-aquila.c
+++ b/arch/arm/mach-s5pv210/mach-aquila.c
@@ -39,7 +39,7 @@
#include <plat/fimc-core.h>
#include <plat/sdhci.h>
#include <plat/s5p-time.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include "common.h"
diff --git a/arch/arm/mach-s5pv210/mach-goni.c b/arch/arm/mach-s5pv210/mach-goni.c
index 822a559..e799a02 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -49,7 +49,7 @@
#include <plat/clock.h>
#include <plat/s5p-time.h>
#include <plat/mfc.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/camport.h>
#include <media/v4l2-mediabus.h>
diff --git a/arch/arm/mach-s5pv210/mach-smdkv210.c b/arch/arm/mach-s5pv210/mach-smdkv210.c
index 918b23d..3c569e5 100644
--- a/arch/arm/mach-s5pv210/mach-smdkv210.c
+++ b/arch/arm/mach-s5pv210/mach-smdkv210.c
@@ -46,7 +46,7 @@
#include <plat/fb.h>
#include <plat/s5p-time.h>
#include <plat/backlight.h>
-#include <plat/regs-fb-v4.h>
+#include <video/samsung_fimd.h>
#include <plat/mfc.h>
#include <plat/clock.h>
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
From: Leela Krishna Amudala @ 2012-07-31 12:35 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc
Cc: dri-devel, linux-fbdev, ben-linux, inki.dae, kgene.kim, joshi,
jg1.han, m.szyprowski
In-Reply-To: <1343737385-23337-1-git-send-email-l.krishna@samsung.com>
Exynos5 has VIDTCON and VIDCON registers at different offsets
from the previous SOCs. Hence, adding the macros.
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
---
include/video/samsung_fimd.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index e979f42..820f190 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -524,3 +524,10 @@
* 1110 -none- -none- -none- -none- -none-
* 1111 -none- -none- -none- -none- -none-
*/
+
+/*EXYNOS5 FIMD REG OFFSET */
+#define EXYNOS5_VIDTCON0 (0x20010)
+#define EXYNOS5_VIDTCON1 (0x20014)
+#define EXYNOS5_VIDTCON2 (0x20018)
+#define EXYNOS5_VIDTCON3 (0x2001C)
+#define EXYNOS5_VIDCON1 (0x20004)
--
1.7.0.4
^ permalink raw reply related
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