* [PATCH 13/19] ARM: omap4.dtsi: Add audio related parametes to hdmi node
From: Jyri Sarha @ 2014-05-12 9:12 UTC (permalink / raw)
To: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: peter.ujfalusi-l0cyMroinI0, broonie-DgEjT+Ai2ygdnm+yROfE0A,
liam.r.girdwood-VuQAYsv1563Yd54FQh9/CA,
bcousson-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
detheridge-l0cyMroinI0, Jyri Sarha
In-Reply-To: <cover.1399884780.git.jsarha-l0cyMroinI0@public.gmane.org>
Adds HDMI audio sDMA properties.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 27fcac8..c7f0913 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -919,6 +919,8 @@
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
+ dmas = <&sdma 76>;
+ dma-names = "audio_tx";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
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
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Adds a simple-card sound node for HDMI audio, the associated
hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d2c45bf..c04f453 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -41,7 +41,7 @@
};
};
- sound: sound {
+ sound: sound@0 {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
@@ -65,6 +65,24 @@
"AFMR", "Line In";
};
+ sound@1 {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,cpu {
+ sound-dai = <&hdmi>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&hdmi_audio>;
+ };
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,hdmi-audio";
+ status = "okay";
+ };
+
/* HS USB Port 1 Power */
hsusb1_power: hsusb1_power_reg {
compatible = "regulator-fixed";
@@ -512,6 +530,7 @@
};
&hdmi {
+ #sound-dai-cells = <0>;
status = "ok";
vdda-supply = <&vdac>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 15/19] ARM: omap5.dtsi: Add audio related parameters to hdmi node
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
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Adds HDMI audio sDMA properties.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b2a28e6..bac7d8e 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -931,6 +931,8 @@
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
+ dmas = <&sdma 76>;
+ dma-names = "audio_tx";
};
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 16/19] ARM: omap5-uevm.dts: Add hdmi audio related nodes
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
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
Adds a simple-card sound node for HDMI audio, the associated
hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/boot/dts/omap5-uevm.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index f625a87..42d625b 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -561,6 +561,24 @@
};
};
};
+
+ sound@0 {
+ compatible = "simple-audio-card";
+
+ simple-audio-card,cpu {
+ sound-dai = <&hdmi>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&hdmi_audio>;
+ };
+ };
+
+ hdmi_audio: hdmi_audio@0 {
+ #sound-dai-cells = <0>;
+ compatible = "linux,hdmi-audio";
+ status = "okay";
+ };
};
&dss {
@@ -568,6 +586,7 @@
};
&hdmi {
+ #sound-dai-cells = <0>;
status = "ok";
vdda-supply = <&ldo4_reg>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 17/19] ARM: omap2plus_defconfig: Build DSS HDMI support for OMAP4 in kernel
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
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
This patch is here only as an example on how to enable HDMI video for
Panda board. In addition to this patch omapdss.def_disp=hdmi parameter
should be added to kernel command line in order to enable HDMI video.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index a966795..35c42aa 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -187,14 +187,14 @@ CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
-CONFIG_OMAP2_DSS=m
+CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
-CONFIG_FB_OMAP2=m
+CONFIG_FB_OMAP2=y
CONFIG_DISPLAY_ENCODER_TFP410=m
CONFIG_DISPLAY_ENCODER_TPD12S015=m
-CONFIG_DISPLAY_CONNECTOR_DVI=m
-CONFIG_DISPLAY_CONNECTOR_HDMI=m
+CONFIG_DISPLAY_CONNECTOR_DVI=y
+CONFIG_DISPLAY_CONNECTOR_HDMI=y
CONFIG_DISPLAY_PANEL_DPI=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 18/19] ARM: omap2plus_defconfig: Enable OMAP5 HDMI 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
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
This patch is here only as an example on how to enable HDMI video for
OMAP5 uEVM. Adds CONFIG_GPIO_PCA953X=y and CONFIG_OMAP5_DSS_HDMI=y.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 35c42aa..363733e 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -157,6 +157,7 @@ CONFIG_PINCTRL_SINGLE=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_TWL4030=y
+CONFIG_GPIO_PCA953X=y
CONFIG_W1=y
CONFIG_POWER_SUPPLY=y
CONFIG_SENSORS_LM75=m
@@ -190,6 +191,7 @@ CONFIG_FB_TILEBLITTING=y
CONFIG_OMAP2_DSS=y
CONFIG_OMAP2_DSS_SDI=y
CONFIG_OMAP2_DSS_DSI=y
+CONFIG_OMAP5_DSS_HDMI=y
CONFIG_FB_OMAP2=y
CONFIG_DISPLAY_ENCODER_TFP410=m
CONFIG_DISPLAY_ENCODER_TPD12S015=m
--
1.7.9.5
^ permalink raw reply related
* [PATCH 19/19] ARM: omap2plus_defconfig: Enable 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
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
This patch is here only as an example on how to enable HDMI audio for
OMAP4+ HW. Adds CONFIG_SND_SIMPLE_CARD=m and CONFIG_SND_SOC_HDMI_CODEC=m.
Also builds SND_OMAP_SOC in kernel to support in kernel built OMAPDSS
with integrated HDMI DAI driver.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 363733e..8b512c7 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -204,20 +204,22 @@ CONFIG_LCD_PLATFORM=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
CONFIG_LOGO=y
-CONFIG_SOUND=m
-CONFIG_SND=m
+CONFIG_SOUND=y
+CONFIG_SND=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_SND_USB_AUDIO=m
-CONFIG_SND_SOC=m
-CONFIG_SND_OMAP_SOC=m
+CONFIG_SND_SOC=y
+CONFIG_SND_OMAP_SOC=y
CONFIG_SND_AM33XX_SOC_EVM=m
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m
CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
+CONFIG_SND_SIMPLE_CARD=m
+CONFIG_SND_SOC_HDMI_CODEC=m
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Javier Martinez Canillas @ 2014-05-12 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53707A64.2060203@ti.com>
Hello Tomi,
On Mon, May 12, 2014 at 9:38 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> 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.
>
Maybe we can remove this hackery by relying on the fact that a
compatible string can have a set of values that goes from more
specific to more general. So you can have something like:
compatible = "sony,panel-foobar", "omapdss,panel-foobar"
So right now only "omapdss,panel-foobar" will be matched and later
when we have common panel drivers then that driver could handle the
"sony,panel-foobar" compatible string.
Other platforms could do something similar and have
compatible = "sony,panel-foobar", "baz,panel-foobar"
That way you won't break DT backward compatible but still not require
hacks on arch/arm/mach-omap2/display.c.
We do the same for OMAP boards, we now have the following compatible string:
compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
There isn't a struct machine_desc that matches "isee,omap3-igep0020"
but later if we find that we need some board specific initialization
we could add one without breaking existing DTS. In fact it used to be
a single machine_desc that matched "ti,omap3" for both omap36xx and
omap34xx but later when some DT clocks changes were introduced we
needed to split both SoC families.
> Tomi
>
>
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-12 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=kwhodeFTHoVpn1nHeh9+kV5fwMN9s3Kbk6h7_xJp4UYA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On 12/05/14 12:34, Javier Martinez Canillas wrote:
> Maybe we can remove this hackery by relying on the fact that a
> compatible string can have a set of values that goes from more
> specific to more general. So you can have something like:
>
> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
>
> So right now only "omapdss,panel-foobar" will be matched and later
> when we have common panel drivers then that driver could handle the
> "sony,panel-foobar" compatible string.
>
> Other platforms could do something similar and have
>
> compatible = "sony,panel-foobar", "baz,panel-foobar"
>
> That way you won't break DT backward compatible but still not require
> hacks on arch/arm/mach-omap2/display.c.
>
> We do the same for OMAP boards, we now have the following compatible string:
>
> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>
> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
> but later if we find that we need some board specific initialization
> we could add one without breaking existing DTS. In fact it used to be
> a single machine_desc that matched "ti,omap3" for both omap36xx and
> omap34xx but later when some DT clocks changes were introduced we
> needed to split both SoC families.
I think that's a different thing. "isee,omap3-igep0020" is a proper
compatible string, if the board is "isee,...". No matter what software
you run, that's correct and fine.
The omapdss case is different, there the "omapdss" points to a sw thing,
it does not describe the hardware. It's only needed as we don't have
proper sw drivers for the devices.
That said, I think what you describe would work. But I would rather keep
the .dts files clean and correct, and keep that hacks hidden inside the
kernel.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Javier Martinez Canillas @ 2014-05-12 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53709706.10501@ti.com>
Hello Tomi,
On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 12/05/14 12:34, Javier Martinez Canillas wrote:
>
>> Maybe we can remove this hackery by relying on the fact that a
>> compatible string can have a set of values that goes from more
>> specific to more general. So you can have something like:
>>
>> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
>>
>> So right now only "omapdss,panel-foobar" will be matched and later
>> when we have common panel drivers then that driver could handle the
>> "sony,panel-foobar" compatible string.
>>
>> Other platforms could do something similar and have
>>
>> compatible = "sony,panel-foobar", "baz,panel-foobar"
>>
>> That way you won't break DT backward compatible but still not require
>> hacks on arch/arm/mach-omap2/display.c.
>>
>> We do the same for OMAP boards, we now have the following compatible string:
>>
>> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
>>
>> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
>> but later if we find that we need some board specific initialization
>> we could add one without breaking existing DTS. In fact it used to be
>> a single machine_desc that matched "ti,omap3" for both omap36xx and
>> omap34xx but later when some DT clocks changes were introduced we
>> needed to split both SoC families.
>
> I think that's a different thing. "isee,omap3-igep0020" is a proper
> compatible string, if the board is "isee,...". No matter what software
> you run, that's correct and fine.
>
> The omapdss case is different, there the "omapdss" points to a sw thing,
> it does not describe the hardware. It's only needed as we don't have
> proper sw drivers for the devices.
>
> That said, I think what you describe would work. But I would rather keep
> the .dts files clean and correct, and keep that hacks hidden inside the
> kernel.
>
Thanks for the explanation. Since DT are meant to describe hardware
and not software I agree with you that we shouldn't leak an
implementation detail to the DeviceTrees.
And after all fortunately we don't have a stable API in the kernel
like the one that is enforced in the DT so we can fix it later ;-)
> Tomi
>
>
Bets regards,
Javier
^ permalink raw reply
* Re: [PATCH] uvesafb: abort initialization if video=uvesafb is not set
From: David Herrmann @ 2014-05-12 10:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1396791873-22606-1-git-send-email-lxnay@sabayon.org>
Hi
On Sun, Apr 6, 2014 at 3:44 PM, <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.
Why would you want vesafb _and_ uvesafb built-in? Ship them as modules
and let users blacklist the modules they don't want. I mean the
problem you describe is specific to distros. Embedded devices or other
specific use-cases can explicitly disable any unwanted module. And for
distros I cannot see why we should support both as built-in modules.
_Iff_ you want this as in-kernel option, I'd recommend looking at the
sysfb stuff. uvesafb could easily claim the vesa-framebuffer and thus
unload any generic drivers like vesafb.
Thanks
David
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-12 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509143703.GA17814@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]
On 09/05/14 17:37, Tony Lindgren wrote:
> * 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.
Hmm, well, those both look fine. The fck is well below the maximum,
which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
with this patch, but that should affect the GFX overlay.
So you're just booting, and there are no applications that use the
framebuffer? And there is no rotation or such configured?
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-12 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140509143748.GB17814@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
On 09/05/14 17:37, Tony Lindgren wrote:
> * 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.
I mean the debugs for clock framework. The above warning means that the
clock framework says the clock rate is X, but the dss had calculated
that it should be Y. So there's a difference how the clock framework
calculates the rate and how the dss calculates it.
And yes, dss shouldn't calculate it. But I don't know how to get good
pixel clocks if we didn't.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-12 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABxcv=mY0a+yJgmCTPN=BhSQD57Pw022zOd5_KxEgvvF_-=O7Q@mail.gmail.com>
* Javier Martinez Canillas <javier@dowhile0.org> [140512 03:01]:
> Hello Tomi,
>
> On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 12/05/14 12:34, Javier Martinez Canillas wrote:
> >
> >> Maybe we can remove this hackery by relying on the fact that a
> >> compatible string can have a set of values that goes from more
> >> specific to more general. So you can have something like:
> >>
> >> compatible = "sony,panel-foobar", "omapdss,panel-foobar"
> >>
> >> So right now only "omapdss,panel-foobar" will be matched and later
> >> when we have common panel drivers then that driver could handle the
> >> "sony,panel-foobar" compatible string.
> >>
> >> Other platforms could do something similar and have
> >>
> >> compatible = "sony,panel-foobar", "baz,panel-foobar"
> >>
> >> That way you won't break DT backward compatible but still not require
> >> hacks on arch/arm/mach-omap2/display.c.
> >>
> >> We do the same for OMAP boards, we now have the following compatible string:
> >>
> >> compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
> >>
> >> There isn't a struct machine_desc that matches "isee,omap3-igep0020"
> >> but later if we find that we need some board specific initialization
> >> we could add one without breaking existing DTS. In fact it used to be
> >> a single machine_desc that matched "ti,omap3" for both omap36xx and
> >> omap34xx but later when some DT clocks changes were introduced we
> >> needed to split both SoC families.
> >
> > I think that's a different thing. "isee,omap3-igep0020" is a proper
> > compatible string, if the board is "isee,...". No matter what software
> > you run, that's correct and fine.
> >
> > The omapdss case is different, there the "omapdss" points to a sw thing,
> > it does not describe the hardware. It's only needed as we don't have
> > proper sw drivers for the devices.
> >
> > That said, I think what you describe would work. But I would rather keep
> > the .dts files clean and correct, and keep that hacks hidden inside the
> > kernel.
> >
>
> Thanks for the explanation. Since DT are meant to describe hardware
> and not software I agree with you that we shouldn't leak an
> implementation detail to the DeviceTrees.
>
> And after all fortunately we don't have a stable API in the kernel
> like the one that is enforced in the DT so we can fix it later ;-)
This remapping of compatible flags sounds smelly to me, please discuss
it first with the device tree people.
I think we're better off just using the compatible properties limited
to the simple-panel.txt for now and actually describe the real
hardware. The fact that the panel is connected to DSS should be possible
to find out based on the phandles.
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-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370B222.7050702@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
> On 09/05/14 17:37, Tony Lindgren wrote:
> >
> > This is just the 3730-evm with the Sharp VGA panel mentioned in
> > this series.
>
> Hmm, well, those both look fine. The fck is well below the maximum,
> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
> with this patch, but that should affect the GFX overlay.
>
> So you're just booting, and there are no applications that use the
> framebuffer? And there is no rotation or such configured?
Right. The rotation is set to 3 though.
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tony Lindgren @ 2014-05-12 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALbNGRQpieZ+b-PvC+K2Zxb3hOd6KOCrPVOnveds-fXENn8GJg@mail.gmail.com>
* Andreas Müller <schnitzeltony@googlemail.com> [140512 01:20]:
> 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.
Yeah 35xx should be treated as 34xx so sounds like there might be
some detection problem if this patch does something for your board.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
From: Tomi Valkeinen @ 2014-05-12 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140512143934.GC31772@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On 12/05/14 17:39, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 04:36]:
>> On 09/05/14 17:37, Tony Lindgren wrote:
>>>
>>> This is just the 3730-evm with the Sharp VGA panel mentioned in
>>> this series.
>>
>> Hmm, well, those both look fine. The fck is well below the maximum,
>> which is somewhere around 170MHz-180MHz. The lck/pck ratio is higher
>> with this patch, but that should affect the GFX overlay.
>>
>> So you're just booting, and there are no applications that use the
>> framebuffer? And there is no rotation or such configured?
>
> Right. The rotation is set to 3 though.
Hmm, that's probably the issue then. VRFB rotation is very heavy on the
memory bandwidth, and is generally a very easy way to get sync lost errors.
My opinion is that VRFB should only be used when you know your system
will handle it fine with the clock rates and bandwidth usage you have
for your use cases.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tomi Valkeinen @ 2014-05-12 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140512142646.GA31772@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
On 12/05/14 17:26, Tony Lindgren wrote:
>>> The omapdss case is different, there the "omapdss" points to a sw thing,
>>> it does not describe the hardware. It's only needed as we don't have
>>> proper sw drivers for the devices.
>>>
>>> That said, I think what you describe would work. But I would rather keep
>>> the .dts files clean and correct, and keep that hacks hidden inside the
>>> kernel.
>>>
>>
>> Thanks for the explanation. Since DT are meant to describe hardware
>> and not software I agree with you that we shouldn't leak an
>> implementation detail to the DeviceTrees.
>>
>> And after all fortunately we don't have a stable API in the kernel
>> like the one that is enforced in the DT so we can fix it later ;-)
>
> This remapping of compatible flags sounds smelly to me, please discuss
> it first with the device tree people.
It's already in v3.15.
I agree it's smelly, but it smelly only inside the kernel, not visible
anywhere, and we can remove it when we have common panel drivers,
without any modifications to .dts files.
> I think we're better off just using the compatible properties limited
> to the simple-panel.txt for now and actually describe the real
> hardware. The fact that the panel is connected to DSS should be possible
> to find out based on the phandles.
I'm not sure what you mean. We do describe only the real hardware. The
compatible string in the .dts file is "sharp,ls037v7dw01".
Prepending the "omapdss" to the compatible string is required for the
device/driver matching to work, because we can't use the
"sharp,ls037v7dw01" compatible string in our omap specific panel driver.
I'm not sure what it would give us to try to be compatible with
simple-panel.txt. The simple-panel bindings won't probably be compatible
with the future common display drivers in any case, as the simple-panel
binding is just too limited and doesn't describe the hardware fully.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv2 00/11] improve PWM lookup support without device tree
From: Alexandre Belloni @ 2014-05-12 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1397512793-10325-1-git-send-email-alexandre.belloni@free-electrons.com>
Hello Thierry,
Do you know when you will have some time to review that patch series ?
On 14/04/2014 at 23:59:42 +0200, Alexandre Belloni wrote :
> Hi,
>
> A patch set as suggested by Thierry to make lookup with the lookup table
> instead of device tree behave more like when using device tree.
>
> The first patch adds a period and a polarity member to the lookup table and use
> those to set period and polarity.
>
> Patch 2, 4 and 5 are making use of those new members from the board files.
> Patch 3 removes useless code since setting the polarity is now handled by the
> PWM core.
>
> I couldn't decide on a good name for the extended PWM_LOOKUP macro and I believe
> we won't have to add members to that structure soon so:
> Patch 6 modifies the PWM_LOOKUP macro to also initialize period and polarity
> and
> Patch 7-9 are making use of the new PWM_LOOKUP macro in the board files
>
> Patch 10 and 11 are making the leds-pwm and pwm_bl drivers get the period from
> the PWM before using pwm_period_ns if it is not already set.
>
> Patch 10 will obviously conflict with the series of Russell reworking the
> leds-pwm probing. I can rebase if necessary
>
> The final goal would be to get rid of .pwm_period_ns in leds-pwm and pwm_bl
> after moving all the remaining users (still around 25) to pwm_lookup.
>
> Changes in v2:
> - correctly unlock the pwm_lookup_lock mutex before returning.
> - don't change PWM_LOOKUP atomically
> - remove tpu_pwm_platform_data and the associated header file
> - make the leds-pwm and pwm_bl drivers get the period from the PWM
>
> Alexandre Belloni (11):
> pwm: add period and polarity to struct pwm_lookup
> ARM: shmobile: Armadillo 800 EVA: initialize all struct pwm_lookup
> members
> pwm: renesas-tpu: remove useless struct tpu_pwm_platform_data
> ARM: OMAP3: Beagle: initialize all the struct pwm_lookup members
> ARM: pxa: hx4700: initialize all the struct pwm_lookup members
> pwm: modify PWM_LOOKUP to initialize all struct pwm_lookup members
> ARM: OMAP3: Beagle: use PWM_LOOKUP to initialize struct pwm_lookup
> ARM: shmobile: Armadillo 800 EVA: use PWM_LOOKUP to initialize struct
> pwm_lookup
> ARM: pxa: hx4700: use PWM_LOOKUP to initialize struct pwm_lookup
> leds: leds-pwm: retrieve configured pwm period
> backlight: pwm_bl: retrieve configured pwm period
>
> Documentation/pwm.txt | 3 ++-
> arch/arm/mach-omap2/board-omap3beagle.c | 3 ++-
> arch/arm/mach-pxa/hx4700.c | 3 ++-
> arch/arm/mach-shmobile/board-armadillo800eva.c | 14 +++-----------
> drivers/leds/leds-pwm.c | 5 ++++-
> drivers/pwm/core.c | 8 +++++++-
> drivers/pwm/pwm-renesas-tpu.c | 19 +++----------------
> drivers/video/backlight/pwm_bl.c | 8 +++++---
> include/linux/platform_data/pwm-renesas-tpu.h | 16 ----------------
> include/linux/pwm.h | 6 +++++-
> 10 files changed, 33 insertions(+), 52 deletions(-)
> delete mode 100644 include/linux/platform_data/pwm-renesas-tpu.h
>
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Tony Lindgren @ 2014-05-12 15:06 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, peter.ujfalusi,
broonie, liam.r.girdwood, bcousson, tomi.valkeinen, detheridge
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
* Jyri Sarha <jsarha@ti.com> [140512 02:13]:
> 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.
Can you guys please post this split into the following separate
parts for the maintainers to merge:
- ASoC changes
- DSS changes
- DTS changes
And once those are all in, please post the defconfig changes.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-12 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370E0C9.8050201@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140512 07:55]:
> On 12/05/14 17:26, Tony Lindgren wrote:
>
> >>> The omapdss case is different, there the "omapdss" points to a sw thing,
> >>> it does not describe the hardware. It's only needed as we don't have
> >>> proper sw drivers for the devices.
> >>>
> >>> That said, I think what you describe would work. But I would rather keep
> >>> the .dts files clean and correct, and keep that hacks hidden inside the
> >>> kernel.
> >>>
> >>
> >> Thanks for the explanation. Since DT are meant to describe hardware
> >> and not software I agree with you that we shouldn't leak an
> >> implementation detail to the DeviceTrees.
> >>
> >> And after all fortunately we don't have a stable API in the kernel
> >> like the one that is enforced in the DT so we can fix it later ;-)
> >
> > This remapping of compatible flags sounds smelly to me, please discuss
> > it first with the device tree people.
>
> It's already in v3.15.
Oh great.. And you dumped it into arch/arm/mach-omap2 too and I somehow
even acked it :( Looks like there's also the custom mux hacks. And
custom hwmod hacks. And ongoing soc_is_xxx tinkering. Now let's not add
_any_ new crap into arch/arm/mach-omap2/display.c.
So please consider this a huge eternal NAK to add any more crap to
arch/arm/mach-omap2/display.c from me. No more new soc_is beyond
the soc_is_am43xx() you have in linux next. No more adding
of_find_compatible_node() beyond ti,omap5-dss you have in linux next.
And no more new panel remapping in this file as soon as you have found
a better solution. Preferrably by v3.17 merge window. This file just
needs to disappear. Yuk.
> I agree it's smelly, but it smelly only inside the kernel, not visible
> anywhere, and we can remove it when we have common panel drivers,
> without any modifications to .dts files.
>
> > I think we're better off just using the compatible properties limited
> > to the simple-panel.txt for now and actually describe the real
> > hardware. The fact that the panel is connected to DSS should be possible
> > to find out based on the phandles.
>
> I'm not sure what you mean. We do describe only the real hardware. The
> compatible string in the .dts file is "sharp,ls037v7dw01".
>
> Prepending the "omapdss" to the compatible string is required for the
> device/driver matching to work, because we can't use the
> "sharp,ls037v7dw01" compatible string in our omap specific panel driver.
>
> I'm not sure what it would give us to try to be compatible with
> simple-panel.txt. The simple-panel bindings won't probably be compatible
> with the future common display drivers in any case, as the simple-panel
> binding is just too limited and doesn't describe the hardware fully.
Hmm what else does a panel need where the existing binding cannot be
extended?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 11/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
From: Mark Brown @ 2014-05-12 17:22 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, peter.ujfalusi,
liam.r.girdwood, bcousson, tomi.valkeinen, detheridge
In-Reply-To: <df664d05d8208f5789623604a4e0f5342bc6e405.1399884780.git.jsarha@ti.com>
[-- Attachment #1: Type: text/plain, Size: 353 bytes --]
On Mon, May 12, 2014 at 12:12:22PM +0300, Jyri Sarha wrote:
> Removes omap-hdmi DAI driver, omap-hdmi-card driver, the related
> Kconfig options, and Makefile entries. The HDMI DAI drivers has been
> integrated directly to OMAP4+ HDMI drivers and simple-card driver is
> used instead of omap-hdmi-card driver.
Acked-by: Mark Brown <broonie@linaro.org>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Joachim Eastwood @ 2014-05-12 21:13 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <cover.1399884780.git.jsarha@ti.com>
On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
> 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
hey, this worked straight away :)
But there seems to be something wrong with the channel mapping.
For stereo (speaker-test -c 2) the mapping is correct.
But for -c 4 and -c 8 it gets weird:
speaker-test -c 4 -s X # where X is 1-4
1: Front Left is Rear Left
2: Front Right is Rear Right
3: Rear Right is Front Right
4: Rear Left is Front Left
speaker-test -c 8 -s X # where X is 1-8
1: Front Left is Rear Left
2: Center is Rear Left
3: Front Right is Rear Right
4: Side Right is Front Right
5: Rear Right is silent
6: Rear Left is Center
7: Side Left is Front Left
8: LFE - Rear Right
I think you need to check what channel order ALSA expects. I believe
speaker-test does the right thing on my HTPC normally connected to my
receiver.
Note: I am not 100% sure about the -c 8 results. I might have to do
the test again.
Tested on VAR-DVK-OM44 (OMAP4460) with Yamaha RX-A1030 Surround receiver.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
From: Jingoo Han @ 2014-05-13 1:36 UTC (permalink / raw)
To: 'Lee Jones'
Cc: 'Tony Lindgren', linux-kernel, linux-fbdev, linux-omap,
'Bryan Wu', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', 'Linus Walleij',
'Alexandre Courbot', 'Russell King',
'Jingoo Han'
In-Reply-To: <20140509012454.GL2198@atomide.com>
On Friday, May 09, 2014 10:25 AM, Tony Lindgren wrote:
>
> If the GPIO for the backlight is on an I2C chip, we currently
> get nasty warnings like this during the boot:
>
> WARNING: CPU: 0 PID: 6 at drivers/gpio/gpiolib.c:2364 gpiod_set_raw_value+0x40/0x4c()
> Modules linked in:
> CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.15.0-rc4-12393-gcde9f4e #400
> Workqueue: deferwq deferred_probe_work_func
> [<c0014cbc>] (unwind_backtrace) from [<c001191c>] (show_stack+0x10/0x14)
> [<c001191c>] (show_stack) from [<c0566ae0>] (dump_stack+0x80/0x9c)
> [<c0566ae0>] (dump_stack) from [<c003f61c>] (warn_slowpath_common+0x68/0x8c)
> [<c003f61c>] (warn_slowpath_common) from [<c003f65c>] (warn_slowpath_null+0x1c/0x24)
> [<c003f65c>] (warn_slowpath_null) from [<c02f7e10>] (gpiod_set_raw_value+0x40/0x4c)
> [<c02f7e10>] (gpiod_set_raw_value) from [<c0308fbc>] (gpio_backlight_update_status+0x4c/0x74)
> [<c0308fbc>] (gpio_backlight_update_status) from [<c030914c>] (gpio_backlight_probe+0x168/0x254)
> [<c030914c>] (gpio_backlight_probe) from [<c0378fa8>] (platform_drv_probe+0x18/0x48)
> [<c0378fa8>] (platform_drv_probe) from [<c0377c40>] (driver_probe_device+0x10c/0x238)
> [<c0377c40>] (driver_probe_device) from [<c0376330>] (bus_for_each_drv+0x44/0x8c)
> [<c0376330>] (bus_for_each_drv) from [<c0377afc>] (device_attach+0x74/0x8c)
> [<c0377afc>] (device_attach) from [<c03771c4>] (bus_probe_device+0x88/0xb0)
> [<c03771c4>] (bus_probe_device) from [<c03775c8>] (deferred_probe_work_func+0x64/0x94)
> [<c03775c8>] (deferred_probe_work_func) from [<c00572e8>] (process_one_work+0x1b4/0x4bc)
> [<c00572e8>] (process_one_work) from [<c00579d0>] (worker_thread+0x11c/0x398)
> [<c00579d0>] (worker_thread) from [<c005dfd8>] (kthread+0xc8/0xe4)
> [<c005dfd8>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)
>
> Fix this by using gpio_set_value_cansleep() as suggested in
> drivers/gpio/gpiolib.c:2364. This is what the other backlight drivers
> are also doing.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
(+cc Linus Walleij, Alexandre Courbot, Russell King)
Hi Lee Jones,
Would you apply this patch into backlight git tree?
If you have other opinions, please let us know. :-)
Thank you.
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
>
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -38,7 +38,8 @@ static int gpio_backlight_update_status(struct backlight_device *bl)
> bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> brightness = 0;
>
> - gpio_set_value(gbl->gpio, brightness ? gbl->active : !gbl->active);
> + gpio_set_value_cansleep(gbl->gpio,
> + brightness ? gbl->active : !gbl->active);
>
> return 0;
> }
^ permalink raw reply
* [PATCH 0/3] minor console cleanup patches
From: Takashi Iwai @ 2014-05-13 10:09 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jiri Slaby, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev, linux-kernel
Hi,
here is a small series of cleanup patches for some annoyance I
stumbled during debugging the framebuffer issues:
[PATCH 1/3] vgacon: Fix & cleanup refcounting
[PATCH 2/3] console: Use explicit pointer type for vc_uni_pagedir*
[PATCH 3/3] console: Remove superfluous readonly check
There should be no functional changes by this.
Takashi
^ 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