* [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
* [PATCH V2 1/5] include/video: Add samsung FIMD register header
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>
This patch copies the contents from regs-fb-v4.h and regs-fb.h to
include/video/samsung_fimd.h
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
---
include/video/samsung_fimd.h | 526 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 526 insertions(+), 0 deletions(-)
create mode 100644 include/video/samsung_fimd.h
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
new file mode 100644
index 0000000..e979f42
--- /dev/null
+++ b/include/video/samsung_fimd.h
@@ -0,0 +1,526 @@
+/* include/video/samsung_fimd.h
+ *
+ * Copyright 2008 Openmoko, Inc.
+ * Copyright 2008 Simtec Electronics
+ * http://armlinux.simtec.co.uk/
+ * Ben Dooks <ben@simtec.co.uk>
+ *
+ * S3C Platform - new-style fimd and framebuffer register definitions
+ *
+ * This is the register set for the fimd and 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.
+ *
+ * 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.
+*/
+
+/* 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)
+
+#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-
+*/
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
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
This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side
to include/video/samsung_fimd.h
This patchset is created and rebased against master branch of torvalds tree.
Tested on smdk5250 board, build tested for other boards.
Changes from version 1:
- Split the patches as per Sylwester comments
- Changed FIMD_V8_xxx macro to EXYNOS5_xxx
Leela Krishna Amudala (5):
include/video: Add samsung FIMD register header
include/video: Add Exynos5 specific FIMD register offsets
arm: samsung: Include the modified FIMD header file
driver: Include the modified FIMD header file
arm: samsung: delete frame buffer header files from platform
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 +-
arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --------------------
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/video/s3c-fb.c | 2 +-
.../plat/regs-fb.h => include/video/samsung_fimd.h | 152 +++++++++++++++++--
26 files changed, 165 insertions(+), 194 deletions(-)
delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h
rename arch/arm/plat-samsung/include/plat/regs-fb.h => include/video/samsung_fimd.h (74%)
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mitch Bradley @ 2012-07-31 12:22 UTC (permalink / raw)
To: Thierry Reding
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: <20120731105640.GD16155-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
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.
>
> Thierry
>
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: mxs: Add alternative I2C muxing options for imx28
From: Fabio Estevam @ 2012-07-31 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1343730576-20494-3-git-send-email-maxime.ripard@free-electrons.com>
On Tue, Jul 31, 2012 at 7:29 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> + i2c0_pins_b: i2c0@1 {
> + reg = <1>;
> + fsl,pinmux-ids = <0x3001 0x3011>;
Can you please also list the name of the pin as comment (just like you
did for pwm4)?
This would allow us to quickly identify the muxing option without the
need of looking at the mxs pinctrl doc.
Regards,
Fabio Estevam
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-07-31 10:56 UTC (permalink / raw)
To: Alex Courbot
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, 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: <5017B434.2010706-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2169 bytes --]
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.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Thierry Reding @ 2012-07-31 10:46 UTC (permalink / raw)
To: Alex Courbot
Cc: Simon Glass, Stephen Warren, Grant Likely, Rob Herring,
Greg Kroah-Hartman, Mark Brown, 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: <5017AF5D.2010204-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4848 bytes --]
On Tue, Jul 31, 2012 at 07:11:41PM +0900, Alex Courbot wrote:
> On 07/31/2012 06:13 PM, Thierry Reding wrote:
> >>I don't see any need for microseconds myself - anybody sees use for
> >>finer-grained delays?
> >>
> >>Btw, I noticed I was using mdelay instead of msleep - caught and fixed that.
> >
> >You might want to take a look at Documentation/timers/timers-howto.txt.
> >msleep() isn't very accurate for periods shorter than 20 ms.
>
> Ok, looks like usleep_range is the way to go here. In that case it
> would probably not hurt to specify delays in microseconds in the DT
> and platform data as well.
>
> >>>>+Device tree
> >>>>+-----------
> >>>>+All the same, power sequences can be encoded as device tree nodes. The following
> >>>>+properties and nodes are equivalent to the platform data defined previously:
> >>>>+
> >>>>+ power-supply = <&mydevice_reg>;
> >>>>+ enable-gpio = <&gpio 6 0>;
> >>>>+
> >>>>+ power-on-sequence {
> >>>>+ regulator@0 {
> >>>>+ id = "power";
> >>>
> >>>Is there a reason not to put the phandle here, like:
> >>>
> >>> id = <&mydevice_reg>;
> >>>
> >>>(or maybe 'device' instead of id?)
> >>
> >>There is one reason, but it might be a bad one. On Tegra, PWM
> >>phandle uses an extra cell to encode the duty-cycle the PWM should
> >>have when we call get_pwm().
> >
> >This is not only the case on Tegra, but it is the default unless a
> >driver specifically overrides it. The second cell specifies the index of
> >the PWM device within the PWM chip. The third cell doesn't specify the
> >duty cycle but the period of the PWM.
>
> Then I think there is a mistake in
> Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt:
>
> "the second cell is the duty cycle in nanoseconds."
Yes, that's a mistake. =\
> >>This makes it possible to address the
> >>same PWM with different phandles (and different duty cycles),
> >
> >How so? A phandle will always refer to a PWM chip. Paired with the
> >second cell, of_pwm_request() will resolve that into the correct PWM
> >device.
>
> For tegra, we can only address PWMs this way IIRC:
>
> pwm = <&pwm 2 5000000>;
>
> If we had <&pwm 2>, I agree that there would be no problem. But here
> the period of the PWM is also given - and in practice, we can
> request the same PWM using different phandles. For instance, if the
> above property was part of the power-on sequence, and the following
>
> pwm = <&pwm 2 0>;
>
> was part of power-off, how can I know that these two different
> phandles refer to the same PWM without calling pwm_get a second time
> and getting -EBUSY?
You should specify the same period regardless of the sequence. But you
are right, you still cannot request the device twice.
> Of course if the same period is specified for both, I will not have
> this issue as the phandles will be identical, but the possibility
> remains open that we are given a faulty tree here.
I think the phandle is in fact only the reference to the PWM chip, that
is: &pwm. The second cell, the PWM index, is part of the PWM specifier.
However the issue doesn't go away if you drop the period cell because
you still won't be able to request the PWM device a second time. How is
this solved for regulators and GPIOs? At least for GPIOs I'm pretty sure
that you can't request them more than once either.
> More generally speaking, wouldn't it make more sense to have the
> period/duty cycle of a PWM encoded into separate properties when
> needed and have the phandle just reference the PWM instance? This
> also seems to stand from an API point of view, since the period is
> not specified when invoking pwm_request or pwm_get, but set by its
> own pwm_set_period function?
The problem with specifying the period in a separate property is how to
map them to the correct PWM device. From a hardware description point of
view, making the period part of the specifier makes a lot of sense and
hardware description is what DT is about.
> On an unrelated note, I also don't understand why the period is also
> a parameter of pwm_config and why pwm_set_period does not do
> anything beyond setting a struct member that is returned by
> pwm_get_period (but maybe I am missing something here).
pwm_config() is the legacy API that we need to support for compatibility
reasons. Eventually this interface should probably be changed.
pwm_get_period() and pwm_set_period() were merely introduced to support
DT, but I could imagine them becoming the canonical way for configuring
PWM devices in the future, perhaps with a complementary
pwm_set_duty_cycle().
But first we need to convert drivers and users.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Alex Courbot @ 2012-07-31 10:32 UTC (permalink / raw)
To: Stephen Warren
Cc: Stephen Warren, Thierry Reding, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Mark Brown, 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: <50170EA0.1010408@wwwdotorg.org>
On 07/31/2012 07:45 AM, Stephen Warren wrote:
>> +- Delay to wait before performing the action,
>> +- Delay to wait after performing the action.
>
> I don't see a need to have a delay both before and after an action;
> except at the start of the sequence, step n's post-delay is at the same
> point in the sequence as step n+1's pre-delay. Perhaps make a "delay"
> step type?
My first version used this actually - and you're right, having a "delay"
step type would be more flexible and less redundant.
>> +Both new resources and parameters can be introduced, but the goal is of course
>> +to keep things as simple and compact as possible.
>
>> +The platform data is a simple array of platform_power_seq_step instances, each
>
> Rather than jumping straight into platform data here, I'd expect an
> enumeration of legal resource types, and what actions can be performed
> on each, followed by a description of a sequence (very simply, just a
> list of actions and their parameters). This could be followed by a
> section describing the mapping of the abstract concepts to concrete
> platform data representation (and concrete device tree representation).
Keeping that in mind for the next revision.
>> +instance describing a step. The type as well as one of id or gpio members
>> +(depending on the type) must be specified. The last step must be of type
>> +POWER_SEQ_STOP.
>
> I'd certainly suggest having a step count rather than a sentinel value
> in the list.
As Thierry did - I think I will go that way.
>> Regulator and PWM resources are identified by name. GPIO are
>> +identified by number.
>
> That's a little implementation-specific. I guess it's entirely true for
> a platform data representation, but not when mapping this into device tree.
If we can come with a way to properly use phandles within DT sequences
(and we should), then this will only apply to platform data.
>> +You will need an instance of power_seq_resources to keep track of the resources
>> +that are already allocated. On success, the function returns a devm allocated
>> +resolved sequence that is ready to be passed to power_seq_run(). In case of
>> +failure, and error code is returned.
>
> If the result is devm-allocated, the function probably should be named
> devm_power_seq_build().
Right - more generally this needs to have both devm and non-devm variants.
> 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?
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.
> You can make a custom devm free routine for the power_seq_resources
> itself, so the overall free'ing of the content can be triggered by devm,
> but the free'ing function can then call whatever non-devm APIs it wants
> for the non-devm-allocated members.
That sounds good.
>> +Device tree
>> +-----------
>> +All the same, power sequences can be encoded as device tree nodes. The following
>> +properties and nodes are equivalent to the platform data defined previously:
>> +
>> + power-supply = <&mydevice_reg>;
>> + enable-gpio = <&gpio 6 0>;
>> +
>> + power-on-sequence {
>> + regulator@0 {
>
> As Thierry mentioned, the step nodes should be named for the type of
> object they are (a "step") not the type or name of resource they act
> upon ("regulator" or "gpio").
Will fix that.
> 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?
>> + id = "power";
>
> "id" is usually a name or identifier. I think you mean "type" or perhaps
> "action" here:
>
> type = "regulator";
> action = "enable";
>
> or:
>
> action = "enable-regulator";
Right, that was a clear misuse.
> Oh I see. That's a little confusing. Why not just reference the relevant
> resources directly in each step; something more like:
>
> gpio@1 {
> action = "enable-gpio";
> gpio = <&gpio 1 0>;
> };
>
> I guess that might make parsing/building a little harder, since you'd
> have to detect when you'd already done gpio_request() on a given GPIO
> and not repeat it or something like that, but to me this makes the DT a
> lot easier to comprehend.
You can see my reply to Thierry for the reason - the only issue with
that is caused by PWM phandles. If we overcome this, then I agree we
should use phandles. The code should not even get more complex as I have
to check whether a resource is already allocated with strings as well.
Thanks,
Alex.
^ permalink raw reply
* [PATCH 4/4] ARM: dts: mxs: add oled support for the cfa-10036
From: Maxime Ripard @ 2012-07-31 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1343730576-20494-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
arch/arm/boot/dts/imx28-cfa10036.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts b/arch/arm/boot/dts/imx28-cfa10036.dts
index c03a577..92784a9 100644
--- a/arch/arm/boot/dts/imx28-cfa10036.dts
+++ b/arch/arm/boot/dts/imx28-cfa10036.dts
@@ -33,11 +33,31 @@
};
apbx@80040000 {
+ pwm: pwm@80064000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm4_pins_a>;
+ status = "okay";
+ };
+
duart: serial@80074000 {
pinctrl-names = "default";
pinctrl-0 = <&duart_pins_b>;
status = "okay";
};
+
+ i2c0: i2c@80058000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_b>;
+ status = "okay";
+
+ ssd1307: oled@3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ oled-reset-gpio = <&gpio2 7 1>;
+ oled-reset-active-low;
+ };
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: mxs: Add pwm4 muxing options for imx28
From: Maxime Ripard @ 2012-07-31 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1343730576-20494-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
arch/arm/boot/dts/imx28.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 44ce1fd..98891d8 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -461,6 +461,16 @@
fsl,pull-up = <0>;
};
+ pwm4_pins_a: pwm4@0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ 0x31d0 /* MX28_PAD_PWM4__PWM_4 */
+ >;
+ fsl,drive-strength = <0>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <0>;
+ };
+
lcdif_24bit_pins_a: lcdif-24bit@0 {
reg = <0>;
fsl,pinmux-ids = <
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: mxs: Add alternative I2C muxing options for imx28
From: Maxime Ripard @ 2012-07-31 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1343730576-20494-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
arch/arm/boot/dts/imx28.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 915db89..44ce1fd 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -410,6 +410,14 @@
fsl,pull-up = <1>;
};
+ i2c0_pins_b: i2c0@1 {
+ reg = <1>;
+ fsl,pinmux-ids = <0x3001 0x3011>;
+ fsl,drive-strength = <1>;
+ fsl,voltage = <1>;
+ fsl,pull-up = <1>;
+ };
+
saif0_pins_a: saif0@0 {
reg = <0>;
fsl,pinmux-ids = <
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/4] video: Add support for the Solomon SSD1307 OLED Controller
From: Maxime Ripard @ 2012-07-31 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1343730576-20494-1-git-send-email-maxime.ripard@free-electrons.com>
This patch adds support for the Solomon SSD1307 OLED
controller found on the Crystalfontz CFA10036 board.
This controller can drive a display with a resolution up
to 128x39 and can operate over I2C or SPI.
The current driver has only been tested on the CFA-10036,
that is using this controller over I2C to driver a 96x16
OLED screen.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Brian Lilly <brian@crystalfontz.com>
---
.../devicetree/bindings/video/ssd1307fb.txt | 24 ++
drivers/video/Kconfig | 14 +
drivers/video/Makefile | 1 +
drivers/video/ssd1307fb.c | 418 ++++++++++++++++++++
4 files changed, 457 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/ssd1307fb.txt
create mode 100644 drivers/video/ssd1307fb.c
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
new file mode 100644
index 0000000..791e14f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -0,0 +1,24 @@
+* Solomon SSD1307 Framebuffer Driver
+
+Required properties:
+ - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
+ now is i2c.
+ - reg: Should contain address of the controller on the I2C bus. Most likely
+ 0x3c or 0x3d
+ - pwm: Should contain the pwm to use according to the OF device tree PWM
+ specification [0]
+ - oled-reset-gpio: Should contain the GPIO used to reset the OLED display
+
+Optional properties:
+ - oled-reset-active-low: Is the reset gpio is active on physical low?
+
+[0]: Documentation/devicetree/bindings/pwm/pwm.txt
+
+Examples:
+ssd1307: oled@3c {
+ compatible = "solomon,ssd1307fb-i2c";
+ reg = <0x3c>;
+ pwms = <&pwm 4 3000>;
+ oled-reset-gpio = <&gpio2 7 1>;
+ oled-reset-active-low;
+};
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..21ae6dd 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2469,4 +2469,18 @@ config FB_SH_MOBILE_MERAM
Up to 4 memory channels can be configured, allowing 4 RGB or
2 YCbCr framebuffers to be configured.
+
+config FB_SSD1307
+ tristate "Solomon SSD1307 framebuffer support"
+ depends on FB && I2C
+ select FB_SYS_FOPS
+ select FB_SYS_FILLRECT
+ select FB_SYS_COPYAREA
+ select FB_SYS_IMAGEBLIT
+ select FB_DEFERRED_IO
+ select PWM
+ help
+ This driver implements support for the Solomon SSD1307
+ OLED controller over I2C.
+
endmenu
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index ee8dafb..6bbb72c 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_FB_BFIN_7393) += bfin_adv7393fb.o
obj-$(CONFIG_FB_MX3) += mx3fb.o
obj-$(CONFIG_FB_DA8XX) += da8xx-fb.o
obj-$(CONFIG_FB_MXS) += mxsfb.o
+obj-$(CONFIG_FB_SSD1307) += ssd1307fb.o
# the test framebuffer is last
obj-$(CONFIG_FB_VIRTUAL) += vfb.o
diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
new file mode 100644
index 0000000..c705ab4
--- /dev/null
+++ b/drivers/video/ssd1307fb.c
@@ -0,0 +1,418 @@
+/*
+ * Driver for the Solomon SSD1307 OLED controler
+ *
+ * Copyright 2012 Free Electrons
+ *
+ * Licensed under the GPLv2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/i2c.h>
+#include <linux/fb.h>
+#include <linux/uaccess.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/pwm.h>
+#include <linux/delay.h>
+
+#define SSD1307FB_WIDTH 96
+#define SSD1307FB_HEIGHT 16
+
+#define SSD1307FB_DATA 0x40
+#define SSD1307FB_COMMAND 0x80
+
+#define SSD1307FB_CONTRAST 0x81
+#define SSD1307FB_SEG_REMAP_ON 0xa1
+#define SSD1307FB_DISPLAY_OFF 0xae
+#define SSD1307FB_DISPLAY_ON 0xaf
+#define SSD1307FB_START_PAGE_ADDRESS 0xb0
+
+struct ssd1307fb_par {
+ struct i2c_client *client;
+ struct fb_info *info;
+ struct pwm_device *pwm;
+ u32 pwm_period;
+ int reset;
+};
+
+static struct fb_fix_screeninfo ssd1307fb_fix __devinitdata = {
+ .id = "Solomon SSD1307",
+ .type = FB_TYPE_PACKED_PIXELS,
+ .visual = FB_VISUAL_MONO10,
+ .xpanstep = 0,
+ .ypanstep = 0,
+ .ywrapstep = 0,
+ .line_length = SSD1307FB_WIDTH / 8,
+ .accel = FB_ACCEL_NONE,
+};
+
+static struct fb_var_screeninfo ssd1307fb_var __devinitdata = {
+ .xres = SSD1307FB_WIDTH,
+ .yres = SSD1307FB_HEIGHT,
+ .xres_virtual = SSD1307FB_WIDTH,
+ .yres_virtual = SSD1307FB_HEIGHT,
+ .bits_per_pixel = 1,
+};
+
+static int ssd1307fb_write_array(struct i2c_client *client, u8 type, u8* cmd, u32 len)
+{
+ u8 *buf;
+ int ret = 0;
+
+ buf = kzalloc(len + 1, GFP_KERNEL);
+ if (!buf) {
+ dev_err(&client->dev, "Couldn't allocate sending buffer.\n");
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ buf[0] = type;
+ memcpy(buf + 1, cmd, len);
+
+ ret = i2c_master_send(client, buf, len + 1);
+ if (ret != len + 1) {
+ dev_err(&client->dev, "Couldn't send I2C command.\n");
+ goto error;
+ }
+
+error:
+ kfree(buf);
+out:
+ return ret;
+}
+
+static inline int ssd1307fb_write_cmd_array(struct i2c_client *client, u8* cmd, u32 len)
+{
+ return ssd1307fb_write_array(client, SSD1307FB_COMMAND, cmd, len);
+}
+
+static inline int ssd1307fb_write_cmd(struct i2c_client *client, u8 cmd)
+{
+ return ssd1307fb_write_cmd_array(client, &cmd, 1);
+}
+
+static inline int ssd1307fb_write_data_array(struct i2c_client *client, u8* cmd, u32 len)
+{
+ return ssd1307fb_write_array(client, SSD1307FB_DATA, cmd, len);
+}
+
+static inline int ssd1307fb_write_data(struct i2c_client *client, u8 data)
+{
+ return ssd1307fb_write_data_array(client, &data, 1);
+}
+
+static int ssd1307fb_set(struct i2c_client *client, u8 value)
+{
+ int i, j, ret;
+
+ for (i = 1; i <= (SSD1307FB_HEIGHT / 8); i++) {
+ ret = ssd1307fb_write_cmd(client, SSD1307FB_START_PAGE_ADDRESS + i);
+ if (ret < 0)
+ goto i2c_error;
+
+ ret = ssd1307fb_write_cmd(client, 0x00);
+ if (ret < 0)
+ goto i2c_error;
+
+ ret = ssd1307fb_write_cmd(client, 0x10);
+ if (ret < 0)
+ goto i2c_error;
+
+ for (j = 0; j < SSD1307FB_WIDTH; j++)
+ ssd1307fb_write_data(client, value);
+ }
+
+ return 0;
+
+i2c_error:
+ dev_err(&client->dev, "Couldn't send i2c command: %d\n", ret);
+ return ret;
+}
+
+static void ssd1307fb_update_display(struct ssd1307fb_par *par)
+{
+ u8 *vmem = par->info->screen_base;
+ int i, j, k;
+
+ /*
+ * The screen is divided in pages, each having a height of 8
+ * pixels, and the width of the screen. When sending a byte of
+ * data to the controller, it gives the 8 bits for the current
+ * column. I.e, the first byte are the 8 bits of the first
+ * column, then the 8 bits for the second column, etc.
+ *
+ *
+ * Representation of the screen, assuming it is 5 bits
+ * wide. Each letter-number combination is a bit that controls
+ * one pixel.
+ *
+ * A0 A1 A2 A3 A4
+ * B0 B1 B2 B3 B4
+ * C0 C1 C2 C3 C4
+ * D0 D1 D2 D3 D4
+ * E0 E1 E2 E3 E4
+ * F0 F1 F2 F3 F4
+ * G0 G1 G2 G3 G4
+ * H0 H1 H2 H3 H4
+ *
+ * If you want to update this screen, you need to send 5 bytes:
+ * (1) A0 B0 C0 D0 E0 F0 G0 H0
+ * (2) A1 B1 C1 D1 E1 F1 G1 H1
+ * (3) A2 B2 C2 D2 E2 F2 G2 H2
+ * (4) A3 B3 C3 D3 E3 F3 G3 H3
+ * (5) A4 B4 C4 D4 E4 F4 G4 H4
+ */
+
+ for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
+ ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + (i + 1));
+ ssd1307fb_write_cmd(par->client, 0x00);
+ ssd1307fb_write_cmd(par->client, 0x10);
+
+ for (j = 0; j < SSD1307FB_WIDTH; j++) {
+ u8 buf = 0;
+ for (k = 0; k < 8; k++) {
+ u32 page_length = SSD1307FB_WIDTH * i;
+ u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
+ u8 byte = *(vmem + index);
+ u8 bit = byte & (1 << (7 - (j % 8)));
+ bit = bit >> (7 - (j % 8));
+ buf |= bit << k;
+ }
+ ssd1307fb_write_data(par->client, buf);
+ }
+ }
+
+ return;
+}
+
+
+static ssize_t ssd1307fb_write(struct fb_info *info, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ struct ssd1307fb_par *par = info->par;
+ unsigned long p = *ppos;
+ void *dst;
+ int err = 0;
+
+ dst = (void __force *) (info->screen_base + p);
+
+ if (copy_from_user(dst, buf, count))
+ err = -EFAULT;
+
+ if (!err)
+ *ppos += count;
+
+ ssd1307fb_update_display(par);
+
+ return (err) ? err : count;
+}
+
+static void ssd1307fb_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
+{
+ struct ssd1307fb_par *par = info->par;
+ sys_fillrect(info, rect);
+ ssd1307fb_update_display(par);
+}
+
+static void ssd1307fb_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+{
+ struct ssd1307fb_par *par = info->par;
+ sys_copyarea(info, area);
+ ssd1307fb_update_display(par);
+}
+
+static void ssd1307fb_imageblit(struct fb_info *info, const struct fb_image *image)
+{
+ struct ssd1307fb_par *par = info->par;
+ sys_imageblit(info, image);
+ ssd1307fb_update_display(par);
+}
+
+static struct fb_ops ssd1307fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_read = fb_sys_read,
+ .fb_write = ssd1307fb_write,
+ .fb_fillrect = ssd1307fb_fillrect,
+ .fb_copyarea = ssd1307fb_copyarea,
+ .fb_imageblit = ssd1307fb_imageblit,
+};
+
+static void ssd1307fb_deferred_io(struct fb_info *info,
+ struct list_head *pagelist)
+{
+ ssd1307fb_update_display(info->par);
+}
+
+static struct fb_deferred_io ssd1307fb_defio = {
+ .delay = HZ,
+ .deferred_io = ssd1307fb_deferred_io,
+};
+
+static int __devinit ssd1307fb_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+ struct fb_info *info;
+ u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
+ struct ssd1307fb_par *par;
+ u8 *vmem;
+ int ret;
+
+ if (!client->dev.of_node) {
+ dev_err(&client->dev, "No device tree data found!\n");
+ ret = -EINVAL;
+ goto generic_error;
+ }
+
+ info = framebuffer_alloc(sizeof(struct ssd1307fb_par), &client->dev);
+ if (!info) {
+ ret = -ENOMEM;
+ goto generic_error;
+ }
+
+ vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
+ if (!vmem) {
+ dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
+ ret = -ENOMEM;
+ goto generic_error;
+ }
+
+ info->fbops = &ssd1307fb_ops;
+ info->fix = ssd1307fb_fix;
+ info->fbdefio = &ssd1307fb_defio;
+
+ info->var = ssd1307fb_var;
+ info->var.red.length = 1;
+ info->var.red.offset = 0;
+ info->var.green.length = 1;
+ info->var.green.offset = 0;
+ info->var.blue.length = 1;
+ info->var.blue.offset = 0;
+
+ info->screen_base = (u8 __force __iomem *)vmem;
+ info->fix.smem_start = (unsigned long)vmem;
+ info->fix.smem_len = vmem_size;
+
+ fb_deferred_io_init(info);
+
+ par = info->par;
+ par->info = info;
+ par->client = client;
+
+ par->reset = of_get_named_gpio(client->dev.of_node,
+ "oled-reset-gpio", 0);
+ if (gpio_is_valid(par->reset)) {
+ int flags = GPIOF_OUT_INIT_HIGH;
+ if (of_get_property(client->dev.of_node,
+ "oled-reset-active-low", NULL))
+ flags = GPIOF_OUT_INIT_LOW;
+ ret = devm_gpio_request_one(&client->dev, par->reset,
+ flags, "oled-reset");
+ if (ret) {
+ dev_err(&client->dev,
+ "failed to request gpio %d: %d\n",
+ par->reset, ret);
+ goto reset_oled_error;
+ }
+ }
+
+ par->pwm = pwm_get(&client->dev, NULL);
+ if (IS_ERR(par->pwm)) {
+ dev_err(&client->dev, "Could not get PWM from device tree!\n");
+ ret = PTR_ERR(par->pwm);
+ goto pwm_error;
+ }
+
+ par->pwm_period = pwm_get_period(par->pwm);
+
+ dev_dbg(&client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
+
+ ret = register_framebuffer(info);
+ if (ret) {
+ dev_err(&client->dev, "Couldn't register the framebuffer\n");
+ goto fbreg_error;
+ }
+
+ i2c_set_clientdata(client, info);
+
+ /* Reset the screen */
+ gpio_set_value(par->reset, 1);
+ udelay(4);
+ gpio_set_value(par->reset, 0);
+ udelay(4);
+
+ /* Enable the PWM */
+ pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
+ pwm_enable(par->pwm);
+
+ /* Map column 127 of the OLED to segment 0 */
+ ret = ssd1307fb_write_cmd(client, SSD1307FB_SEG_REMAP_ON);
+ if (ret < 0) {
+ dev_err(&client->dev, "Couldn't remap the screen.\n");
+ goto remap_error;
+ }
+
+ /* Turn on the display */
+ ret = ssd1307fb_write_cmd(client, SSD1307FB_DISPLAY_ON);
+ if (ret < 0) {
+ dev_err(&client->dev, "Couldn't turn the display on.\n");
+ goto remap_error;
+ }
+
+ dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
+
+ return 0;
+
+remap_error:
+ unregister_framebuffer(info);
+ pwm_disable(par->pwm);
+fbreg_error:
+ pwm_put(par->pwm);
+pwm_error:
+reset_oled_error:
+ fb_deferred_io_cleanup(info);
+ framebuffer_release(info);
+generic_error:
+ return ret;
+}
+
+static int __devexit ssd1307fb_remove(struct i2c_client *client)
+{
+ struct fb_info *info = i2c_get_clientdata(client);
+ struct ssd1307fb_par *par = info->par;
+ unregister_framebuffer(info);
+ pwm_disable(par->pwm);
+ pwm_put(par->pwm);
+ fb_deferred_io_cleanup(info);
+ framebuffer_release(info);
+
+ return 0;
+}
+
+static const struct i2c_device_id ssd1307fb_i2c_id[] = {
+ { "ssd1307fb", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
+
+static const struct of_device_id ssd1307fb_of_match[] = {
+ { .compatible = "solomon,ssd1307fb-i2c" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
+
+static struct i2c_driver ssd1307fb_driver = {
+ .probe = ssd1307fb_probe,
+ .remove = __devexit_p(ssd1307fb_remove),
+ .id_table = ssd1307fb_i2c_id,
+ .driver = {
+ .name = "ssd1307fb",
+ .of_match_table = of_match_ptr(ssd1307fb_of_match),
+ .owner = THIS_MODULE,
+ },
+};
+
+module_i2c_driver(ssd1307fb_driver);
+
+MODULE_DESCRIPTION("FB driver for the Solomon SSD1307 OLED controler");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard@free-electrons.com>");
+MODULE_LICENSE("GPL");
--
1.7.9.5
^ 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