* [PATCH 2/2] OMAPDSS: DISPC: remove dispc fck uses
From: Tomi Valkeinen @ 2012-12-12 12:27 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
In-Reply-To: <1355315229-25238-1-git-send-email-tomi.valkeinen@ti.com>
The previous patch changes dispc to get the dispc fck rate from dss core
driver. This was the only use of the dispc fck in dispc, and thus we can
now remove the clock handling.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 08137a8..05ff2b9 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -96,7 +96,6 @@ static struct {
int ctx_loss_cnt;
int irq;
- struct clk *dss_clk;
u32 fifo_size[DISPC_MAX_NR_FIFOS];
/* maps which plane is using a fifo. fifo-id -> plane-id */
@@ -3619,7 +3618,6 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
u32 rev;
int r = 0;
struct resource *dispc_mem;
- struct clk *clk;
dispc.pdev = pdev;
@@ -3646,15 +3644,6 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
return -ENODEV;
}
- clk = clk_get(&pdev->dev, "fck");
- if (IS_ERR(clk)) {
- DSSERR("can't get fck\n");
- r = PTR_ERR(clk);
- return r;
- }
-
- dispc.dss_clk = clk;
-
pm_runtime_enable(&pdev->dev);
r = dispc_runtime_get();
@@ -3675,7 +3664,6 @@ static int __init omap_dispchw_probe(struct platform_device *pdev)
err_runtime_get:
pm_runtime_disable(&pdev->dev);
- clk_put(dispc.dss_clk);
return r;
}
@@ -3683,8 +3671,6 @@ static int __exit omap_dispchw_remove(struct platform_device *pdev)
{
pm_runtime_disable(&pdev->dev);
- clk_put(dispc.dss_clk);
-
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] OMAPDSS: DISPC: get dss clock rate from dss driver
From: Tomi Valkeinen @ 2012-12-12 12:27 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev; +Cc: Tomi Valkeinen
Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
to get the rate for scaling calculations. This causes a problem with
common clock framework, as omapdss uses the dispc functions inside a
spinlock, and common clock framework uses a mutex in clk_get_rate().
Looking at the DSS clock tree, the above use of the dispc fck is not
quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
a mux to select the clock for DISPC from various options, so the current
use of dispc fck bypasses that. Fortunately we never change the dispc
clock mux for now.
To fix the issue with clk_get_rate(), this patch caches the dss clock
rate in dss.c when it is set. Dispc will then ask for the clock rate
from dss. While this is not very elegant, it does fix the issue, and
it's not totally wrong when considering that the dispc fck actually
comes via dss.
In the future we should probably look into common clock framework and
see if that could be used to represent the DSS clock tree properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 4 ++--
drivers/video/omap2/dss/dss.c | 12 ++++++++++++
drivers/video/omap2/dss/dss.h | 1 +
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index fedbd2c..08137a8 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2970,7 +2970,7 @@ unsigned long dispc_fclk_rate(void)
switch (dss_get_dispc_clk_source()) {
case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
+ r = dss_get_dispc_clk_rate();
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
dsidev = dsi_get_dsidev_from_id(0);
@@ -3002,7 +3002,7 @@ unsigned long dispc_mgr_lclk_rate(enum omap_channel channel)
switch (dss_get_lcd_clk_source(channel)) {
case OMAP_DSS_CLK_SRC_FCK:
- r = clk_get_rate(dispc.dss_clk);
+ r = dss_get_dispc_clk_rate();
break;
case OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC:
dsidev = dsi_get_dsidev_from_id(0);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 833f162..054c2a2 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -77,6 +77,7 @@ static struct {
struct clk *dpll4_m4_ck;
struct clk *dss_clk;
+ unsigned long dss_clk_rate;
unsigned long cache_req_pck;
unsigned long cache_prate;
@@ -489,6 +490,10 @@ int dss_set_clock_div(struct dss_clock_info *cinfo)
return -EINVAL;
}
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+
+ WARN_ONCE(dss.dss_clk_rate != cinfo->fck, "clk rate mismatch");
+
DSSDBG("fck = %ld (%d)\n", cinfo->fck, cinfo->fck_div);
return 0;
@@ -502,6 +507,11 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+unsigned long dss_get_dispc_clk_rate(void)
+{
+ return dss.dss_clk_rate;
+}
+
static int dss_setup_default_clock(void)
{
unsigned long max_dss_fck, prate;
@@ -953,6 +963,8 @@ static int __init omap_dsshw_probe(struct platform_device *pdev)
if (r)
goto err_runtime_get;
+ dss.dss_clk_rate = clk_get_rate(dss.dss_clk);
+
/* Select DPLL */
REG_FLD_MOD(DSS_CONTROL, 0, 0, 0);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ebe9e08..610c8e5 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -237,6 +237,7 @@ void dss_overlay_kobj_uninit(struct omap_overlay *ovl);
int dss_init_platform_driver(void) __init;
void dss_uninit_platform_driver(void);
+unsigned long dss_get_dispc_clk_rate(void);
int dss_dpi_select_source(enum omap_channel channel);
void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
--
1.7.10.4
^ permalink raw reply related
* 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
* 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
* [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
* [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
* 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
* 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 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 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
* [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
* [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 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 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
* 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
* 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 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: 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 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 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] 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: [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: [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: [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: [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
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