* [PATCH] drivers/video/vt8500lcdfb.c: use devm_ functions
From: Julia Lawall @ 2012-12-09 17:21 UTC (permalink / raw)
To: linux-arm-kernel
From: Julia Lawall <Julia.Lawall@lip6.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.
The patch makes some other cleanups. First, the original code used
devm_kzalloc, but kfree. This would lead to a double free. The problem
was found using the following semantic match (http://coccinelle.lip6.fr/):
// <smpl>
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x,...);
// </smpl>
The error-handing code of devm_request_and_ioremap does not print any
warning message, because devm_request_and_ioremap does this.
The first call to dma_alloc_coherent is converted to its devm equivalent,
dmam_alloc_coherent. This implicitly introduces a call to
dmam_free_coherent, which was completly missing in the original code.
A semicolon is removed at the end of the error-handling code for the first
call to dma_alloc_coherent.
The block of code calling fb_alloc_cmap is moved below the block of code
calling vt8500lcd_set_par, so that the error-handing code of the call to
vt8500lcd_set_par can just return ret. This way there is only one block of
error-handling code that needs to call fb_dealloc_cmap, and so this is
moved up to the place where it is needed, eliminating the need for all
gotos and labels in the function. This was suggested by Tony Prisk.
The initializations of fbi and ret at the beginning of the function are not
necessary and are removed. The call platform_set_drvdata(pdev, NULL); at
the end of the function is also removed.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
Only compiled. Not tested.
drivers/video/vt8500lcdfb.c | 107 +++++++++++---------------------------------
1 file changed, 27 insertions(+), 80 deletions(-)
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 9af8da7..fae2456 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -287,15 +287,11 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
unsigned long fb_mem_len;
void *fb_mem_virt;
- ret = -ENOMEM;
- fbi = NULL;
-
fbi = devm_kzalloc(&pdev->dev, sizeof(struct vt8500lcd_info)
- + sizeof(u32) * 16, GFP_KERNEL);
+ + sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(&pdev->dev, "Failed to initialize framebuffer device\n");
- ret = -ENOMEM;
- goto failed;
+ return -ENOMEM;
}
strcpy(fbi->fb.fix.id, "VT8500 LCD");
@@ -326,31 +322,15 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
fbi->fb.pseudo_palette = addr;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res = NULL) {
- dev_err(&pdev->dev, "no I/O memory resource defined\n");
- ret = -ENODEV;
- goto failed_fbi;
- }
- res = request_mem_region(res->start, resource_size(res), "vt8500lcd");
- if (res = NULL) {
- dev_err(&pdev->dev, "failed to request I/O memory\n");
- ret = -EBUSY;
- goto failed_fbi;
- }
-
- fbi->regbase = ioremap(res->start, resource_size(res));
- if (fbi->regbase = NULL) {
- dev_err(&pdev->dev, "failed to map I/O memory\n");
- ret = -EBUSY;
- goto failed_free_res;
- }
+ fbi->regbase = devm_request_and_ioremap(&pdev->dev, res);
+ if (fbi->regbase = NULL)
+ return -EBUSY;
np = of_parse_phandle(pdev->dev.of_node, "default-mode", 0);
if (!np) {
pr_err("%s: No display description in Device Tree\n", __func__);
- ret = -EINVAL;
- goto failed_free_res;
+ return -EINVAL;
}
/*
@@ -369,54 +349,44 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
ret |= of_property_read_u32(np, "bpp", &bpp);
if (ret) {
pr_err("%s: Unable to read display properties\n", __func__);
- goto failed_free_res;
+ return ret;
}
of_mode.vmode = FB_VMODE_NONINTERLACED;
/* try allocating the framebuffer */
fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
- fb_mem_virt = dma_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
+ fb_mem_virt = dmam_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
GFP_KERNEL);
if (!fb_mem_virt) {
pr_err("%s: Failed to allocate framebuffer\n", __func__);
return -ENOMEM;
- };
+ }
fbi->fb.fix.smem_start = fb_mem_phys;
fbi->fb.fix.smem_len = fb_mem_len;
fbi->fb.screen_base = fb_mem_virt;
fbi->palette_size = PAGE_ALIGN(512);
- fbi->palette_cpu = dma_alloc_coherent(&pdev->dev,
+ fbi->palette_cpu = dmam_alloc_coherent(&pdev->dev,
fbi->palette_size,
&fbi->palette_phys,
GFP_KERNEL);
if (fbi->palette_cpu = NULL) {
dev_err(&pdev->dev, "Failed to allocate palette buffer\n");
- ret = -ENOMEM;
- goto failed_free_io;
+ return -ENOMEM;
}
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "no IRQ defined\n");
- ret = -ENODEV;
- goto failed_free_palette;
+ return -ENODEV;
}
- ret = request_irq(irq, vt8500lcd_handle_irq, 0, "LCD", fbi);
+ ret = devm_request_irq(&pdev->dev, irq, vt8500lcd_handle_irq, 0,
+ "LCD", fbi);
if (ret) {
dev_err(&pdev->dev, "request_irq failed: %d\n", ret);
- ret = -EBUSY;
- goto failed_free_palette;
- }
-
- init_waitqueue_head(&fbi->wait);
-
- if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
- dev_err(&pdev->dev, "Failed to allocate color map\n");
- ret = -ENOMEM;
- goto failed_free_irq;
+ return -EBUSY;
}
fb_videomode_to_var(&fbi->fb.var, &of_mode);
@@ -428,7 +398,14 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
ret = vt8500lcd_set_par(&fbi->fb);
if (ret) {
dev_err(&pdev->dev, "Failed to set parameters\n");
- goto failed_free_cmap;
+ return ret;
+ }
+
+ init_waitqueue_head(&fbi->wait);
+
+ if (fb_alloc_cmap(&fbi->fb.cmap, 256, 0) < 0) {
+ dev_err(&pdev->dev, "Failed to allocate color map\n");
+ return -ENOMEM;
}
writel(fbi->fb.fix.smem_start >> 22, fbi->regbase + 0x1c);
@@ -440,7 +417,10 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
if (ret < 0) {
dev_err(&pdev->dev,
"Failed to register framebuffer device: %d\n", ret);
- goto failed_free_cmap;
+ if (fbi->fb.cmap.len)
+ fb_dealloc_cmap(&fbi->fb.cmap);
+ platform_set_drvdata(pdev, NULL);
+ return ret;
}
/*
@@ -449,31 +429,11 @@ static int __devinit vt8500lcd_probe(struct platform_device *pdev)
writel(readl(fbi->regbase) | 1, fbi->regbase);
return 0;
-
-failed_free_cmap:
- if (fbi->fb.cmap.len)
- fb_dealloc_cmap(&fbi->fb.cmap);
-failed_free_irq:
- free_irq(irq, fbi);
-failed_free_palette:
- dma_free_coherent(&pdev->dev, fbi->palette_size,
- fbi->palette_cpu, fbi->palette_phys);
-failed_free_io:
- iounmap(fbi->regbase);
-failed_free_res:
- release_mem_region(res->start, resource_size(res));
-failed_fbi:
- platform_set_drvdata(pdev, NULL);
- kfree(fbi);
-failed:
- return ret;
}
static int __devexit vt8500lcd_remove(struct platform_device *pdev)
{
struct vt8500lcd_info *fbi = platform_get_drvdata(pdev);
- struct resource *res;
- int irq;
unregister_framebuffer(&fbi->fb);
@@ -482,19 +442,6 @@ static int __devexit vt8500lcd_remove(struct platform_device *pdev)
if (fbi->fb.cmap.len)
fb_dealloc_cmap(&fbi->fb.cmap);
- irq = platform_get_irq(pdev, 0);
- free_irq(irq, fbi);
-
- dma_free_coherent(&pdev->dev, fbi->palette_size,
- fbi->palette_cpu, fbi->palette_phys);
-
- iounmap(fbi->regbase);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, resource_size(res));
-
- kfree(fbi);
-
return 0;
}
^ permalink raw reply related
* Re: [Bulk] [PATCH] drivers/video/wm8505fb.c: use devm_ functions
From: Tony Prisk @ 2012-12-09 23:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355076491-2246-1-git-send-email-Julia.Lawall@lip6.fr>
On Sun, 2012-12-09 at 19:08 +0100, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.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.
>
> The patch makes some other cleanups. First, the original code used
> devm_kzalloc, but kfree. This would lead to a double free. The problem
> was found using the following semantic match (http://coccinelle.lip6.fr/):
>
> // <smpl>
> @@
> expression x,e;
> @@
> x = devm_kzalloc(...)
> ... when != x = e
> ?-kfree(x,...);
> // </smpl>
>
> The error-handing code of devm_request_and_ioremap does not print any
> warning message, because devm_request_and_ioremap does this.
>
> The call to dma_alloc_coherent is converted to its devm equivalent,
> dmam_alloc_coherent. This implicitly introduces a call to
> dmam_free_coherent, which was completly missing in the original code.
>
> A semicolon is removed at the end of the error-handling code for the call
> to dma_alloc_coherent.
>
> The block of code calling fb_alloc_cmap is moved below the block of code
> calling wm8505fb_set_par, so that the error-handing code of the call to
> wm8505fb_set_par can just return ret. This way there is only one block of
> error-handling code that needs to call fb_dealloc_cmap, and so this is
> moved up to the place where it is needed, eliminating the need for all
> gotos and labels in the function. This was suggested by Tony Prisk.
>
> The initializations of fbi and ret at the beginning of the function are not
> necessary and are removed. The call platform_set_drvdata(pdev, NULL); at
> the end of the function is also removed.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> Only compiled. Not tested.
Thanks Julia,
I will include this with the other patches we have for fbdev. I have
tested this on WM8650 and all appears fine.
Regards
Tony P
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Archit Taneja @ 2012-12-10 7:46 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1354881309-17625-5-git-send-email-tomi.valkeinen@ti.com>
Hi,
On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
> Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
> display code from omapdss) moved setting up the initial overlay, overlay
> manager, output and display connections from omapdss to omapfb.
>
> However, currently omapfb only handles the connection related to the
> default display, which means that no overlay managers are connected to
> other displays.
>
> This patch changes omapfb to go through all dssdevs, and connect an
> overlay manager to them.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/omapfb/omapfb-main.c | 38 +++++++++++++++++++-----------
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index 1df973e..24739fc 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -2353,27 +2353,37 @@ static int omapfb_init_display(struct omapfb2_device *fbdev,
> }
>
> static int omapfb_init_connections(struct omapfb2_device *fbdev,
> - struct omap_dss_device *dssdev)
> + struct omap_dss_device *def_dssdev)
> {
> int i, r;
> - struct omap_overlay_manager *mgr = NULL;
> + struct omap_overlay_manager *mgr;
>
> - for (i = 0; i < fbdev->num_managers; i++) {
> - mgr = fbdev->managers[i];
> -
> - if (dssdev->channel = mgr->id)
> - break;
> + if (!def_dssdev->output) {
> + dev_err(fbdev->dev, "no output for the default display\n");
> + return -EINVAL;
> }
>
> - if (i = fbdev->num_managers)
> - return -ENODEV;
> + for (i = 0; i < fbdev->num_displays; ++i) {
> + struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
> + struct omap_dss_output *out = dssdev->output;
>
> - if (mgr->output)
> - mgr->unset_output(mgr);
> + mgr = omap_dss_get_overlay_manager(dssdev->channel);
This dssdev->channel reference is something we would want to get rid of
eventually, right?
At the point omapfb_init_connections() is called, we would have all the
omap_dss_devices registered, right? So at this point, omapfb will have
an overall view of how the panels need to be connected to DSS.
I think we can try to find a manager here for dssdev rather than using
dssdev->channel directly. The dssdev's output could connect to a few
managers. We would want to chose managers for each dssdev output in such
a way that all outputs have a manager. I guess there would be multiple
combinations for this, but it would be okay to pick any one of them.
I think we would need some recursive or backtracking sort of approach to
get a desired combination. We can figure about how to make it work
later, but do you agree if this is a right way to get rid of
dssdev->channel?
Also, we would need to do this for omapdrm separately using it's own
encoder/connector entities.
Archit
>
> - r = mgr->set_output(mgr, dssdev->output);
> - if (r)
> - return r;
> + if (!mgr || !out)
> + continue;
> +
> + if (mgr->output)
> + mgr->unset_output(mgr);
> +
> + mgr->set_output(mgr, out);
> + }
> +
> + mgr = def_dssdev->output->manager;
> +
> + if (!mgr) {
> + dev_err(fbdev->dev, "no ovl manager for the default display\n");
> + return -EINVAL;
> + }
>
> for (i = 0; i < fbdev->num_overlays; i++) {
> struct omap_overlay *ovl = fbdev->overlays[i];
>
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Tomi Valkeinen @ 2012-12-10 8:03 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5909E.8030800@ti.com>
[-- Attachment #1: Type: text/plain, Size: 5584 bytes --]
On 2012-12-10 09:34, Archit Taneja wrote:
> Hi,
>
> On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
>> Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
>> display code from omapdss) moved setting up the initial overlay, overlay
>> manager, output and display connections from omapdss to omapfb.
>>
>> However, currently omapfb only handles the connection related to the
>> default display, which means that no overlay managers are connected to
>> other displays.
>>
>> This patch changes omapfb to go through all dssdevs, and connect an
>> overlay manager to them.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> drivers/video/omap2/omapfb/omapfb-main.c | 38
>> +++++++++++++++++++-----------
>> 1 file changed, 24 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
>> b/drivers/video/omap2/omapfb/omapfb-main.c
>> index 1df973e..24739fc 100644
>> --- a/drivers/video/omap2/omapfb/omapfb-main.c
>> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
>> @@ -2353,27 +2353,37 @@ static int omapfb_init_display(struct
>> omapfb2_device *fbdev,
>> }
>>
>> static int omapfb_init_connections(struct omapfb2_device *fbdev,
>> - struct omap_dss_device *dssdev)
>> + struct omap_dss_device *def_dssdev)
>> {
>> int i, r;
>> - struct omap_overlay_manager *mgr = NULL;
>> + struct omap_overlay_manager *mgr;
>>
>> - for (i = 0; i < fbdev->num_managers; i++) {
>> - mgr = fbdev->managers[i];
>> -
>> - if (dssdev->channel == mgr->id)
>> - break;
>> + if (!def_dssdev->output) {
>> + dev_err(fbdev->dev, "no output for the default display\n");
>> + return -EINVAL;
>> }
>>
>> - if (i == fbdev->num_managers)
>> - return -ENODEV;
>> + for (i = 0; i < fbdev->num_displays; ++i) {
>> + struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
>> + struct omap_dss_output *out = dssdev->output;
>>
>> - if (mgr->output)
>> - mgr->unset_output(mgr);
>> + mgr = omap_dss_get_overlay_manager(dssdev->channel);
>
> This dssdev->channel reference is something we would want to get rid of
> eventually, right?
Yes.
> At the point omapfb_init_connections() is called, we would have all the
> omap_dss_devices registered, right? So at this point, omapfb will have
> an overall view of how the panels need to be connected to DSS.
>
> I think we can try to find a manager here for dssdev rather than using
> dssdev->channel directly. The dssdev's output could connect to a few
> managers. We would want to chose managers for each dssdev output in such
> a way that all outputs have a manager. I guess there would be multiple
> combinations for this, but it would be okay to pick any one of them.
>
> I think we would need some recursive or backtracking sort of approach to
> get a desired combination. We can figure about how to make it work
> later, but do you agree if this is a right way to get rid of
> dssdev->channel?
Yes, I think that's a sensible approach. The thing I don't like about it
is that it requires omapfb/omapdrm to create the mgr-output connections.
They shouldn't really be interested in that. All they want is a display
device that works, and a way to get the mgr used for the display.
Well, I think we can hide the implementation inside omapdss, so that
omapfb/omapdrm will just need to call one omapdss func when they are
started, which will connect the mgrs to outputs.
A downside with setting up the mgr-output links at one go, when
omapfb/omapdrm starts, is that it creates a strict load order
restriction between omapdss, panels and omapfb/omapdrm. The drivers will
need to be loaded in that order, or things won't work.
Another option would be to pass information about mgr-output links from
the board files (or DT data) to the omapdss driver, so that omapdss
could setup them at probe time. With this option omapfb/omapdrm doesn't
need to care about this, and it doesn't create load order restriction.
But mgr-output links are something that I'd really like to handle inside
the drivers, not something that needs to be passed via platform data.
Third option, which is the best, but also something I have no idea how
to implement, would be to create the mgr-output links dynamically when
needed. The problem here is, of course, that a mgr could be allocated to
an output, only to be later found out that that particular mgr is needed
for another output.
But this is something we could study a bit: can we create such mgr
allocation system, that no matter what outputs the board uses, it'll
just work.
So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
cannot be used at the same time, we're free to give LCD1 to either one.
And if we know that DPI and DSI2 cannot be used at the same time, we're
also free to give LCD2 to either one. And if that's the case, there are
no conflicts.
I don't know if we can find such allocation for all current omaps, and I
know it's slightly risky as the next omap could have limitations even if
current ones do not.
> Also, we would need to do this for omapdrm separately using it's own
> encoder/connector entities.
Yep. That's also a negative side: both omapfb/omapdrm will need to
implement the same stuff, even if neither of them are really interested
in that stuff.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
From: Steffen Trumtrar @ 2012-12-10 8:28 UTC (permalink / raw)
To: Philipp Zabel
Cc: Tomi Valkeinen, linux-fbdev, Florian Tobias Schandinat,
David Airlie, devicetree-discuss, dri-devel, Laurent Pinchart,
kernel, Guennady Liakhovetski, linux-media
In-Reply-To: <1354889568.2533.118.camel@pizza.hi.pengutronix.de>
Hi,
On Fri, Dec 07, 2012 at 03:12:48PM +0100, Philipp Zabel wrote:
> Hi,
>
> Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
> > On 2012-11-26 18:10, Steffen Trumtrar wrote:
> > > Hi,
> > >
> > > On Mon, Nov 26, 2012 at 04:38:36PM +0200, Tomi Valkeinen wrote:
> >
> > >>> +optional properties:
> > >>> + - hsync-active: hsync pulse is active low/high/ignored
> > >>> + - vsync-active: vsync pulse is active low/high/ignored
> > >>> + - de-active: data-enable pulse is active low/high/ignored
> > >>> + - pixelclk-inverted: pixelclock is inverted (active on falling edge)/
> > >>> + non-inverted (active on rising edge)/
> > >>> + ignored (ignore property)
> > >>
> > >> I think hsync-active and vsync-active are clear, and commonly used, and
> > >> they are used for both drm and fb mode conversions in later patches.
> > >>
> > >> de-active is not used in drm and fb mode conversions, but I think it's
> > >> also clear.
> > >>
> > >> pixelclk-inverted is not used in the mode conversions. It's also a bit
> > >> unclear to me. What does it mean that pix clock is "active on rising
> > >> edge"? The pixel data is driven on rising edge? How about the sync
> > >> signals and DE, when are they driven? Does your HW have any settings
> > >> related to those?
> > >>
> > >
> > > Those are properties commonly found in display specs. That is why they are here.
> > > If the GPU does not support the property it can be omitted.
> >
> > So what does the pixelclk-inverted mean? Normally the SoC drives pixel
> > data on rising edge, and the panel samples it at falling edge? And
> > vice-versa for inverted? Or the other way around?
> >
> > When is hsync/vsync set? On rising or falling edge of pclk?
> >
> > My point here is that the pixelclk-inverted is not crystal clear thing,
> > like the hsync/vsync/de-active values are.
> >
> > And while thinking about this, I realized that the meaning of
> > pixelclk-inverted depends on what component is it applied to. Presuming
> > normal pixclk means "pixel data on rising edge", the meaning of that
> > depends on do we consider the SoC or the panel. The panel needs to
> > sample the data on the other edge from the one the SoC uses to drive the
> > data.
> >
> > Does the videomode describe the panel, or does it describe the settings
> > programmed to the SoC?
>
> How about calling this property pixelclk-active, active high meaning
> driving pixel data on rising edges and sampling on falling edges (the
> pixel clock is high between driving and sampling the data), and active
> low meaning driving on falling edges and sampling on rising edges?
> It is the same from the SoC perspective and from the panel perspective,
> and it mirrors the usage of the other *-active properties.
>
I think, this would not be a bad idea. I would include Philipps description in the
display-timing.txt, as it makes the meaning pretty clear; at least to me.
What do the others think about this?
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCHv15 3/7] video: add of helper for display timings/videomode
From: Tomi Valkeinen @ 2012-12-10 8:45 UTC (permalink / raw)
To: Philipp Zabel
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Florian Tobias Schandinat,
David Airlie, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Laurent Pinchart,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Steffen Trumtrar,
Guennady Liakhovetski, linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1354889568.2533.118.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
On 2012-12-07 16:12, Philipp Zabel wrote:
> Hi,
>
> Am Montag, den 26.11.2012, 18:56 +0200 schrieb Tomi Valkeinen:
>> So what does the pixelclk-inverted mean? Normally the SoC drives pixel
>> data on rising edge, and the panel samples it at falling edge? And
>> vice-versa for inverted? Or the other way around?
>>
>> When is hsync/vsync set? On rising or falling edge of pclk?
>>
>> My point here is that the pixelclk-inverted is not crystal clear thing,
>> like the hsync/vsync/de-active values are.
>>
>> And while thinking about this, I realized that the meaning of
>> pixelclk-inverted depends on what component is it applied to. Presuming
>> normal pixclk means "pixel data on rising edge", the meaning of that
>> depends on do we consider the SoC or the panel. The panel needs to
>> sample the data on the other edge from the one the SoC uses to drive the
>> data.
>>
>> Does the videomode describe the panel, or does it describe the settings
>> programmed to the SoC?
>
> How about calling this property pixelclk-active, active high meaning
> driving pixel data on rising edges and sampling on falling edges (the
> pixel clock is high between driving and sampling the data), and active
> low meaning driving on falling edges and sampling on rising edges?
> It is the same from the SoC perspective and from the panel perspective,
> and it mirrors the usage of the other *-active properties.
This sounds good to me. It's not quite correct, as neither pixelclock or
pixel data are not really "active" when the clock is high/low, but it
still makes sense and is clear (at least with a short description).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] da8xx: Allow use by am33xx based devices
From: Vaibhav Hiremath @ 2012-12-10 9:14 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: Valkeinen, Tomi, davinci-linux-open-source@linux.davincidsp.com,
Porter, Matt, linux-fbdev@vger.kernel.org,
FlorianSchandinat@gmx.de, Koen Kooi, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Dill, Russ,
linux-omap@vger.kernel.org
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC3EA1452B@DBDE01.ent.ti.com>
On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote:
> Hi Tomi,
>
> On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote:
>> Hi,
>>
>> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote:
>>> This driver can be used for AM33xx devices, like the popular beaglebone.
>>>
>>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
>>> ---
>>> drivers/video/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index 9791d10..e7868d8 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -2202,7 +2202,7 @@ config FB_SH7760
>>>
>>> config FB_DA8XX
>>> tristate "DA8xx/OMAP-L1xx Framebuffer support"
>>> - depends on FB && ARCH_DAVINCI_DA8XX
>>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX)
>>
>> Agreed this is present on da8xx and am33xx, but moving forward for
>> supporting DT, we should be avoiding these dependencies. So instead
>> change this to remove machine dependencies.
>>
>
> I could be wrong here, having dependency on platform seems to be right.
> Otherwise may lead to build errors for other platforms.
No, it should not result in to build error unless driver uses some
platform specific api's.
Thanks,
Vaibhav
> Please ignore my
> comments and accept this patch.
>
> Thanks,
> Prakash
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
^ permalink raw reply
* Re: [patch 1/2] drivers/video: add support for the Solomon SSD1307 OLED Controller
From: Tomi Valkeinen @ 2012-12-10 9:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20121207203038.F16D082004A@wpzn4.hot.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]
On 2012-12-07 22:30, akpm@linux-foundation.org wrote:
> From: Maxime Ripard <maxime.ripard@free-electrons.com>
> Subject: drivers/video: add support for the Solomon SSD1307 OLED Controller
>
> Add 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.
>
> [akpm@linux-foundation.org: checkpatch fixes]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Cc: Brian Lilly <brian@crystalfontz.com>
> Cc: Greg KH <gregkh@linux-foundation.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: Thomas Petazzoni <thomas@free-electrons.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> Documentation/devicetree/bindings/video/ssd1307fb.txt | 24
> drivers/video/Kconfig | 15
> drivers/video/Makefile | 1
> drivers/video/ssd1307fb.c | 396 ++++++++++
> 4 files changed, 436 insertions(+)
Thanks, queued for 3.8.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Archit Taneja @ 2012-12-10 9:55 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C59745.2080604@ti.com>
On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
> On 2012-12-10 09:34, Archit Taneja wrote:
>> Hi,
>>
>> On Friday 07 December 2012 05:25 PM, Tomi Valkeinen wrote:
>>> Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial
>>> display code from omapdss) moved setting up the initial overlay, overlay
>>> manager, output and display connections from omapdss to omapfb.
>>>
>>> However, currently omapfb only handles the connection related to the
>>> default display, which means that no overlay managers are connected to
>>> other displays.
>>>
>>> This patch changes omapfb to go through all dssdevs, and connect an
>>> overlay manager to them.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> drivers/video/omap2/omapfb/omapfb-main.c | 38
>>> +++++++++++++++++++-----------
>>> 1 file changed, 24 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
>>> b/drivers/video/omap2/omapfb/omapfb-main.c
>>> index 1df973e..24739fc 100644
>>> --- a/drivers/video/omap2/omapfb/omapfb-main.c
>>> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
>>> @@ -2353,27 +2353,37 @@ static int omapfb_init_display(struct
>>> omapfb2_device *fbdev,
>>> }
>>>
>>> static int omapfb_init_connections(struct omapfb2_device *fbdev,
>>> - struct omap_dss_device *dssdev)
>>> + struct omap_dss_device *def_dssdev)
>>> {
>>> int i, r;
>>> - struct omap_overlay_manager *mgr = NULL;
>>> + struct omap_overlay_manager *mgr;
>>>
>>> - for (i = 0; i < fbdev->num_managers; i++) {
>>> - mgr = fbdev->managers[i];
>>> -
>>> - if (dssdev->channel = mgr->id)
>>> - break;
>>> + if (!def_dssdev->output) {
>>> + dev_err(fbdev->dev, "no output for the default display\n");
>>> + return -EINVAL;
>>> }
>>>
>>> - if (i = fbdev->num_managers)
>>> - return -ENODEV;
>>> + for (i = 0; i < fbdev->num_displays; ++i) {
>>> + struct omap_dss_device *dssdev = fbdev->displays[i].dssdev;
>>> + struct omap_dss_output *out = dssdev->output;
>>>
>>> - if (mgr->output)
>>> - mgr->unset_output(mgr);
>>> + mgr = omap_dss_get_overlay_manager(dssdev->channel);
>>
>> This dssdev->channel reference is something we would want to get rid of
>> eventually, right?
>
> Yes.
>
>> At the point omapfb_init_connections() is called, we would have all the
>> omap_dss_devices registered, right? So at this point, omapfb will have
>> an overall view of how the panels need to be connected to DSS.
>>
>> I think we can try to find a manager here for dssdev rather than using
>> dssdev->channel directly. The dssdev's output could connect to a few
>> managers. We would want to chose managers for each dssdev output in such
>> a way that all outputs have a manager. I guess there would be multiple
>> combinations for this, but it would be okay to pick any one of them.
>>
>> I think we would need some recursive or backtracking sort of approach to
>> get a desired combination. We can figure about how to make it work
>> later, but do you agree if this is a right way to get rid of
>> dssdev->channel?
>
> Yes, I think that's a sensible approach. The thing I don't like about it
> is that it requires omapfb/omapdrm to create the mgr-output connections.
> They shouldn't really be interested in that. All they want is a display
> device that works, and a way to get the mgr used for the display.
>
> Well, I think we can hide the implementation inside omapdss, so that
> omapfb/omapdrm will just need to call one omapdss func when they are
> started, which will connect the mgrs to outputs.
>
> A downside with setting up the mgr-output links at one go, when
> omapfb/omapdrm starts, is that it creates a strict load order
> restriction between omapdss, panels and omapfb/omapdrm. The drivers will
> need to be loaded in that order, or things won't work.
Yes, that's true.
>
> Another option would be to pass information about mgr-output links from
> the board files (or DT data) to the omapdss driver, so that omapdss
> could setup them at probe time. With this option omapfb/omapdrm doesn't
> need to care about this, and it doesn't create load order restriction.
> But mgr-output links are something that I'd really like to handle inside
> the drivers, not something that needs to be passed via platform data.
This would definitely make things simpler, but if this parameter is put
in a panel's DT, it would become omap specific. We could add this info
to the DT corresponding to omapdss.
>
> Third option, which is the best, but also something I have no idea how
> to implement, would be to create the mgr-output links dynamically when
> needed. The problem here is, of course, that a mgr could be allocated to
> an output, only to be later found out that that particular mgr is needed
> for another output.
>
> But this is something we could study a bit: can we create such mgr
> allocation system, that no matter what outputs the board uses, it'll
> just work.
Yes, that would be quite useful. But I think we'll hit situations where
it is sort of impossible to prevent the above situation.
When an output needs a manager. We could study the current state of the
system by splitting managers into 2 sets:
A: managers which already have outputs connected to them
B: managers which don't have an output, but might get connected to one
in the future.
managers in A are lost, and we can't detach them, we would need to at
least disable/reenable the panel with a new manager connected to the output.
we need to find one from B such that maximum outputs(or some other
weightage factor) will still be supported after this new link is made.
The system will initially have all managers in B, but eventually
managers will move to A. We need to move one manager from B to A for
every mgr-output link.
I guess I just described the problem in a more mathematical way, without
providing any solution :), but it does look like an optimisation problem.
>
> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
> cannot be used at the same time, we're free to give LCD1 to either one.
But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI.
Are you creating this constraint by assuming what the board is like? Or
is this a constraint of OMAP DSS HW?
> And if we know that DPI and DSI2 cannot be used at the same time, we're
> also free to give LCD2 to either one. And if that's the case, there are
> no conflicts.
This is also possible at the same time: TV->DPI and LCD2->DSI2
>
> I don't know if we can find such allocation for all current omaps, and I
> know it's slightly risky as the next omap could have limitations even if
> current ones do not.
I don't understand the example so well, but I get your point of taking
advantage of such limitations.
>
>> Also, we would need to do this for omapdrm separately using it's own
>> encoder/connector entities.
>
> Yep. That's also a negative side: both omapfb/omapdrm will need to
> implement the same stuff, even if neither of them are really interested
> in that stuff.
Yes. I wonder if crtcs, encoders and connectors already have some sort
of helpers for this?
Archit
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Tomi Valkeinen @ 2012-12-10 10:07 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5B154.9080305@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4743 bytes --]
On 2012-12-10 11:54, Archit Taneja wrote:
> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
>> Another option would be to pass information about mgr-output links from
>> the board files (or DT data) to the omapdss driver, so that omapdss
>> could setup them at probe time. With this option omapfb/omapdrm doesn't
>> need to care about this, and it doesn't create load order restriction.
>> But mgr-output links are something that I'd really like to handle inside
>> the drivers, not something that needs to be passed via platform data.
>
> This would definitely make things simpler, but if this parameter is put
> in a panel's DT, it would become omap specific. We could add this info
> to the DT corresponding to omapdss.
Yes, I meant it should be omapdss platform data. Nothing related to panels.
>> Third option, which is the best, but also something I have no idea how
>> to implement, would be to create the mgr-output links dynamically when
>> needed. The problem here is, of course, that a mgr could be allocated to
>> an output, only to be later found out that that particular mgr is needed
>> for another output.
>>
>> But this is something we could study a bit: can we create such mgr
>> allocation system, that no matter what outputs the board uses, it'll
>> just work.
>
> Yes, that would be quite useful. But I think we'll hit situations where
> it is sort of impossible to prevent the above situation.
>
> When an output needs a manager. We could study the current state of the
> system by splitting managers into 2 sets:
>
> A: managers which already have outputs connected to them
> B: managers which don't have an output, but might get connected to one
> in the future.
>
> managers in A are lost, and we can't detach them, we would need to at
> least disable/reenable the panel with a new manager connected to the
> output.
>
> we need to find one from B such that maximum outputs(or some other
> weightage factor) will still be supported after this new link is made.
>
> The system will initially have all managers in B, but eventually
> managers will move to A. We need to move one manager from B to A for
> every mgr-output link.
>
> I guess I just described the problem in a more mathematical way, without
> providing any solution :), but it does look like an optimisation problem.
Well, optimization problem sounds like something that can always be
solved. But in this case the driver may need to predict what outputs
will be used, which is of course impossible.
>> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
>> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
>> cannot be used at the same time, we're free to give LCD1 to either one.
>
> But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI.
> Are you creating this constraint by assuming what the board is like? Or
> is this a constraint of OMAP DSS HW?
I didn't check if they can be used together or not, I was just guessing.
At least on OMAP3 DSI and RFBI shared the same pins, so they could not
be used at the same time.
Perhaps we should implement a mixed approach: the driver presumes
certain things, like "if DSI is used, RFBI is not used", based on the
knowledge of what kind of boards there currently are. This would allow
us to manage the mgr->output connections in the driver for, say, 95% of
the cases. Then we'd also have the platform data parameters for omapdss,
which could be used in the weird cases.
>> And if we know that DPI and DSI2 cannot be used at the same time, we're
>> also free to give LCD2 to either one. And if that's the case, there are
>> no conflicts.
>
> This is also possible at the same time: TV->DPI and LCD2->DSI2
True. I was just again guessing. On OMAP3 DPI and DSI shared the same pins.
Thinking about this, OMAP4 does have separate pins for DSI, doesn't it?
So my guesses don't hold.
>> I don't know if we can find such allocation for all current omaps, and I
>> know it's slightly risky as the next omap could have limitations even if
>> current ones do not.
>
> I don't understand the example so well, but I get your point of taking
> advantage of such limitations.
>
>>
>>> Also, we would need to do this for omapdrm separately using it's own
>>> encoder/connector entities.
>>
>> Yep. That's also a negative side: both omapfb/omapdrm will need to
>> implement the same stuff, even if neither of them are really interested
>> in that stuff.
>
> Yes. I wonder if crtcs, encoders and connectors already have some sort
> of helpers for this?
Probably nothing that helps us, as this is OMAP HW restriction.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH v4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent
From: Hideki EIRAKU @ 2012-12-10 10:31 UTC (permalink / raw)
To: laurent.pinchart
Cc: FlorianSchandinat, linux-fbdev, linux-kernel, m.szyprowski, matsu,
dhobsong
In-Reply-To: <14014166.3JMiBq7jRA@avalon>
Hi Laurent,
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH v4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent
Date: Thu, 16 Aug 2012 14:16:32 +0200
> Hi Eiraku-san,
>
> On Thursday 16 August 2012 19:13:20 Hideki EIRAKU wrote:
>> fb_mmap() implemented in fbmem.c uses smem_start as the physical
>> address of the frame buffer. In the sh_mobile_lcdc driver, the
>> smem_start is a dma_addr_t that is not a physical address when IOMMU is
>> enabled. dma_mmap_coherent() maps the address correctly.
>>
>> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> I will push the patch to v3.7 through my tree.
I'd like to use this patch to test IOMMU implementation of Renesas
IPMMU. But I could not find it in v3.7-rc8. Could you please tell me if
this has already been merged somewhere or not?
--
Hideki EIRAKU <hdk@igel.co.jp>
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Archit Taneja @ 2012-12-10 10:54 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5B44E.3040304@ti.com>
On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote:
> On 2012-12-10 11:54, Archit Taneja wrote:
>> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
>
>>> Another option would be to pass information about mgr-output links from
>>> the board files (or DT data) to the omapdss driver, so that omapdss
>>> could setup them at probe time. With this option omapfb/omapdrm doesn't
>>> need to care about this, and it doesn't create load order restriction.
>>> But mgr-output links are something that I'd really like to handle inside
>>> the drivers, not something that needs to be passed via platform data.
>>
>> This would definitely make things simpler, but if this parameter is put
>> in a panel's DT, it would become omap specific. We could add this info
>> to the DT corresponding to omapdss.
>
> Yes, I meant it should be omapdss platform data. Nothing related to panels.
I think this is the easiest way out. We can have one parameter per
output in DT. If we do come up with a way to implement the 3rd option
below, we can always ignore those DT fields(assuming our implementation
to give the same result). So in this way, we would just be deprecating a
DT field in the future, and calculating it ourselves.
>
>>> Third option, which is the best, but also something I have no idea how
>>> to implement, would be to create the mgr-output links dynamically when
>>> needed. The problem here is, of course, that a mgr could be allocated to
>>> an output, only to be later found out that that particular mgr is needed
>>> for another output.
>>>
>>> But this is something we could study a bit: can we create such mgr
>>> allocation system, that no matter what outputs the board uses, it'll
>>> just work.
>>
>> Yes, that would be quite useful. But I think we'll hit situations where
>> it is sort of impossible to prevent the above situation.
>>
>> When an output needs a manager. We could study the current state of the
>> system by splitting managers into 2 sets:
>>
>> A: managers which already have outputs connected to them
>> B: managers which don't have an output, but might get connected to one
>> in the future.
>>
>> managers in A are lost, and we can't detach them, we would need to at
>> least disable/reenable the panel with a new manager connected to the
>> output.
>>
>> we need to find one from B such that maximum outputs(or some other
>> weightage factor) will still be supported after this new link is made.
>>
>> The system will initially have all managers in B, but eventually
>> managers will move to A. We need to move one manager from B to A for
>> every mgr-output link.
>>
>> I guess I just described the problem in a more mathematical way, without
>> providing any solution :), but it does look like an optimisation problem.
>
> Well, optimization problem sounds like something that can always be
> solved. But in this case the driver may need to predict what outputs
> will be used, which is of course impossible.
>
>>> So, for example, on omap4, LCD2 mgr can be used for DPI, DSI2, DSI1, and
>>> RFBI. LCD1 can be used for RFBI and DSI1. If we know that DSI1 and RFBI
>>> cannot be used at the same time, we're free to give LCD1 to either one.
>>
>> But they can be used together, can't they? LCD1->DSI1 and LCD2->RFBI.
>> Are you creating this constraint by assuming what the board is like? Or
>> is this a constraint of OMAP DSS HW?
>
> I didn't check if they can be used together or not, I was just guessing.
> At least on OMAP3 DSI and RFBI shared the same pins, so they could not
> be used at the same time.
>
> Perhaps we should implement a mixed approach: the driver presumes
> certain things, like "if DSI is used, RFBI is not used", based on the
> knowledge of what kind of boards there currently are. This would allow
> us to manage the mgr->output connections in the driver for, say, 95% of
> the cases. Then we'd also have the platform data parameters for omapdss,
> which could be used in the weird cases.
Let's just have platform data parameters :)
>
>>> And if we know that DPI and DSI2 cannot be used at the same time, we're
>>> also free to give LCD2 to either one. And if that's the case, there are
>>> no conflicts.
>>
>> This is also possible at the same time: TV->DPI and LCD2->DSI2
>
> True. I was just again guessing. On OMAP3 DPI and DSI shared the same pins.
>
> Thinking about this, OMAP4 does have separate pins for DSI, doesn't it?
> So my guesses don't hold.
>
>>> I don't know if we can find such allocation for all current omaps, and I
>>> know it's slightly risky as the next omap could have limitations even if
>>> current ones do not.
>>
>> I don't understand the example so well, but I get your point of taking
>> advantage of such limitations.
>>
>>>
>>>> Also, we would need to do this for omapdrm separately using it's own
>>>> encoder/connector entities.
>>>
>>> Yep. That's also a negative side: both omapfb/omapdrm will need to
>>> implement the same stuff, even if neither of them are really interested
>>> in that stuff.
>>
>> Yes. I wonder if crtcs, encoders and connectors already have some sort
>> of helpers for this?
>
> Probably nothing that helps us, as this is OMAP HW restriction.
If we do use DT/platform data, would we need to parse it in omapdrm to
establish drm entities? Or do we rely on omapdss to parse the DT data
and give the links to omapdrm?
Archit
^ permalink raw reply
* Re: [PATCH 5/5] OMAPFB: connect ovl managers to all dssdevs
From: Tomi Valkeinen @ 2012-12-10 11:03 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <50C5BF32.1080006@ti.com>
[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]
On 2012-12-10 12:53, Archit Taneja wrote:
> On Monday 10 December 2012 03:37 PM, Tomi Valkeinen wrote:
>> On 2012-12-10 11:54, Archit Taneja wrote:
>>> On Monday 10 December 2012 01:33 PM, Tomi Valkeinen wrote:
>>
>>>> Another option would be to pass information about mgr-output links from
>>>> the board files (or DT data) to the omapdss driver, so that omapdss
>>>> could setup them at probe time. With this option omapfb/omapdrm doesn't
>>>> need to care about this, and it doesn't create load order restriction.
>>>> But mgr-output links are something that I'd really like to handle
>>>> inside
>>>> the drivers, not something that needs to be passed via platform data.
>>>
>>> This would definitely make things simpler, but if this parameter is put
>>> in a panel's DT, it would become omap specific. We could add this info
>>> to the DT corresponding to omapdss.
>>
>> Yes, I meant it should be omapdss platform data. Nothing related to
>> panels.
>
> I think this is the easiest way out. We can have one parameter per
> output in DT. If we do come up with a way to implement the 3rd option
> below, we can always ignore those DT fields(assuming our implementation
> to give the same result). So in this way, we would just be deprecating a
> DT field in the future, and calculating it ourselves.
I would rather go the other way around: calculate it ourselves
(presuming it can be done for the current boards), and add the DT field
later if we come up with boards that won't work with the dynamic approach.
The reasons I'm not too happy with having the parameter in the DT data
is that:
- DT should be about describing the hardware connections between
components, but in this case it's dynamically configurable connection.
- We need to have the DT parameter for all cases, even if in 95% of
cases it's not really needed.
- We may never need the parameter, if we never get boards that require
funny setup.
> If we do use DT/platform data, would we need to parse it in omapdrm to
> establish drm entities? Or do we rely on omapdss to parse the DT data
> and give the links to omapdrm?
I think we should parse it in omapdss and setup the connections at
omapdss's probe. Then when omapfb/omapdrm starts, they can get
information about the connections from omapdss, and setup their entities
as they want.
So omapdss would setup the mgr->output->panel links, and they would be
ready for omapfb/omapdrm to use.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* [PATCH 0/3] atmel_lcdfb: fix 16-bpp regression
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
These patches fix a regression in 16-bpp support for older SOCs which use
IBGR:555 rather than BGR:565 pixel layout. Use SOC-type to determine if the
controller uses the intensity-bit and restore the old layout in that case.
The third patch is simply a clean up.
Thanks,
Johan
Johan Hovold (3):
atmel_lcdfb: fix 16-bpp modes on older SOCs
ARM: at91/neocore926: fix LCD-wiring mode
atmel_lcdfb: remove unsupported 15-bpp mode
arch/arm/mach-at91/board-neocore926.c | 2 +-
drivers/video/atmel_lcdfb.c | 23 +++++++++++++++--------
include/video/atmel_lcdc.h | 2 +-
3 files changed, 17 insertions(+), 10 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
modes for older SOCs which use IBGR:555 (msb is intensity) rather
than BGR:565.
Use SOC-type to determine the pixel layout.
Tested on custom at91sam9263-board.
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
include/video/atmel_lcdc.h | 1 +
2 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 1505539..1f68fa6 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
= var->bits_per_pixel;
break;
case 16:
+ /* Older SOCs use IBGR:555 rather than BGR:565. */
+ if (sinfo->have_intensity_bit)
+ var->green.length = 5;
+ else
+ var->green.length = 6;
+
if (sinfo->lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB) {
- /* RGB:565 mode */
- var->red.offset = 11;
+ /* RGB:5X5 mode */
+ var->red.offset = var->green.length + 5;
var->blue.offset = 0;
} else {
- /* BGR:565 mode */
+ /* BGR:5X5 mode */
var->red.offset = 0;
- var->blue.offset = 11;
+ var->blue.offset = var->green.length + 5;
}
var->green.offset = 5;
- var->green.length = 6;
var->red.length = var->blue.length = 5;
break;
case 32:
@@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
case FB_VISUAL_PSEUDOCOLOR:
if (regno < 256) {
- if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
- || cpu_is_at91sam9rl()) {
+ if (sinfo->have_intensity_bit) {
/* old style I+BGR:555 */
val = ((red >> 11) & 0x001f);
val |= ((green >> 6) & 0x03e0);
@@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
}
sinfo->info = info;
sinfo->pdev = pdev;
+ if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
+ cpu_is_at91sam9rl()) {
+ sinfo->have_intensity_bit = true;
+ }
strcpy(info->fix.id, sinfo->pdev->name);
info->flags = ATMEL_LCDFB_FBINFO_DEFAULT;
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 28447f1..5f0e234 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -62,6 +62,7 @@ struct atmel_lcdfb_info {
void (*atmel_lcdfb_power_control)(int on);
struct fb_monspecs *default_monspecs;
u32 pseudo_palette[16];
+ bool have_intensity_bit;
};
#define ATMEL_LCDC_DMABADDR1 0x00
--
1.8.0
^ permalink raw reply related
* [PATCH 2/3] ARM: at91/neocore926: fix LCD-wiring mode
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
modes for older SOCs which use IBGR:555 (msb is intensity) rather than
BGR:565.
The above commit also removed the RGB:555-wiring hack without fixing the
neocore926 board which used it. Fix by specifying RGB-wiring and let the
driver handle the final SOC-dependant layout.
Remove the no longer used ATMEL_LCDC_WIRING_RGB555 define.
Compile-only tested.
Cc: <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
arch/arm/mach-at91/board-neocore926.c | 2 +-
include/video/atmel_lcdc.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-at91/board-neocore926.c b/arch/arm/mach-at91/board-neocore926.c
index 997d359..daeb7c6 100644
--- a/arch/arm/mach-at91/board-neocore926.c
+++ b/arch/arm/mach-at91/board-neocore926.c
@@ -265,7 +265,7 @@ static struct atmel_lcdfb_info __initdata neocore926_lcdc_data = {
.default_monspecs = &at91fb_default_monspecs,
.atmel_lcdfb_power_control = at91_lcdc_power_control,
.guard_time = 1,
- .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB555,
+ .lcd_wiring_mode = ATMEL_LCDC_WIRING_RGB,
};
#else
diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
index 5f0e234..8deb226 100644
--- a/include/video/atmel_lcdc.h
+++ b/include/video/atmel_lcdc.h
@@ -30,7 +30,6 @@
*/
#define ATMEL_LCDC_WIRING_BGR 0
#define ATMEL_LCDC_WIRING_RGB 1
-#define ATMEL_LCDC_WIRING_RGB555 2
/* LCD Controller info data structure, stored in device platform_data */
--
1.8.0
^ permalink raw reply related
* [PATCH 3/3] atmel_lcdfb: remove unsupported 15-bpp mode
From: Johan Hovold @ 2012-12-10 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
Since commit 787f9fd23283 ("atmel_lcdfb: support 16bit BGR:565 mode,
remove unsupported 15bit modes") atmel_lcdfb_check_var does not accept
15-bpp mode so remove it from atmel_lcdfb_set_par as well.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/video/atmel_lcdfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 1f68fa6..3cdbd53 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -567,7 +567,6 @@ static int atmel_lcdfb_set_par(struct fb_info *info)
case 2: value |= ATMEL_LCDC_PIXELSIZE_2; break;
case 4: value |= ATMEL_LCDC_PIXELSIZE_4; break;
case 8: value |= ATMEL_LCDC_PIXELSIZE_8; break;
- case 15: /* fall through */
case 16: value |= ATMEL_LCDC_PIXELSIZE_16; break;
case 24: value |= ATMEL_LCDC_PIXELSIZE_24; break;
case 32: value |= ATMEL_LCDC_PIXELSIZE_32; break;
--
1.8.0
^ permalink raw reply related
* Re: [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Peter Korsgaard @ 2012-12-10 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-2-git-send-email-jhovold@gmail.com>
>>>>> "Johan" = Johan Hovold <jhovold@gmail.com> writes:
Johan> Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
Johan> 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
Johan> modes for older SOCs which use IBGR:555 (msb is intensity) rather
Johan> than BGR:565.
Johan> Use SOC-type to determine the pixel layout.
Johan> Tested on custom at91sam9263-board.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 2/3] ARM: at91/neocore926: fix LCD-wiring mode
From: Peter Korsgaard @ 2012-12-10 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-3-git-send-email-jhovold@gmail.com>
>>>>> "Johan" = Johan Hovold <jhovold@gmail.com> writes:
Johan> Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
Johan> 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
Johan> modes for older SOCs which use IBGR:555 (msb is intensity) rather than
Johan> BGR:565.
Johan> The above commit also removed the RGB:555-wiring hack without fixing the
Johan> neocore926 board which used it. Fix by specifying RGB-wiring and let the
Johan> driver handle the final SOC-dependant layout.
Johan> Remove the no longer used ATMEL_LCDC_WIRING_RGB555 define.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/3] atmel_lcdfb: remove unsupported 15-bpp mode
From: Peter Korsgaard @ 2012-12-10 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-4-git-send-email-jhovold@gmail.com>
>>>>> "Johan" = Johan Hovold <jhovold@gmail.com> writes:
Johan> Since commit 787f9fd23283 ("atmel_lcdfb: support 16bit BGR:565 mode,
Johan> remove unsupported 15bit modes") atmel_lcdfb_check_var does not accept
Johan> 15-bpp mode so remove it from atmel_lcdfb_set_par as well.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH v4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent
From: Laurent Pinchart @ 2012-12-10 22:54 UTC (permalink / raw)
To: Hideki EIRAKU
Cc: FlorianSchandinat, linux-fbdev, linux-kernel, m.szyprowski, matsu,
dhobsong
In-Reply-To: <20121210.193125.442743545.hdk@igel.co.jp>
Hi Eiraku-san,
On Monday 10 December 2012 19:31:25 Hideki EIRAKU wrote:
> On Thu, 16 Aug 2012 14:16:32 +0200 Laurent Pinchart wrote:
> > On Thursday 16 August 2012 19:13:20 Hideki EIRAKU wrote:
> >> fb_mmap() implemented in fbmem.c uses smem_start as the physical
> >> address of the frame buffer. In the sh_mobile_lcdc driver, the
> >> smem_start is a dma_addr_t that is not a physical address when IOMMU is
> >> enabled. dma_mmap_coherent() maps the address correctly.
> >>
> >> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
> >
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > I will push the patch to v3.7 through my tree.
>
> I'd like to use this patch to test IOMMU implementation of Renesas
> IPMMU. But I could not find it in v3.7-rc8. Could you please tell me if
> this has already been merged somewhere or not?
I'm afraid the patch got delayed to v3.8, sorry about that. I've sent a pull
request for v3.8, the patch is currently in linux-next
(bf10a53765b4435a5349a92a5a51753902ed86f1) and will be merged during the next
merge window (which should open in the very near future).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 10/19] MAINTAINERS: fix .../plat-mxc/include/mach/imxfb.h
From: Cesar Eduardo Barros @ 2012-12-11 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355262601-4263-1-git-send-email-cesarb@cesarb.net>
This file was moved to include/linux/platform_data/video-imxfb.h by
commit 82906b1 (ARM: imx: move platform_data definitions).
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bf84d4..9bc4861d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3138,7 +3138,7 @@ M: Sascha Hauer <kernel@pengutronix.de>
L: linux-fbdev@vger.kernel.org
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
-F: arch/arm/plat-mxc/include/mach/imxfb.h
+F: include/linux/platform_data/video-imxfb.h
F: drivers/video/imxfb.c
FREESCALE SOC FS_ENET DRIVER
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/1] video: exynos: Use devm_* APIs in s6e8ax0.c
From: Sachin Kamat @ 2012-12-12 5:23 UTC (permalink / raw)
To: linux-fbdev
devm_* APIs are device managed and make error handling
and code cleanup simpler.
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
Compile tested against linux-next.
---
drivers/video/exynos/s6e8ax0.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/exynos/s6e8ax0.c b/drivers/video/exynos/s6e8ax0.c
index 05d080b..ca26024 100644
--- a/drivers/video/exynos/s6e8ax0.c
+++ b/drivers/video/exynos/s6e8ax0.c
@@ -776,7 +776,7 @@ static int s6e8ax0_probe(struct mipi_dsim_lcd_device *dsim_dev)
int ret;
u8 mtp_id[3] = {0, };
- lcd = kzalloc(sizeof(struct s6e8ax0), GFP_KERNEL);
+ lcd = devm_kzalloc(&dsim_dev->dev, sizeof(struct s6e8ax0), GFP_KERNEL);
if (!lcd) {
dev_err(&dsim_dev->dev, "failed to allocate s6e8ax0 structure.\n");
return -ENOMEM;
@@ -788,18 +788,17 @@ static int s6e8ax0_probe(struct mipi_dsim_lcd_device *dsim_dev)
mutex_init(&lcd->lock);
- ret = regulator_bulk_get(lcd->dev, ARRAY_SIZE(supplies), supplies);
+ ret = devm_regulator_bulk_get(lcd->dev, ARRAY_SIZE(supplies), supplies);
if (ret) {
dev_err(lcd->dev, "Failed to get regulators: %d\n", ret);
- goto err_lcd_register;
+ return ret;
}
lcd->ld = lcd_device_register("s6e8ax0", lcd->dev, lcd,
&s6e8ax0_lcd_ops);
if (IS_ERR(lcd->ld)) {
dev_err(lcd->dev, "failed to register lcd ops.\n");
- ret = PTR_ERR(lcd->ld);
- goto err_lcd_register;
+ return PTR_ERR(lcd->ld);
}
lcd->bd = backlight_device_register("s6e8ax0-bl", lcd->dev, lcd,
@@ -838,11 +837,6 @@ static int s6e8ax0_probe(struct mipi_dsim_lcd_device *dsim_dev)
err_backlight_register:
lcd_device_unregister(lcd->ld);
-
-err_lcd_register:
- regulator_bulk_free(ARRAY_SIZE(supplies), supplies);
- kfree(lcd);
-
return ret;
}
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH] da8xx: Allow use by am33xx based devices
From: Manjunathappa, Prakash @ 2012-12-12 7:20 UTC (permalink / raw)
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi, davinci-linux-open-source@linux.davincidsp.com,
Porter, Matt, linux-fbdev@vger.kernel.org,
FlorianSchandinat@gmx.de, Koen Kooi, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Dill, Russ,
linux-omap@vger.kernel.org
In-Reply-To: <50C5A50E.4070602@ti.com>
Hi Vaibhav,
On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote:
>
>
> On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote:
> > Hi Tomi,
> >
> > On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote:
> >> Hi,
> >>
> >> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote:
> >>> This driver can be used for AM33xx devices, like the popular beaglebone.
> >>>
> >>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> >>> ---
> >>> drivers/video/Kconfig | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> >>> index 9791d10..e7868d8 100644
> >>> --- a/drivers/video/Kconfig
> >>> +++ b/drivers/video/Kconfig
> >>> @@ -2202,7 +2202,7 @@ config FB_SH7760
> >>>
> >>> config FB_DA8XX
> >>> tristate "DA8xx/OMAP-L1xx Framebuffer support"
> >>> - depends on FB && ARCH_DAVINCI_DA8XX
> >>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX)
> >>
> >> Agreed this is present on da8xx and am33xx, but moving forward for
> >> supporting DT, we should be avoiding these dependencies. So instead
> >> change this to remove machine dependencies.
> >>
> >
> > I could be wrong here, having dependency on platform seems to be right.
> > Otherwise may lead to build errors for other platforms.
>
> No, it should not result in to build error unless driver uses some
> platform specific api's.
>
Agreed, should not result in build error. But is it ok to show this option
on the platforms which do not have this IP?
Thanks,
Prakash
^ permalink raw reply
* RE: [PATCH] da8xx: Allow use by am33xx based devices
From: Hiremath, Vaibhav @ 2012-12-12 8:00 UTC (permalink / raw)
To: Manjunathappa, Prakash
Cc: Valkeinen, Tomi, davinci-linux-open-source@linux.davincidsp.com,
Porter, Matt, linux-fbdev@vger.kernel.org,
FlorianSchandinat@gmx.de, Koen Kooi, Pantelis Antoniou,
linux-kernel@vger.kernel.org, Dill, Russ,
linux-omap@vger.kernel.org
In-Reply-To: <A73F36158E33644199EB82C5EC81C7BC3EA17E45@DBDE01.ent.ti.com>
On Wed, Dec 12, 2012 at 12:50:28, Manjunathappa, Prakash wrote:
> Hi Vaibhav,
>
> On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote:
> >
> >
> > On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote:
> > > Hi Tomi,
> > >
> > > On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote:
> > >> Hi,
> > >>
> > >> On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote:
> > >>> This driver can be used for AM33xx devices, like the popular beaglebone.
> > >>>
> > >>> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
> > >>> ---
> > >>> drivers/video/Kconfig | 2 +-
> > >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > >>> index 9791d10..e7868d8 100644
> > >>> --- a/drivers/video/Kconfig
> > >>> +++ b/drivers/video/Kconfig
> > >>> @@ -2202,7 +2202,7 @@ config FB_SH7760
> > >>>
> > >>> config FB_DA8XX
> > >>> tristate "DA8xx/OMAP-L1xx Framebuffer support"
> > >>> - depends on FB && ARCH_DAVINCI_DA8XX
> > >>> + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX)
> > >>
> > >> Agreed this is present on da8xx and am33xx, but moving forward for
> > >> supporting DT, we should be avoiding these dependencies. So instead
> > >> change this to remove machine dependencies.
> > >>
> > >
> > > I could be wrong here, having dependency on platform seems to be right.
> > > Otherwise may lead to build errors for other platforms.
> >
> > No, it should not result in to build error unless driver uses some
> > platform specific api's.
> >
>
> Agreed, should not result in build error. But is it ok to show this option
> on the platforms which do not have this IP?
>
You can choose to put machine dependency here, as this patch is already
doing it. The side-effect of this would be, list may grow and you may have
to edit this file everytime.
Thanks,
Vaibhav
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox