* [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson,
tomi.valkeinen, detheridge, Jyri Sarha
Since RFC version of the patch set:
- Split callbacks removal patch away from "Integrated ASoC DAI
component driver implementation" patches for easier reading
This set of patches fixes OMAP4+ HDMI audio. The structure of the
implementatin looks a bit different than before. Instead of creating a
driver specific API for a separate ASoC component driver to connect
to, this implementation integrates an the component driver into the
HDMI driver.
The idea is to use an existing ASoC component driver API instead of
creating a new custom API for each HDMI IP and to avoid splitting the
driver to half for separate video and audio parts connected with the
API.
The new implementation also uses simple-audio-card for a machine
driver instead of having its own HW specific machine driver.
The patches are based on 3.15-rc2 merged with
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
and
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-omap5
Everything is pushed here here:
git://git.ti.com/~jyrisarha/ti-linux-kernel/jyrisarhas-audio-video-linux-feature-tree.git omap-hdmi-audio
Best regards,
Jyri
Jyri Sarha (19):
ASoC: omap-pcm: Move omap-pcm under include/sound
OMAPDSS: hdmi-common: Add hdmi_dss_audio_from_hw_params()
OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver
OMAPDSS: hdmi4: Integrated ASoC DAI component driver implementation
OMAPDSS: Kconfig: Add depencies and help section to
OMAP4_DSS_HDMI_AUDIO
OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO
OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver
OMAPDSS: hdmi5: Integrated ASoC DAI component driver implementation
OMAPDSS: Kconfig: Add depencies and help section to
OMAP5_DSS_HDMI_AUDIO
ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
OMAPDSS: Remove obsolete audio code
ARM: omap4.dtsi: Add audio related parametes to hdmi node
ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
ARM: omap5.dtsi: Add audio related parameters to hdmi node
ARM: omap5-uevm.dts: Add hdmi audio related nodes
ARM: omap2plus_defconfig: Build DSS HDMI support for OMAP4 in kernel
ARM: omap2plus_defconfig: Enable OMAP5 HDMI support
ARM: omap2plus_defconfig: Enable OMAP4+ HDMI audio support
.../devicetree/bindings/video/ti,omap4-dss.txt | 4 +
.../devicetree/bindings/video/ti,omap5-dss.txt | 4 +
arch/arm/boot/dts/omap4-panda-common.dtsi | 21 +-
arch/arm/boot/dts/omap4.dtsi | 2 +
arch/arm/boot/dts/omap5-uevm.dts | 19 +
arch/arm/boot/dts/omap5.dtsi | 2 +
arch/arm/configs/omap2plus_defconfig | 20 +-
.../fbdev/omap2/displays-new/connector-hdmi.c | 99 ------
.../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ---
drivers/video/fbdev/omap2/dss/Kconfig | 19 +-
drivers/video/fbdev/omap2/dss/hdmi.h | 8 +-
drivers/video/fbdev/omap2/dss/hdmi4.c | 216 ++++++++----
drivers/video/fbdev/omap2/dss/hdmi5.c | 216 ++++++++----
drivers/video/fbdev/omap2/dss/hdmi5_core.c | 2 +-
drivers/video/fbdev/omap2/dss/hdmi_common.c | 117 ++++++-
include/sound/omap-pcm.h | 30 ++
include/video/omapdss.h | 31 --
sound/soc/davinci/davinci-mcasp.c | 2 +-
sound/soc/omap/Kconfig | 13 -
sound/soc/omap/Makefile | 4 -
sound/soc/omap/omap-dmic.c | 2 +-
sound/soc/omap/omap-hdmi-card.c | 87 -----
sound/soc/omap/omap-hdmi.c | 364 --------------------
sound/soc/omap/omap-hdmi.h | 38 --
sound/soc/omap/omap-mcbsp.c | 2 +-
sound/soc/omap/omap-mcpdm.c | 2 +-
sound/soc/omap/omap-pcm.h | 30 --
27 files changed, 540 insertions(+), 870 deletions(-)
create mode 100644 include/sound/omap-pcm.h
delete mode 100644 sound/soc/omap/omap-hdmi-card.c
delete mode 100644 sound/soc/omap/omap-hdmi.c
delete mode 100644 sound/soc/omap/omap-hdmi.h
delete mode 100644 sound/soc/omap/omap-pcm.h
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH] uvesafb: abort initialization if video=uvesafb is not set
From: Wang YanQing @ 2014-05-12 8:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396791873-22606-1-git-send-email-lxnay@sabayon.org>
On Fri, May 09, 2014 at 01:06:44PM +0300, Tomi Valkeinen wrote:
> 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 don't think it is right, this patch force uvesafb user to set uvesafb kernel cmdline
options, but what about the default setting? If user use UVESAFB_DEFAULT_MODE before, then
he or she have to add useless cmdline options to make uvesafb work for it in future kernel.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Andreas Müller @ 2014-05-12 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140511144209.GA28266@atomide.com>
On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]:
>> 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
>
> Sorry I'm a bit confused now. Is the reboot issue a separate issue
> related to the twl4030 generic scripts for 3530?
>
> And then this patch fixes dm3730 wake-up (from suspend?) issues?
>
> Or do we have some other bug where we wrongly hit omap3630_dss_feats
> on 3530 somehow?
(What I think) I have done: Have 3.14.3 still booting with legacy
board init (please don't kill me for that). Without applying your
patch old OMAP3530 crashed at every reboot with SYNCH_LOST.
After applying your patch reboot works fine.
Looking into id-code makes me wonder what changes on 36xx-features do
to 35xx devices (treated as 34xx - right?). The only way that this
happens is for unknown hawkeye fallthough. I suggest you simply forget
my note and I will find out what really 'fixed' dss reboot problem.
Andreas
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-12 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509155504.GE17814@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]
On 09/05/14 18:55, Tony Lindgren wrote:
>> 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?
Hmm, right. I guess all we can do is have boolean flags in the .dts for
MO, LR and UD, which tells if the respective pins are hard-wires high or
low. And say in the documentation that you must either have a proper
GPIO, or use the flag, but not both.
The panel mounting orientation is a different matter. But I think it is
also something we should specify in the .dts. However, we don't have any
SW support to handle it, and it's a bit unclear to me how it should be
handled, so I think that has to be left for later.
>> 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?
The .dts should have the proper names. The idea of this hackery is that
in the .dts we can have the proper compatible string. So in the .dts, we
have, say:
"sony,panel-foobar"
Then, at boot time, omap's platform code changes that to:
"omapdss,sony,panel-foobar".
And our (omap specific) panel-foobar driver use that
"omapdss,sony,panel-foobar" string.
This way some other platform could do the same, and have their platform
specific drivers handle the panel.
At some point in the future we hopefully will have common panel drivers,
and at that point we can remove that hackery. The .dts files will
already be correct.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v4] video: mx3fb: Add backlight control support
From: Alexander Stein @ 2014-05-12 6:34 UTC (permalink / raw)
To: linux-fbdev
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 v4:
* Add backlight support unconditionally
Changes in v3:
* Add a more descriptive commit message
Changes in v2:
* rebased to v3.15-rc4
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/mx3fb.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e1f4727..d76b4af 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2332,6 +2332,7 @@ config FB_MX3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select BACKLIGHT_CLASS_DEVICE
default y
help
This is a framebuffer device for the i.MX31 LCD Controller. So
diff --git a/drivers/video/fbdev/mx3fb.c b/drivers/video/fbdev/mx3fb.c
index 142e860..315e285 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>
@@ -241,6 +242,7 @@ struct mx3fb_data {
void __iomem *reg_base;
spinlock_t lock;
struct device *dev;
+ struct backlight_device *bl;
uint32_t h_start_width;
uint32_t v_start_width;
@@ -271,6 +273,71 @@ struct mx3fb_info {
struct fb_var_screeninfo cur_var; /* current var info */
};
+static void sdc_set_brightness(struct mx3fb_data *mx3fb, uint8_t value);
+static u32 sdc_get_brightness(struct mx3fb_data *mx3fb);
+
+static int mx3fb_bl_get_brightness(struct backlight_device *bl)
+{
+ struct mx3fb_data *fbd = bl_get_data(bl);
+
+ return sdc_get_brightness(fbd);
+}
+
+static int mx3fb_bl_update_status(struct backlight_device *bl)
+{
+ struct mx3fb_data *fbd = bl_get_data(bl);
+ int brightness = bl->props.brightness;
+
+ if (bl->props.power != FB_BLANK_UNBLANK)
+ brightness = 0;
+ if (bl->props.fb_blank != FB_BLANK_UNBLANK)
+ brightness = 0;
+
+ fbd->backlight_level = (fbd->backlight_level & ~0xFF) | brightness;
+
+ sdc_set_brightness(fbd, fbd->backlight_level);
+
+ return 0;
+}
+
+static const struct backlight_ops mx3fb_lcdc_bl_ops = {
+ .update_status = mx3fb_bl_update_status,
+ .get_brightness = mx3fb_bl_get_brightness,
+};
+
+static void mx3fb_init_backlight(struct mx3fb_data *fbd)
+{
+ struct backlight_properties props;
+ struct backlight_device *bl;
+
+ if (fbd->bl)
+ return;
+
+ memset(&props, 0, sizeof(struct backlight_properties));
+ props.max_brightness = 0xff;
+ props.type = BACKLIGHT_RAW;
+ sdc_set_brightness(fbd, fbd->backlight_level);
+
+ bl = backlight_device_register("mx3fb-bl", fbd->dev, fbd,
+ &mx3fb_lcdc_bl_ops, &props);
+ if (IS_ERR(bl)) {
+ dev_err(fbd->dev, "error %ld on backlight register\n",
+ PTR_ERR(bl));
+ return;
+ }
+
+ fbd->bl = bl;
+ bl->props.power = FB_BLANK_UNBLANK;
+ bl->props.fb_blank = FB_BLANK_UNBLANK;
+ bl->props.brightness = mx3fb_bl_get_brightness(bl);
+}
+
+static void mx3fb_exit_backlight(struct mx3fb_data *fbd)
+{
+ if (fbd->bl)
+ backlight_device_unregister(fbd->bl);
+}
+
static void mx3fb_dma_done(void *);
/* Used fb-mode and bpp. Can be set on kernel command line, therefore file-static. */
@@ -628,6 +695,16 @@ static int sdc_set_global_alpha(struct mx3fb_data *mx3fb, bool enable, uint8_t a
return 0;
}
+static u32 sdc_get_brightness(struct mx3fb_data *mx3fb)
+{
+ u32 brightness;
+
+ brightness = mx3fb_read_reg(mx3fb, SDC_PWM_CTRL);
+ brightness = (brightness >> 16) & 0xFF;
+
+ return brightness;
+}
+
static void sdc_set_brightness(struct mx3fb_data *mx3fb, uint8_t value)
{
dev_dbg(mx3fb->dev, "%s: value = %d\n", __func__, value);
@@ -1534,6 +1611,8 @@ static int mx3fb_probe(struct platform_device *pdev)
if (ret < 0)
goto eisdc0;
+ mx3fb_init_backlight(mx3fb);
+
return 0;
eisdc0:
@@ -1557,6 +1636,8 @@ static int mx3fb_remove(struct platform_device *dev)
chan = &mx3_fbi->idmac_channel->dma_chan;
release_fbi(fbi);
+ mx3fb_exit_backlight(mx3fb);
+
dma_release_channel(chan);
dmaengine_put();
--
1.8.5.5
^ permalink raw reply related
* Re: [PATCH 5/5] Doc/DT: hdmi-connector: add HPD GPIO documentation
From: Tomi Valkeinen @ 2014-05-12 6:30 UTC (permalink / raw)
To: Archit Taneja, linux-fbdev, linux-omap; +Cc: devicetree
In-Reply-To: <53705DC8.1050903@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
On 12/05/14 08:36, Archit Taneja wrote:
> Hi,
>
> On Friday 09 May 2014 06:02 PM, Tomi Valkeinen wrote:
>> 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
>
> Would there ever be more than one HPD gpio?
No. HDMI spec specifies that there is one HPD pin in the connector.
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: Alexander Stein @ 2014-05-12 6:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1399559916-15183-1-git-send-email-alexander.stein@systec-electronic.com>
On Friday 09 May 2014 12:11:29, Tomi Valkeinen wrote:
> 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?
Well, sure I can. I just went the same way as atmel_lcdfb.c did. Will sent new patch.
Regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.stein@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
^ permalink raw reply
* Re: [PATCH 5/5] Doc/DT: hdmi-connector: add HPD GPIO documentation
From: Archit Taneja @ 2014-05-12 5:48 UTC (permalink / raw)
To: Tomi Valkeinen, linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1399638727-23254-5-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Hi,
On Friday 09 May 2014 06:02 PM, Tomi Valkeinen wrote:
> 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
Would there ever be more than one HPD gpio?
Archit
^ permalink raw reply
* Re: [PATCH] video: omap: delete support for early fbmem allocation
From: Tony Lindgren @ 2014-05-11 15:02 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, linux-kernel,
Peter Griffin, Arnd Bergmann, Jean-Christophe Plagniol-Villard,
Janusz Krzysztofik
In-Reply-To: <1399675964-22917-1-git-send-email-aaro.koskinen@iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [140509 15:47]:
> 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>
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> 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
* Re: [PATCH 13/13] video: omap: allow building on !MMU
From: Tony Lindgren @ 2014-05-11 15:01 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Tomi Valkeinen, Peter Griffin, Arnd Bergmann, linux-kernel,
linaro-kernel, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-omap, Janusz Krzysztofik
In-Reply-To: <20140509212112.GB6670@drone.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [140509 14:26]:
> 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.
OK maybe it's just a question of loading the backlight modules.
> > > > > 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.
OK thanks that makes sense to me.
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-11 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALbNGRR3U1veFgXmOWpfG3yNVESdxi2t79WDrJwOZ1oShuG1yA@mail.gmail.com>
* Andreas Müller <schnitzeltony@googlemail.com> [140509 14:07]:
> 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
Sorry I'm a bit confused now. Is the reboot issue a separate issue
related to the twl4030 generic scripts for 3530?
And then this patch fixes dm3730 wake-up (from suspend?) issues?
Or do we have some other bug where we wrongly hit omap3630_dss_feats
on 3530 somehow?
Regards,
Tony
> [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
* [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
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