* [PATCH] video: omap: delete support for early fbmem allocation
From: Aaro Koskinen @ 2014-05-09 22:52 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev
Cc: linux-kernel, Peter Griffin, Arnd Bergmann,
Jean-Christophe Plagniol-Villard, Janusz Krzysztofik,
Tony Lindgren, Aaro Koskinen
Commit 1e434f9318efc3dddc0c0b8d2071712668154c2b (OMAPFB: remove early mem
alloc from old omapfb) deleted the support for early fbmem allocation
from the platform code, but some code still remains in the driver side.
Delete this code now, as it repotedly causes build issues on !MMU.
The patch was tested on Amstrad E3 and Nokia 770 and framebuffer
functionality is not affected.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
drivers/video/fbdev/omap/lcdc.c | 67 ++---------------------------------------
1 file changed, 2 insertions(+), 65 deletions(-)
diff --git a/drivers/video/fbdev/omap/lcdc.c b/drivers/video/fbdev/omap/lcdc.c
index b52f625..6efa259 100644
--- a/drivers/video/fbdev/omap/lcdc.c
+++ b/drivers/video/fbdev/omap/lcdc.c
@@ -74,7 +74,6 @@ static struct omap_lcd_controller {
void (*dma_callback)(void *data);
void *dma_callback_data;
- int fbmem_allocated;
dma_addr_t vram_phys;
void *vram_virt;
unsigned long vram_size;
@@ -611,42 +610,6 @@ static void lcdc_dma_handler(u16 status, void *data)
lcdc.dma_callback(lcdc.dma_callback_data);
}
-static int mmap_kern(void)
-{
- struct vm_struct *kvma;
- struct vm_area_struct vma;
- pgprot_t pgprot;
- unsigned long vaddr;
-
- kvma = get_vm_area(lcdc.vram_size, VM_IOREMAP);
- if (kvma = NULL) {
- dev_err(lcdc.fbdev->dev, "can't get kernel vm area\n");
- return -ENOMEM;
- }
- vma.vm_mm = &init_mm;
-
- vaddr = (unsigned long)kvma->addr;
- vma.vm_start = vaddr;
- vma.vm_end = vaddr + lcdc.vram_size;
-
- pgprot = pgprot_writecombine(pgprot_kernel);
- if (io_remap_pfn_range(&vma, vaddr,
- lcdc.vram_phys >> PAGE_SHIFT,
- lcdc.vram_size, pgprot) < 0) {
- dev_err(lcdc.fbdev->dev, "kernel mmap for FB memory failed\n");
- return -EAGAIN;
- }
-
- lcdc.vram_virt = (void *)vaddr;
-
- return 0;
-}
-
-static void unmap_kern(void)
-{
- vunmap(lcdc.vram_virt);
-}
-
static int alloc_palette_ram(void)
{
lcdc.palette_virt = dma_alloc_writecombine(lcdc.fbdev->dev,
@@ -703,8 +666,6 @@ static void free_fbmem(void)
static int setup_fbmem(struct omapfb_mem_desc *req_md)
{
- int r;
-
if (!req_md->region_cnt) {
dev_err(lcdc.fbdev->dev, "no memory regions defined\n");
return -EINVAL;
@@ -715,31 +676,7 @@ static int setup_fbmem(struct omapfb_mem_desc *req_md)
req_md->region_cnt = 1;
}
- if (req_md->region[0].paddr = 0) {
- lcdc.fbmem_allocated = 1;
- if ((r = alloc_fbmem(&req_md->region[0])) < 0)
- return r;
- return 0;
- }
-
- lcdc.vram_phys = req_md->region[0].paddr;
- lcdc.vram_size = req_md->region[0].size;
-
- if ((r = mmap_kern()) < 0)
- return r;
-
- dev_dbg(lcdc.fbdev->dev, "vram at %08x size %08lx mapped to 0x%p\n",
- lcdc.vram_phys, lcdc.vram_size, lcdc.vram_virt);
-
- return 0;
-}
-
-static void cleanup_fbmem(void)
-{
- if (lcdc.fbmem_allocated)
- free_fbmem();
- else
- unmap_kern();
+ return alloc_fbmem(&req_md->region[0]);
}
static int omap_lcdc_init(struct omapfb_device *fbdev, int ext_mode,
@@ -833,7 +770,7 @@ static void omap_lcdc_cleanup(void)
{
if (!lcdc.ext_mode)
free_palette_ram();
- cleanup_fbmem();
+ free_fbmem();
omap_free_lcd_dma();
free_irq(OMAP_LCDC_IRQ, lcdc.fbdev);
clk_disable(lcdc.lcd_ck);
--
1.9.0
^ permalink raw reply related
* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Aaro Koskinen @ 2014-05-09 21:21 UTC (permalink / raw)
To: Tony Lindgren
Cc: Tomi Valkeinen, Peter Griffin, Arnd Bergmann, linux-kernel,
linaro-kernel, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-omap, Janusz Krzysztofik
In-Reply-To: <20140508231711.GF2198@atomide.com>
Hi,
On Thu, May 08, 2014 at 04:17:11PM -0700, Tony Lindgren wrote:
> > OMAP1 fb is working very well. As a matter of fact, it's much more usable
> > for me than fb on OMAP2/3 - apart from N900 (on which fb is working again
> > with 3.15) none of my 4 other OMAP2/3 boards have a working display/fb
> > in mainline yet. :-(
>
> I hear you.. What do you have in the .config for omap1?
> Would be nice to enable the framebuffer in omap1_defconfig?
Looks like the needed stuff is enabled there. Unfortunately I cannot
test the full omap1_defconfig because of size limitations.
> > > > Tony, any idea of omap1's fb? Are you able to test this?
> > >
> > > I have three omap1 boards in my rack that I use for my boot
> > > testing. Tried to enable framebuffer but so far no luck on
> > > any of them. So I'm not much of a help here. Looks like the
> > > patch should work though..
> > >
> > > Aaro & Janusz, care to take a look at the patch in this
> > > thread?
> >
> > I couldn't figure out how to enter this code path. Amstrad E3 & Nokia
> > 770 will take the alloc_fbmem() path & exit, and based on quick look
> > I could not see way to enter mmap_kern(). Is that dead code?
>
> Could be. It may be something left from when we had code to keep
> the bootloader logo displayed while booting kernel.
The support for early fbmem alloc was removed in 2011
(1e434f9318efc3dddc0c0b8d2071712668154c2b, OMAPFB: remove early mem
alloc from old omapfb), so I think we can safely delete this code.
I can prepare & test a patch for this.
A.
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Andreas Müller @ 2014-05-09 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536C860E.1000501@ti.com>
On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 30/04/14 02:52, Tony Lindgren wrote:
>> Otherwise we can get often errors like the following and the
>> display won't come on:
>>
>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> the output with video overlays disabled
>>
>> There are some earlier references to this issue:
>>
>> http://www.spinics.net/lists/linux-omap/msg59511.html
>> http://www.spinics.net/lists/linux-omap/msg59724.html
>
resend - my client had HTML enabled...
FWIW: I have had issues long time ago [1]. With mainline 3.14.3 I had
still the reboot problem on old 600MHz OMAP 3530. Applying this patch
solved the issues. For other versions I had no chance to reproduce the
original wakup issue mentioned in old thread
[1] http://marc.info/?l=linux-omap&m\x136250904607413&w=2
Andreas
> Those don't sound like the same issue, but it's hard to say. What kind
> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> without this patch?
>
> What resolution do you have? If it's a very high resolution (say, DVI
> output to a monitor), it could just be an issue of
> not-enough-memory-bandwidth.
>
>> It seems that it's safe to set the lower values even for 3630.
>> If we can confirm that 3630 works with the higher values
>> reliably we can add further detection.
>>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> ---
>> drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
>> index d55266c..ad6561f 100644
>> --- a/drivers/video/fbdev/omap2/dss/dss.c
>> +++ b/drivers/video/fbdev/omap2/dss/dss.c
>> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
>> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
>> };
>>
>> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
>> static const struct dss_features omap3630_dss_feats __initconst = {
>> - .fck_div_max = 32,
>> - .dss_fck_multiplier = 1,
>> + .fck_div_max = 16,
>> + .dss_fck_multiplier = 2,
>
> These values tell about the clock hardware, they are not settings that
> can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> and a divider with maximum value of 16.
>
> Tomi
>
>
^ permalink raw reply
* Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tony Lindgren @ 2014-05-09 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536CA10B.9040702@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 02:34]:
> On 05/05/14 21:41, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [140429 16:53]:
> >> Hi all,
> >>
> >> Here are few patches to add devicetree support for panel ls037v7dw01
> >> that's found on many omap3 boards. They seem to be often mis-configured
> >> as various panel dpi entries, but really should be move to use panel
> >> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
> >> ldp, omap3 evm and few other development boards.
> >
> > Tomi, assuming no more comments, do you want to pick up the first
> > three patches of this series? I can queue the .dts changes or you
> > can also set up a separate .dts changes branch for DSS that I can
> > merge in too.
>
> If it's all the same to you, I'd like to collect all display related
> arch/arm/ patches into my tree, and I'll send you a merge request when
> it's stable.
>
> I already have OMAP5 and AM43xx stuff there.
Yes that works well for me.
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-09 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536C8293.4070506@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:24]:
> On 09/05/14 02:33, Tony Lindgren wrote:
> > +Example when connected to a omap2+ based device:
> > +
> > + lcd0: display {
> > + compatible = "sharp,ls037v7dw01";
> > + power-supply = <&lcd_3v3>;
> > + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
> > + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
> > + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
> > + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> > + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
> > +
> > + panel-timing {
> > + clock-frequency = <19200000>;
> > + hback-porch = <28>;
> > + hactive = <480>;
> > + hfront-porch = <1>;
> > + hsync-len = <2>;
> > + vback-porch = <1>;
> > + vactive = <640>;
> > + vfront-porch = <1>;
> > + vsync-len = <1>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
> > + de-active = <1>;
> > + pixelclk-active = <1>;
> > + };
>
> I don't think we should define panel-timing here. We know it's
> sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
> would extend the driver to support both resolution modes, it needs to
> support two different timings, so the above doesn't work in that case
> either.
OK. It seems we can have at least two different timings for this panel,
the VGA timing above and the QVGA timings that LDP uses that are listed
in the .dts changes.
> Although if the MO gpio is not controlled by the driver, we should tell
> the driver whether that gpio is high or low.
What do you have in mind for telling that? We should also tell the
orientation of the panel:
EVM VGA omapfb.rotate=3
LDP QVGA omapfb.rotate=0
Do you have something in mind for that?
> At the moment our display drivers are OMAP specific, and for that reason
> we should prefix the compatible strings with "omapdss,". For example,
> drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
>
> { .compatible = "omapdss,panel-dsi-cm", },
>
> But we should still have the right compatible string in the .dts, so we
> convert the compatible name in arch/arm/mach-omap2/display.c, with
> 'dss_compat_conv_list' array, to which this panel's name should be added.
Oh so what do you want to have in the .dts file then?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tony Lindgren @ 2014-05-09 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536C7EA7.5000306@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:08]:
> On 09/05/14 02:36, Tony Lindgren wrote:
>
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
> > @@ -0,0 +1,82 @@
> > +/*
> > + * Common file for omap dpi panels with QVGA and reset pins
> > + *
> > + * Note that the board specifc DTS file needs to specify
> > + * at minimum the GPIO enable-gpios for display, and
> > + * gpios for gpio-backlight.
> > + */
>
> This looks very board specific to me... The regulator and the use of
> mcspi1 depend on the board, so this file can't be used on just any omap
> board with the same panel. And this can (probably) only be used on
> boards with a single display. Do those boards have tv-out?
Yes there's also TV out and DVI on omap3-evm, LDP just has DVI.
It seems that all omap3 boards using this are pretty much wired
the same way.
> So I have nothing against having common files, but shouldn't this be
> named something more specific? If the boards involved are TI's OMAP3
> development boards, maybe this should be something like...
> omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.
Yeah let's use omap3-panel-sharp-ls037v7dw01.dtsi. Looking at the
legacy board files that should cover quite a few of them.
I guess it might also work on 2430sdp, but let's assume omap3
for now.
> > +/ {
> > + aliases {
> > + display0 = &lcd0;
> > + };
> > +
> > + backlight0: backlight {
> > + compatible = "gpio-backlight";
> > + };
> > +
> > + /* 3.3V GPIO controlled regulator for LCD_ENVDD */
> > + lcd_3v3: regulator-lcd-3v3 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "lcd_3v3";
> > + regulator-min-microvolt = <3300000>;
> > + regulator-max-microvolt = <3300000>;
> > + startup-delay-us = <70000>;
> > + regulator-always-on;
>
> Why always-on?
Oops, yeah that should not be there. The GPIO is board specific.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-09 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536C924E.5000307@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:31]:
> On 09/05/14 02:33, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [140507 11:00]:
> >> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
> >>> On 07/05/14 18:03, Tony Lindgren wrote:
> >>>>
> >>>> BTW, I'm also personally fine with all five gpios showing in a single
> >>>> gpios property, I'm not too exited about naming anything in DT..
> >>>
> >>> I don't have a strong opinion here. I don't have much experience with
> >>> DT, especially with making bindings compatible with other ones.
> >>>
> >>> I'd just forget the simple-panel, and have single gpio array.
> >>
> >> Well if it's a don't care flag for both of us, let's try to use
> >> the existing standard for simple-panel.txt and add mode-gpios
> >> property. I'll post a patch for that.
> >
> > Here's an updated version using enable-gpios, reset-gpios and
> > mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> > that's currently specific to this panel only.
> >
> > Also updated for -EPROBE_DEFER handling, tested that by changing
> > one of the GPIOs to be a twl4030 GPIO.
>
> To speed things up a bit, I made the changes I suggested. Compile tested
> only.
OK thanks did not get the penguin with it so need to look at it a bit
more.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-09 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536C8B70.1000306@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 01:02]:
> On 09/05/14 02:20, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [140429 16:53]:
> >> Otherwise we can get often errors like the following and the
> >> display won't come on:
> >>
> >> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> >> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> >> the output with video overlays disabled
> >>
> >> There are some earlier references to this issue:
> >>
> >> http://www.spinics.net/lists/linux-omap/msg59511.html
> >> http://www.spinics.net/lists/linux-omap/msg59724.html
> >>
> >> It seems that it's safe to set the lower values even for 3630.
> >> If we can confirm that 3630 works with the higher values
> >> reliably we can add further detection.
> >
> > BTW, I'm also seeing this warning on 3730-evm it may be related:
> >
> > [ 3.523101] ------------[ cut here ]------------
> > [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
> > [ 3.538360] clk rate mismatch: 108000000 != 115200000
> > [ 3.543518] Modules linked in:
>
> Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
> framework calculates the clock rate differently than the dss. Or do we
> have different clock.dts files used for 3730 and 3630?
OK pasted to the other email in this thread.
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-09 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536C860E.1000501@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140509 00:39]:
> On 30/04/14 02:52, Tony Lindgren wrote:
> > Otherwise we can get often errors like the following and the
> > display won't come on:
> >
> > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> > omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> > the output with video overlays disabled
> >
> > There are some earlier references to this issue:
> >
> > http://www.spinics.net/lists/linux-omap/msg59511.html
> > http://www.spinics.net/lists/linux-omap/msg59724.html
>
> Those don't sound like the same issue, but it's hard to say. What kind
> of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
> without this patch?
Without this patch:
# cat /sys/kernel/debug/omapdss/clk
[ 24.833831] DSS: dss_runtime_get
[ 24.837554] DSS: dss_runtime_put
[ 24.840972] DISPC: dispc_runtime_get
[ 24.844757] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 57600000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 57600000
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 57600000 lck div 1
pck 19200000 pck div 3
With this patch:
# cat /sys/kernel/debug/omapdss/clk
[ 34.580688] DSS: dss_runtime_get
[ 34.584197] DSS: dss_runtime_put
[ 34.587768] DISPC: dispc_runtime_get
[ 34.591552] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 108000000
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 108000000
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 108000000 lck div 1
pck 18000000 pck div 6
> What resolution do you have? If it's a very high resolution (say, DVI
> output to a monitor), it could just be an issue of
> not-enough-memory-bandwidth.
This is just the 3730-evm with the Sharp VGA panel mentioned in
this series.
> > It seems that it's safe to set the lower values even for 3630.
> > If we can confirm that 3630 works with the higher values
> > reliably we can add further detection.
> >
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> > index d55266c..ad6561f 100644
> > --- a/drivers/video/fbdev/omap2/dss/dss.c
> > +++ b/drivers/video/fbdev/omap2/dss/dss.c
> > @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
> > .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
> > };
> >
> > +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> > static const struct dss_features omap3630_dss_feats __initconst = {
> > - .fck_div_max = 32,
> > - .dss_fck_multiplier = 1,
> > + .fck_div_max = 16,
> > + .dss_fck_multiplier = 2,
>
> These values tell about the clock hardware, they are not settings that
> can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
> and a divider with maximum value of 16.
>
> Tomi
>
>
^ permalink raw reply
* [PATCH] video: of: display_timing: fix default native-mode setting
From: Boris BREZILLON @ 2014-05-09 13:53 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Boris BREZILLON
Set native mode to the first child node of the display-timings node and not
the first child node of the display-timings parent node.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
---
drivers/video/of_display_timing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/of_display_timing.c b/drivers/video/of_display_timing.c
index ba5b40f..19dd752 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -164,7 +164,7 @@ struct display_timings *of_get_display_timings(struct device_node *np)
entry = of_parse_phandle(timings_np, "native-mode", 0);
/* assume first child as native mode if none provided */
if (!entry)
- entry = of_get_next_child(np, NULL);
+ entry = of_get_next_child(timings_np, NULL);
/* if there is no child, it is useless to go on */
if (!entry) {
pr_err("%s: no timing specifications given\n",
--
1.8.3.2
^ permalink raw reply related
* [PATCH 5/5] Doc/DT: hdmi-connector: add HPD GPIO documentation
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen, devicetree
In-Reply-To: <1399638727-23254-1-git-send-email-tomi.valkeinen@ti.com>
Add binding documentation for HDMI connector's HPD GPIO.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
---
Documentation/devicetree/bindings/video/hdmi-connector.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
index ccccc19e2573..acd5668b1ce1 100644
--- a/Documentation/devicetree/bindings/video/hdmi-connector.txt
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -7,6 +7,7 @@ Required properties:
Optional properties:
- label: a symbolic name for the connector
+- hpd-gpios: HPD GPIO number
Required nodes:
- Video port for HDMI input
--
1.9.1
^ permalink raw reply related
* [PATCH 4/5] OMAPDSS: connector-hdmi: hpd support
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1399638727-23254-1-git-send-email-tomi.valkeinen@ti.com>
Add support to handle HPD GPIO in the HDMI connector driver. For the
time being, the driver only uses HPD GPIO to report is the cable is
connected via detect() calll.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../fbdev/omap2/displays-new/connector-hdmi.c | 25 +++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 29ed21b9dce5..4420ccb69aa9 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <drm/drm_edid.h>
@@ -43,6 +44,8 @@ struct panel_drv_data {
struct device *dev;
struct omap_video_timings timings;
+
+ int hpd_gpio;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -161,7 +164,10 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
- return in->ops.hdmi->detect(in);
+ if (gpio_is_valid(ddata->hpd_gpio))
+ return gpio_get_value_cansleep(ddata->hpd_gpio);
+ else
+ return in->ops.hdmi->detect(in);
}
static int hdmic_audio_enable(struct omap_dss_device *dssdev)
@@ -288,6 +294,8 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
pdata = dev_get_platdata(&pdev->dev);
+ ddata->hpd_gpio = -ENODEV;
+
in = omap_dss_find_output(pdata->source);
if (in = NULL) {
dev_err(&pdev->dev, "Failed to find video source\n");
@@ -307,6 +315,14 @@ static int hdmic_probe_of(struct platform_device *pdev)
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
struct omap_dss_device *in;
+ int gpio;
+
+ /* HPD GPIO */
+ gpio = of_get_named_gpio(node, "hpd-gpios", 0);
+ if (gpio_is_valid(gpio))
+ ddata->hpd_gpio = gpio;
+ else
+ ddata->hpd_gpio = -ENODEV;
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
@@ -344,6 +360,13 @@ static int hdmic_probe(struct platform_device *pdev)
return -ENODEV;
}
+ if (gpio_is_valid(ddata->hpd_gpio)) {
+ r = devm_gpio_request_one(&pdev->dev, ddata->hpd_gpio,
+ GPIOF_DIR_IN, "hdmi_hpd");
+ if (r)
+ goto err_reg;
+ }
+
ddata->timings = hdmic_default_timings;
dssdev = &ddata->dssdev;
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] OMAPDSS: remove unused macros
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1399638727-23254-1-git-send-email-tomi.valkeinen@ti.com>
Macros to_dss_driver() and to_dss_device() are no longer used, and the
latter doesn't even work. Remove them.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
include/video/omapdss.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 6adb44534606..def9f0b739c4 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -964,9 +964,6 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings,
bool mem_to_mem);
-#define to_dss_driver(x) container_of((x), struct omap_dss_driver, driver)
-#define to_dss_device(x) container_of((x), struct omap_dss_device, old_dev)
-
int omapdss_compat_init(void);
void omapdss_compat_uninit(void);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/5] OMAPDSS: remove venc_panel.c
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
In-Reply-To: <1399638727-23254-1-git-send-email-tomi.valkeinen@ti.com>
The use of venc_panel.c was removed in
09d2e7cdebd53b7572380a215008b334ff6321a5 (OMAPDSS: VENC: remove code
related to old panel model), but the file itself was left behind. Remove
the unused file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/venc_panel.c | 232 -----------------------------
1 file changed, 232 deletions(-)
delete mode 100644 drivers/video/fbdev/omap2/dss/venc_panel.c
diff --git a/drivers/video/fbdev/omap2/dss/venc_panel.c b/drivers/video/fbdev/omap2/dss/venc_panel.c
deleted file mode 100644
index af68cd444d7e..000000000000
--- a/drivers/video/fbdev/omap2/dss/venc_panel.c
+++ /dev/null
@@ -1,232 +0,0 @@
-/*
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
- *
- * VENC panel driver
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <linux/kernel.h>
-#include <linux/err.h>
-#include <linux/io.h>
-#include <linux/mutex.h>
-#include <linux/module.h>
-
-#include <video/omapdss.h>
-
-#include "dss.h"
-
-static struct {
- struct mutex lock;
-} venc_panel;
-
-static ssize_t display_output_type_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- const char *ret;
-
- switch (dssdev->phy.venc.type) {
- case OMAP_DSS_VENC_TYPE_COMPOSITE:
- ret = "composite";
- break;
- case OMAP_DSS_VENC_TYPE_SVIDEO:
- ret = "svideo";
- break;
- default:
- return -EINVAL;
- }
-
- return snprintf(buf, PAGE_SIZE, "%s\n", ret);
-}
-
-static ssize_t display_output_type_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t size)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- enum omap_dss_venc_type new_type;
-
- if (sysfs_streq("composite", buf))
- new_type = OMAP_DSS_VENC_TYPE_COMPOSITE;
- else if (sysfs_streq("svideo", buf))
- new_type = OMAP_DSS_VENC_TYPE_SVIDEO;
- else
- return -EINVAL;
-
- mutex_lock(&venc_panel.lock);
-
- if (dssdev->phy.venc.type != new_type) {
- dssdev->phy.venc.type = new_type;
- omapdss_venc_set_type(dssdev, new_type);
- if (dssdev->state = OMAP_DSS_DISPLAY_ACTIVE) {
- omapdss_venc_display_disable(dssdev);
- omapdss_venc_display_enable(dssdev);
- }
- }
-
- mutex_unlock(&venc_panel.lock);
-
- return size;
-}
-
-static DEVICE_ATTR(output_type, S_IRUGO | S_IWUSR,
- display_output_type_show, display_output_type_store);
-
-static int venc_panel_probe(struct omap_dss_device *dssdev)
-{
- /* set default timings to PAL */
- const struct omap_video_timings default_timings = {
- .x_res = 720,
- .y_res = 574,
- .pixelclock = 13500000,
- .hsw = 64,
- .hfp = 12,
- .hbp = 68,
- .vsw = 5,
- .vfp = 5,
- .vbp = 41,
-
- .vsync_level = OMAPDSS_SIG_ACTIVE_HIGH,
- .hsync_level = OMAPDSS_SIG_ACTIVE_HIGH,
-
- .interlace = true,
- };
-
- mutex_init(&venc_panel.lock);
-
- dssdev->panel.timings = default_timings;
-
- return device_create_file(dssdev->dev, &dev_attr_output_type);
-}
-
-static void venc_panel_remove(struct omap_dss_device *dssdev)
-{
- device_remove_file(dssdev->dev, &dev_attr_output_type);
-}
-
-static int venc_panel_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- dev_dbg(dssdev->dev, "venc_panel_enable\n");
-
- mutex_lock(&venc_panel.lock);
-
- if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED) {
- r = -EINVAL;
- goto err;
- }
-
- omapdss_venc_set_timings(dssdev, &dssdev->panel.timings);
- omapdss_venc_set_type(dssdev, dssdev->phy.venc.type);
- omapdss_venc_invert_vid_out_polarity(dssdev,
- dssdev->phy.venc.invert_polarity);
-
- r = omapdss_venc_display_enable(dssdev);
- if (r)
- goto err;
-
- dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
-
- mutex_unlock(&venc_panel.lock);
-
- return 0;
-err:
- mutex_unlock(&venc_panel.lock);
-
- return r;
-}
-
-static void venc_panel_disable(struct omap_dss_device *dssdev)
-{
- dev_dbg(dssdev->dev, "venc_panel_disable\n");
-
- mutex_lock(&venc_panel.lock);
-
- if (dssdev->state = OMAP_DSS_DISPLAY_DISABLED)
- goto end;
-
- omapdss_venc_display_disable(dssdev);
-
- dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
-end:
- mutex_unlock(&venc_panel.lock);
-}
-
-static void venc_panel_set_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- dev_dbg(dssdev->dev, "venc_panel_set_timings\n");
-
- mutex_lock(&venc_panel.lock);
-
- omapdss_venc_set_timings(dssdev, timings);
- dssdev->panel.timings = *timings;
-
- mutex_unlock(&venc_panel.lock);
-}
-
-static int venc_panel_check_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- dev_dbg(dssdev->dev, "venc_panel_check_timings\n");
-
- return omapdss_venc_check_timings(dssdev, timings);
-}
-
-static u32 venc_panel_get_wss(struct omap_dss_device *dssdev)
-{
- dev_dbg(dssdev->dev, "venc_panel_get_wss\n");
-
- return omapdss_venc_get_wss(dssdev);
-}
-
-static int venc_panel_set_wss(struct omap_dss_device *dssdev, u32 wss)
-{
- dev_dbg(dssdev->dev, "venc_panel_set_wss\n");
-
- return omapdss_venc_set_wss(dssdev, wss);
-}
-
-static struct omap_dss_driver venc_driver = {
- .probe = venc_panel_probe,
- .remove = venc_panel_remove,
-
- .enable = venc_panel_enable,
- .disable = venc_panel_disable,
-
- .get_resolution = omapdss_default_get_resolution,
- .get_recommended_bpp = omapdss_default_get_recommended_bpp,
-
- .set_timings = venc_panel_set_timings,
- .check_timings = venc_panel_check_timings,
-
- .get_wss = venc_panel_get_wss,
- .set_wss = venc_panel_set_wss,
-
- .driver = {
- .name = "venc",
- .owner = THIS_MODULE,
- },
-};
-
-int venc_panel_init(void)
-{
- return omap_dss_register_driver(&venc_driver);
-}
-
-void venc_panel_exit(void)
-{
- omap_dss_unregister_driver(&venc_driver);
-}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/5] OMAPDSS: Fix writes to DISPC_POL_FREQ
From: Tomi Valkeinen @ 2014-05-09 12:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen
When omapdss writes to DISPC_POL_FREQ register, it always ORs the bits
with the current contents of the register, never clearing the old ones,
causing wrong signal polarity settings.
As we write all the bits in DISPC_POL_FREQ, we don't need to care about
the current contents of the register. So fix the issue by constructing
new register value from scratch.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/omap2/dss/dispc.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c
index f18397c33e8f..a22c64e26172 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -2945,13 +2945,13 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel channel, int hsw,
BUG();
}
- l = dispc_read_reg(DISPC_POL_FREQ(channel));
- l |= FLD_VAL(onoff, 17, 17);
- l |= FLD_VAL(rf, 16, 16);
- l |= FLD_VAL(de_level, 15, 15);
- l |= FLD_VAL(ipc, 14, 14);
- l |= FLD_VAL(hsync_level, 13, 13);
- l |= FLD_VAL(vsync_level, 12, 12);
+ l = FLD_VAL(onoff, 17, 17) |
+ FLD_VAL(rf, 16, 16) |
+ FLD_VAL(de_level, 15, 15) |
+ FLD_VAL(ipc, 14, 14) |
+ FLD_VAL(hsync_level, 13, 13) |
+ FLD_VAL(vsync_level, 12, 12);
+
dispc_write_reg(DISPC_POL_FREQ(channel), l);
}
--
1.9.1
^ permalink raw reply related
* Re: some divide by zero bugs in >fb_check_var() functions
From: Tomi Valkeinen @ 2014-05-09 10:18 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On 02/05/14 18:48, Geert Uytterhoeven wrote:
> On Tue, Jan 28, 2014 at 10:28 PM, Kees Cook <keescook@chromium.org> wrote:
>> Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
>> zero? Seems like it'd be trivial to check for those in fb_set_var()?
>
> pixclock could be zero for some special fixed type of display that doesn't
> have timings. Hmm, you could use 1 for that. Are there any in-tree users?
I have no idea if we have such drivers. But in that case I would rather
use pixel clock of 0 than 1. It's usually much easier to notice uses of
non-valid value if it's 0 than 1.
But maybe that'd warrant a new flag somewhere, to mark the fb as having
no timings.
> Anyway, the checker reported issues with specific drivers, not with the core,
> right?
Yes, but the issue seemed to be so common that it'd be nice if the core
would check it.
But looking at the longer list sent by Dan, it looks to me that there
are also lots of cases where it must be the driver doing the checks.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] uvesafb: abort initialization if video=uvesafb is not set
From: Tomi Valkeinen @ 2014-05-09 10:06 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396791873-22606-1-git-send-email-lxnay@sabayon.org>
[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]
On 06/04/14 16:44, lxnay@sabayon.org wrote:
> From: Fabio Erculiani <lxnay@sabayon.org>
>
> This patch makes possible to ship kernels with both vesafb and uvesafb
> in order to guarantee a smooth transition to uvesafb and cope with
> potential incompatibiles introduced by uvesafb making possible to disable
> it via cmdline.
>
> In case both vesafb and uvesafb are built-in, the kernel will try to
> initialize both, which makes possible to select the wanted one using
> either video=vesafb:... or video=uvesafb:....
> In this way, old distro installations will keep working as before while
> new ones can adopt video=uvesafb.
>
> The behaviour does not change if uvesafb is built as a module.
> ---
> drivers/video/uvesafb.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
> index d428445..04c4742 100644
> --- a/drivers/video/uvesafb.c
> +++ b/drivers/video/uvesafb.c
> @@ -1957,6 +1957,10 @@ static int uvesafb_init(void)
>
> if (fb_get_options("uvesafb", &option))
> return -ENODEV;
> + if (!option || !*option)
> + /* if vesafb is enabled, this will make possible to fallback to it */
> + return -ENODEV;
> +
> uvesafb_setup(option);
> #endif
> err = cn_add_callback(&uvesafb_cn_id, "uvesafb", uvesafb_cn_callback);
>
I'm not familiar with vesa fbs, so I'd like to hear from other people if
this change is ok. Cc'd a bunch of random people from git log.
Reviewed-by, tested-by, acked-by from anyone?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC 1/6] omapdss: remove check for simpler port/endpoint binding
From: Tomi Valkeinen @ 2014-05-09 9:59 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1399540517-17883-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]
On 08/05/14 12:15, Archit Taneja wrote:
> The support for simpler port/endpoint binding was removed in the merged version
> of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
> port exists. Remove this as this doesn't work.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/dss.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..31ef262 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -784,12 +784,8 @@ static int __init dss_init_ports(struct platform_device *pdev)
> return 0;
>
> port = omapdss_of_get_next_port(parent, NULL);
> - if (!port) {
> -#ifdef CONFIG_OMAP2_DSS_DPI
> - dpi_init_port(pdev, parent);
> -#endif
> + if (!port)
> return 0;
> - }
>
> do {
> u32 reg;
>
I'll try to find time to review the rest, but I'll queue this one
already for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/3] Add display support for gta04 device
From: Tomi Valkeinen @ 2014-05-09 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1399580212-5183-1-git-send-email-marek@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On 08/05/14 23:16, Marek Belisko wrote:
> This 3 patches adding display support for openmoko gta04 device.
> First patch add DT bindings for topolly td028 panel. Second add description for
> dss + panel and third fix panel probing when panel is compiled as module.
>
> Changes from v2:
> - add missing 'port' node for dpi_out endpoint (comment from Tomi Valkeinen)
>
> Changes from v1:
> - extend panel compatible string by 'omapdss'
> - add tpo-td028 panel to dss_compat_conv_list
> - add MODULE_ALIAS macro to properly probe panel when is compiled as module
>
> Marek Belisko (3):
> omapdss: panel-tpo-td028ec1: Add DT support.
> ARM: dts: oma3-gta04: Add display support
> omapdss: panel-tpo-td028ec1: Add module alias
>
> .../bindings/video/toppoly,td028ttec1.txt | 30 ++++++++
> arch/arm/boot/dts/omap3-gta04.dts | 87 ++++++++++++++++++++++
> arch/arm/mach-omap2/display.c | 1 +
> .../omap2/displays-new/panel-tpo-td028ttec1.c | 33 +++++++-
> 4 files changed, 150 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
>
I think this series looks fine. I'll pick it up.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] OMAPDSS: Add support for panel ls037v7dw01
From: Tomi Valkeinen @ 2014-05-09 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140505184138.GB15463@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On 05/05/14 21:41, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>> Hi all,
>>
>> Here are few patches to add devicetree support for panel ls037v7dw01
>> that's found on many omap3 boards. They seem to be often mis-configured
>> as various panel dpi entries, but really should be move to use panel
>> ls037v7dw01 instead. This panel is found at least on the omap3 sdp,
>> ldp, omap3 evm and few other development boards.
>
> Tomi, assuming no more comments, do you want to pick up the first
> three patches of this series? I can queue the .dts changes or you
> can also set up a separate .dts changes branch for DSS that I can
> merge in too.
If it's all the same to you, I'd like to collect all display related
arch/arm/ patches into my tree, and I'll send you a merge request when
it's stable.
I already have OMAP5 and AM43xx stuff there.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3] video: mx3fb: Add backlight control support
From: Tomi Valkeinen @ 2014-05-09 9:11 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1399559916-15183-1-git-send-email-alexander.stein@systec-electronic.com>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On 08/05/14 17:38, Alexander Stein wrote:
> This patch add backlight control support to allow dimming the backlight
> using the internal PWM. Currently the brightness is set fixed to a
> maximum of 255.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
> Changes in v3:
> * Add a more descriptive commit message
>
> Changes in v2:
> * rebased to v3.15-rc4
>
> drivers/video/fbdev/mx3fb.c | 98 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 98 insertions(+)
>
> diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
> index 142e860..10a7244 100644
> --- a/drivers/video/fbdev/mx3fb.c
> +++ b/drivers/video/fbdev/mx3fb.c
> @@ -27,6 +27,7 @@
> #include <linux/clk.h>
> #include <linux/mutex.h>
> #include <linux/dma/ipu-dma.h>
> +#include <linux/backlight.h>
>
> #include <linux/platform_data/dma-imx.h>
> #include <linux/platform_data/video-mx3fb.h>
> @@ -34,6 +35,12 @@
> #include <asm/io.h>
> #include <asm/uaccess.h>
>
> +#if defined(CONFIG_BACKLIGHT_CLASS_DEVICE) || \
> + (defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE) && \
> + defined(CONFIG_MX3FB_MODULE))
> +#define PWM_BACKLIGHT_AVAILABLE
> +#endif
I'm not very fond of this kind of ifdeffery. It makes the driver rather
messy and confusing, especially if large blocks of code are inside the
ifdefs.
Can't you just make the driver select BACKLIGHT_CLASS_DEVICE?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Linus Walleij @ 2014-05-09 9:06 UTC (permalink / raw)
To: Jingoo Han
Cc: Tony Lindgren, Lee Jones, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, Linux-OMAP, Bryan Wu,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Alexandre Courbot, Russell King
In-Reply-To: <000001cf6b38$a6a3ffa0$f3ebfee0$%han@samsung.com>
On Fri, May 9, 2014 at 5:42 AM, Jingoo Han <jg1.han@samsung.com> wrote:
> Linus Walleij,
> Is there any reason to keep these two functions such as
> gpiod_set_raw_value_cansleep() and gpiod_set_raw_value()?
Yes, the former can *not* be called from interrupt context,
and thus erroneous usage can be detected with runtime checks.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-09 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140508233300.GI2198@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 7924 bytes --]
On 09/05/14 02:33, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140507 11:00]:
>> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140507 09:03]:
>>> On 07/05/14 18:03, Tony Lindgren wrote:
>>>>
>>>> BTW, I'm also personally fine with all five gpios showing in a single
>>>> gpios property, I'm not too exited about naming anything in DT..
>>>
>>> I don't have a strong opinion here. I don't have much experience with
>>> DT, especially with making bindings compatible with other ones.
>>>
>>> I'd just forget the simple-panel, and have single gpio array.
>>
>> Well if it's a don't care flag for both of us, let's try to use
>> the existing standard for simple-panel.txt and add mode-gpios
>> property. I'll post a patch for that.
>
> Here's an updated version using enable-gpios, reset-gpios and
> mode-gpios. So it follows simple-panel.txt and adds mode-gpios
> that's currently specific to this panel only.
>
> Also updated for -EPROBE_DEFER handling, tested that by changing
> one of the GPIOs to be a twl4030 GPIO.
To speed things up a bit, I made the changes I suggested. Compile tested
only.
From f8360778e8bc96096cbb1793a18a8c240376ca09 Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Add device tree support for sharp-ls037v7dw01 panel.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../bindings/video/sharp,ls037v7dw01.txt | 44 ++++++++++
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 95 +++++++++++++++++++++-
2 files changed, 136 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index 000000000000..2a60fd9a2607
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===================================
+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+};
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index 8adde628ad38..91eeb2ec93a8 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-
+#include <linux/regulator/consumer.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -95,12 +98,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
+ if (ddata->vcc) {
+ r = regulator_enable(ddata->vcc);
+ if (r != 0)
+ return r;
+ }
+
r = in->ops.dpi->enable(in);
- if (r)
+ if (r) {
+ regulator_disable(ddata->vcc);
return r;
+ }
/* wait couple of vsyncs until enabling the LCD */
msleep(50);
@@ -136,6 +148,9 @@ static void sharp_ls_disable(struct omap_dss_device *dssdev)
in->ops.dpi->disable(in);
+ if (ddata->vcc)
+ regulator_disable(ddata->vcc);
+
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
}
@@ -243,6 +258,68 @@ static int sharp_ls_probe_pdata(struct platform_device *pdev)
return 0;
}
+static struct gpio_desc *
+sharp_ls_get_gpio_of(struct device *dev, int index, int val, char *desc)
+{
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get_index(dev, desc, index);
+ if (IS_ERR(gpio))
+ return gpio;
+
+ gpiod_direction_output(gpio, val);
+
+ return gpio;
+}
+
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ ddata->vcc = devm_regulator_get(&pdev->dev, "envdd");
+ if (IS_ERR(ddata->vcc)) {
+ dev_err(&pdev->dev, "failed to get regulator\n");
+ return PTR_ERR(ddata->vcc);
+ }
+
+ /* lcd INI */
+ ddata->ini_gpio = sharp_ls_get_gpio_of(&pdev->dev, 3, 0, "enable");
+ if (PTR_ERR(ddata->ini_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd RESB */
+ ddata->resb_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "reset");
+ if (PTR_ERR(ddata->resb_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd MO */
+ ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 0, "mode");
+ if (PTR_ERR(ddata->mo_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd LR */
+ ddata->lr_gpio = sharp_ls_get_gpio_of(&pdev->dev, 1, 1, "mode");
+ if (PTR_ERR(ddata->lr_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ /* lcd UD */
+ ddata->ud_gpio = sharp_ls_get_gpio_of(&pdev->dev, 2, 1, "mode");
+ if (PTR_ERR(ddata->ud_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int sharp_ls_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -259,6 +336,10 @@ static int sharp_ls_probe(struct platform_device *pdev)
r = sharp_ls_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = sharp_ls_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -302,12 +383,20 @@ static int __exit sharp_ls_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = "omapdss,sharp,ls037v7dw01", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, sharp_ls_of_match);
+
static struct platform_driver sharp_ls_driver = {
.probe = sharp_ls_probe,
.remove = __exit_p(sharp_ls_remove),
.driver = {
.name = "panel-sharp-ls037v7dw01",
.owner = THIS_MODULE,
+ .of_match_table = sharp_ls_of_match,
},
};
--
1.9.1
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-09 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140508232006.GG2198@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
On 09/05/14 02:20, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [140429 16:53]:
>> Otherwise we can get often errors like the following and the
>> display won't come on:
>>
>> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
>> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
>> the output with video overlays disabled
>>
>> There are some earlier references to this issue:
>>
>> http://www.spinics.net/lists/linux-omap/msg59511.html
>> http://www.spinics.net/lists/linux-omap/msg59724.html
>>
>> It seems that it's safe to set the lower values even for 3630.
>> If we can confirm that 3630 works with the higher values
>> reliably we can add further detection.
>
> BTW, I'm also seeing this warning on 3730-evm it may be related:
>
> [ 3.523101] ------------[ cut here ]------------
> [ 3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c()
> [ 3.538360] clk rate mismatch: 108000000 != 115200000
> [ 3.543518] Modules linked in:
Hmm... Can you paste the clk_summary from debugfs? Somehow the clock
framework calculates the clock rate differently than the dss. Or do we
have different clock.dts files used for 3730 and 3630?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-09 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398815562-24113-2-git-send-email-tony@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
On 30/04/14 02:52, Tony Lindgren wrote:
> Otherwise we can get often errors like the following and the
> display won't come on:
>
> omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
> omapdss APPLY error: SYNC_LOST on channel lcd, restarting
> the output with video overlays disabled
>
> There are some earlier references to this issue:
>
> http://www.spinics.net/lists/linux-omap/msg59511.html
> http://www.spinics.net/lists/linux-omap/msg59724.html
Those don't sound like the same issue, but it's hard to say. What kind
of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
without this patch?
What resolution do you have? If it's a very high resolution (say, DVI
output to a monitor), it could just be an issue of
not-enough-memory-bandwidth.
> It seems that it's safe to set the lower values even for 3630.
> If we can confirm that 3630 works with the higher values
> reliably we can add further detection.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/dss.c b/drivers/video/fbdev/omap2/dss/dss.c
> index d55266c..ad6561f 100644
> --- a/drivers/video/fbdev/omap2/dss/dss.c
> +++ b/drivers/video/fbdev/omap2/dss/dss.c
> @@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats __initconst = {
> .dpi_select_source = &dss_dpi_select_source_omap2_omap3,
> };
>
> +/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
> static const struct dss_features omap3630_dss_feats __initconst = {
> - .fck_div_max = 32,
> - .dss_fck_multiplier = 1,
> + .fck_div_max = 16,
> + .dss_fck_multiplier = 2,
These values tell about the clock hardware, they are not settings that
can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
and a divider with maximum value of 16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox