Re: RCU stall on panda
On 05/13/2014 05:21 AM, Tony Lindgren wrote: > * Paul E. McKenney [140505 11:11]: >> On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: >>> I keep seeing the RCU stall problem on panda board from 3.10 kernel to >>> latest upstream kernel >>> and google find some one report it before: >>> https://lkml.org/lkml/2012/9/20/519 >>> >>> Is it the hardware issue or a real software problem? >> >> I cannot distinguish between hardware and software from the trace below, >> but given that you are also seeing a soft lockup, either way you do >> appear to have a real problem as opposed to an RCU CPU stall warning >> false positive. > > Looks like you have CPU_IDLE enabled on panda. Hangs with current linux > next with CPU_IDLE are currently being discussed on the linux-omap list > in thread "omap4-panda-es boot issues with v3.15-rc4" > > I've seen occasional system hangs, and I've also noticed that doing > ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system > producing similar errors to the below. > Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. > Regards, > > Tony > >>> 95.519653] INFO: rcu_sched self-detected stall on CPU^M >>> [ 95.519866] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M >>> [ 95.526489] INFO: rcu_sched detected stalls on CPUs/tasks:^M >>> [ 95.526489] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M >>> [ 95.526489] (detected by 0, t=4229 jiffies, g=800, c=799, q=440)^M >>> [ 95.526519] Task dump for CPU 1:^M >>> [ 95.526519] swapper/1 R running 0 0 1 0x^M >>> [ 95.559844] (t=4229 jiffies g=800 c=799 q=440)^M >>> [ 95.564727] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc4 #93^M >>> [ 95.571502] [] (unwind_backtrace) from [] >>> (show_stack+0x11/0x14)^M >>> [ 95.579711] [] (show_stack) from [] >>> (dump_stack+0x75/0x88)^M >>> [ 95.587371] [] (dump_stack) from [] >>> (rcu_check_callbacks+0x353/0x79c)^M >>> [ 95.596038] [] (rcu_check_callbacks) from [] >>> (update_process_times+0x33/0x4c)^M >>> [ 95.605438] [] (update_process_times) from [] >>> (tick_sched_handle.isra.18+0x1f/0x48)^M >>> [ 95.615386] [] (tick_sched_handle.isra.18) from [] >>> (tick_sched_timer+0x3d/0x5c)^M >>> [ 95.624969] [] (tick_sched_timer) from [] >>> (__run_hrtimer+0x67/0x310)^M >>> [ 95.633544] [] (__run_hrtimer) from [] >>> (hrtimer_interrupt+0xe1/0x214)^M >>> [ 95.642211] [] (hrtimer_interrupt) from [] >>> (tick_receive_broadcast+0x1f/0x30)^M >>> [ 95.651611] [] (tick_receive_broadcast) from [] >>> (handle_IPI+0xb3/0x120)^M >>> [ 95.660461] [] (handle_IPI) from [] >>> (gic_handle_irq+0x51/0x54)^M >>> [ 95.668487] [] (gic_handle_irq) from [] >>> (__irq_svc+0x3f/0x64)^M >>> [ 95.676391] Exception stack(0xee0dbf10 to 0xee0dbf58)^M >>> [ 95.681762] bf00: 0001 0001 >>> ee0d8c40^M >>> [ 95.690429] bf20: 3c6bd296 0016 3c6f8c43 0016 eefab540 c08e0c84 >>> c0fc7114^M >>> [ 95.699066] bf40: 0010 ee0dbf58 c006ef4d c0443890 4033 ^M >>> [ 95.706085] [] (__irq_svc) from [] >>> (cpuidle_enter_state+0xc0/0xc4)^M >>> [ 95.714477] [] (cpuidle_enter_state) from [] >>> (cpuidle_enter_state_coupled+0xe1/0x290)^M >>> [ 95.724639] [] (cpuidle_enter_state_coupled) from [] >>> (cpu_startup_entry+0x1a5/0x494)^M >>> [ 95.734680] [] (cpu_startup_entry) from [<80008685>] >>> (0x80008685)^M >>> [ 95.742095] BUG: soft lockup - CPU#1 stuck for 40s! [swapper/1:0]^M >>> [ 95.748535] Modules linked in:^M >>> [ 95.751770] irq event stamp: 128730^M >>> [ 95.755462] hardirqs last enabled at (128727): [] >>> cpuidle_enter_state+0xbf/0xc4^M >>> [ 95.764221] hardirqs last disabled at (128728): [] >>> __irq_svc+0x33/0x64^M >>> [ 95.772064] softirqs last enabled at (128730): [] >>> irq_enter+0x59/0x60^M >>> [ 95.779907] softirqs last disabled at (128729): [] >>> irq_enter+0x46/0x60^M >>> [ 95.787750] ^M >>> >>> >>> my RCU and IDLE related kernel config as blow: >>> >>> CONFIG_TREE_RCU=y >>> CONFIG_RCU_STALL_COMMON=y >>> CONFIG_RCU_FANOUT=32 >>> CONFIG_RCU_FANOUT_LEAF=16 >>> CONFIG_TREE_RCU_TRACE=y >>> CONFIG_PROVE_RCU=y >>> CONFIG_PROVE_RCU_REPEATEDLY=y >>> CONFIG_SPARSE_RCU_POINTER=y >>> CONFIG_RCU_CPU_STALL_TIMEOUT=21 >>> CONFIG_RCU_CPU_STALL_INFO=y >>> CONFIG_RCU_TRACE=y >>> alexs@alex-panda:~$ cat /proc/config.gz | gunzip | grep IDLE >>> CONFIG_NO_HZ_IDLE=y >>> CONFIG_GENERIC_SMP_IDLE_THREAD=y >>> CONFIG_GENERIC_IDLE_POLL_SETUP=y >>> CONFIG_CPU_IDLE=y >>> CONFIG_CPU_IDLE_GOV_LADDER=y >>> CONFIG_CPU_IDLE_GOV_MENU=y >>> CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y >>> >>> -- >>> Thanks >>> Alex >>> >> >> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
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 > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x80/0x9c) > [] (dump_stack) from [] (warn_slowpath_common+0x68/0x8c) > [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > [] (warn_slowpath_null) from [] > (gpiod_set_raw_value+0x40/0x4c) > [] (gpiod_set_raw_value) from [] > (gpio_backlight_update_status+0x4c/0x74) > [] (gpio_backlight_update_status) from [] > (gpio_backlight_probe+0x168/0x254) > [] (gpio_backlight_probe) from [] > (platform_drv_probe+0x18/0x48) > [] (platform_drv_probe) from [] > (driver_probe_device+0x10c/0x238) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x44/0x8c) > [] (bus_for_each_drv) from [] (device_attach+0x74/0x8c) > [] (device_attach) from [] (bus_probe_device+0x88/0xb0) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x94) > [] (deferred_probe_work_func) from [] > (process_one_work+0x1b4/0x4bc) > [] (process_one_work) from [] (worker_thread+0x11c/0x398) > [] (worker_thread) from [] (kthread+0xc8/0xe4) > [] (kthread) from [] (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 (+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 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; > } -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: Fix OMAP3 ISP functional clock configuration
* Laurent Pinchart [140512 16:17]: > On Thursday 08 May 2014 13:57:15 Tomi Valkeinen wrote: > > On 21/04/14 13:41, Laurent Pinchart wrote: > > > Hello, > > > > > > This patch set enables rate propagation from the OMAP3 ISP functional > > > clock to the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set > > > for the OMAP DSS functional clock from the "OMAP: OMAP3 DSS related clock > > > patches" patch series. > > > > > > Laurent Pinchart (2): > > > ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck > > > ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path > > > > > > arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +- > > > arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 --- > > > 2 files changed, 5 insertions(+), 4 deletions(-) > > > > These look fine to me. > > > > Acked-by: Tomi Valkeinen > > Thank you. > > Tony, could you please pick the patches up for v3.16 ? I'd like to see acks from Tero on these two, or Tero queue them along with other clock dts clock changes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4-panda-es boot issues with v3.15-rc4
Santosh Shilimkar writes: > On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote: >> * Kevin Hilman [140509 16:46]: >>> Roger Quadros writes: >>> >>>> Kevin, >>>> >>>> On 05/09/2014 01:15 AM, Kevin Hilman wrote: >>>>> Tony Lindgren writes: >>>>> >>>>> [...] >>>>> >>>>>> ..but I think I found the cause for recent hangs on panda, just a wild >>>>>> guess based on looking at the recent cpuidle patches after v3.14. >>>>>> >>>>>> Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts >>>>>> until all coupled CPUs leave idle) makes booting work reliably again >>>>>> on panda. >>>>>> >>>>>> Can you guys confirm, so far no issues here after few boot tests, >>>>>> but it might be too early to tell. >>>>> >>>>> Reverting that makes things a bit more stable, but it still eventually >>>>> fails in the same way. For me it took 8 boots for it to eventually >>>>> fail. >>>>> >>>>> However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable >>>>> (20+ boots in a row and still going.) >>>>> >>>> >>>> Can you please test with CPU_IDLE enabled but C3 disabled as in below >>>> patch? >>>> It worked for me 10/10 boots. >>> >>> Yup, it worked for me too for 10/10 boots in a row. >> >> But what has caused this regression, does it work reliably with let's >> say v3.13 or v3.12? >> > IIRC things were stable till some CPUIDLE code consolidation happened. > I don't recall exactly but some one did discuss about it a while back. > > Can you re-run your test-cases with patch at end of the email. This > is just a hunch so don't blame me if I waste your time testing the > patch. With your patch applied on top of next-20140512, my 4460 Panda-ES has booted 25 times in a row, and still going. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: Fix OMAP3 ISP functional clock configuration
On Thursday 08 May 2014 13:57:15 Tomi Valkeinen wrote: > On 21/04/14 13:41, Laurent Pinchart wrote: > > Hello, > > > > This patch set enables rate propagation from the OMAP3 ISP functional > > clock to the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set > > for the OMAP DSS functional clock from the "OMAP: OMAP3 DSS related clock > > patches" patch series. > > > > Laurent Pinchart (2): > > ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck > > ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path > > > > arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +- > > arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 --- > > 2 files changed, 5 insertions(+), 4 deletions(-) > > These look fine to me. > > Acked-by: Tomi Valkeinen Thank you. Tony, could you please pick the patches up for v3.16 ? -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: omap4-panda-es boot issues with v3.15-rc4
* Santosh Shilimkar [140512 14:41]:
> On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote:
> > * Kevin Hilman [140509 16:46]:
> >> Roger Quadros writes:
> >>
> >>> Kevin,
> >>>
> >>> On 05/09/2014 01:15 AM, Kevin Hilman wrote:
> Tony Lindgren writes:
>
> [...]
>
> > ..but I think I found the cause for recent hangs on panda, just a wild
> > guess based on looking at the recent cpuidle patches after v3.14.
> >
> > Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
> > until all coupled CPUs leave idle) makes booting work reliably again
> > on panda.
> >
> > Can you guys confirm, so far no issues here after few boot tests,
> > but it might be too early to tell.
>
> Reverting that makes things a bit more stable, but it still eventually
> fails in the same way. For me it took 8 boots for it to eventually
> fail.
>
> However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
> (20+ boots in a row and still going.)
>
> >>>
> >>> Can you please test with CPU_IDLE enabled but C3 disabled as in below
> >>> patch?
> >>> It worked for me 10/10 boots.
> >>
> >> Yup, it worked for me too for 10/10 boots in a row.
> >
> > But what has caused this regression, does it work reliably with let's
> > say v3.13 or v3.12?
> >
> IIRC things were stable till some CPUIDLE code consolidation happened.
> I don't recall exactly but some one did discuss about it a while back.
OK that's good to hear.
> Can you re-run your test-cases with patch at end of the email. This
> is just a hunch so don't blame me if I waste your time testing the
> patch.
Seems to work after adding "#include ". I did about 10
reboots and they all succeeded for me. Without your revert, I'm getting
a hang (with sysrq not working) about 1/3 of the boots.
Kevin, Roger, does the revert from Santosh work for you too?
BTW, I think the the RCU stall was/is a separate issue. That's different
where the system actually recovers after about a minute, or after sysrq
ctrl-a f h or l. Sorry, I no longer know if the RCU stall is only with the
older kernels around v3.10 time, or if it's still also happening.
Regards,
Tony
> From bdd30d68f8fa659aa0e3ce436f94029a7719036b Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar
> Date: Mon, 12 May 2014 17:37:59 -0400
> Subject: [PATCH] Revert "cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag"
>
> This reverts commit cb7094e848f7bcaa0a4cda3db4b232f08dbf5b78.
>
> Conflicts:
>
> arch/arm/mach-omap2/cpuidle44xx.c
> ---
> arch/arm/mach-omap2/cpuidle44xx.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index 01fc710..aae3606 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -83,6 +83,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
> *dev,
> {
> struct idle_statedata *cx = state_ptr + index;
> u32 mpuss_can_lose_context = 0;
> + int cpu_id = smp_processor_id();
>
> /*
>* CPU0 has to wait and stay ON until CPU1 is OFF state.
> @@ -110,6 +111,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
> *dev,
> mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
>(cx->mpu_logic_state == PWRDM_POWER_OFF);
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
> +
> /*
>* Call idle CPU PM enter notifier chain so that
>* VFP and per CPU interrupt context is saved.
> @@ -165,6 +168,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
> *dev,
> if (dev->cpu == 0 && mpuss_can_lose_context)
> cpu_cluster_pm_exit();
>
> + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
> +
> fail:
> cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
> cpu_done[dev->cpu] = false;
> @@ -189,8 +194,7 @@ static struct cpuidle_driver omap4_idle_driver = {
> /* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
> .exit_latency = 328 + 440,
> .target_residency = 960,
> - .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
> |
> - CPUIDLE_FLAG_TIMER_STOP,
> + .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
> .enter = omap_enter_idle_coupled,
> .name = "C2",
> .desc = "CPUx OFF, MPUSS CSWR",
> @@ -199,8 +203,7 @@ static struct cpuidle_driver omap4_idle_driver = {
> /* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
> .exit_latency = 460 + 518,
> .target_residency = 1100,
> - .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
> |
> - CPUIDLE_FLAG_TIMER_
Re: omap4-panda-es boot issues with v3.15-rc4
On Sunday 11 May 2014 11:55 AM, Tony Lindgren wrote:
> * Kevin Hilman [140509 16:46]:
>> Roger Quadros writes:
>>
>>> Kevin,
>>>
>>> On 05/09/2014 01:15 AM, Kevin Hilman wrote:
Tony Lindgren writes:
[...]
> ..but I think I found the cause for recent hangs on panda, just a wild
> guess based on looking at the recent cpuidle patches after v3.14.
>
> Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
> until all coupled CPUs leave idle) makes booting work reliably again
> on panda.
>
> Can you guys confirm, so far no issues here after few boot tests,
> but it might be too early to tell.
Reverting that makes things a bit more stable, but it still eventually
fails in the same way. For me it took 8 boots for it to eventually
fail.
However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
(20+ boots in a row and still going.)
>>>
>>> Can you please test with CPU_IDLE enabled but C3 disabled as in below patch?
>>> It worked for me 10/10 boots.
>>
>> Yup, it worked for me too for 10/10 boots in a row.
>
> But what has caused this regression, does it work reliably with let's
> say v3.13 or v3.12?
>
IIRC things were stable till some CPUIDLE code consolidation happened.
I don't recall exactly but some one did discuss about it a while back.
Can you re-run your test-cases with patch at end of the email. This
is just a hunch so don't blame me if I waste your time testing the
patch.
regards,
Santosh
>From bdd30d68f8fa659aa0e3ce436f94029a7719036b Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] Revert "cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag"
This reverts commit cb7094e848f7bcaa0a4cda3db4b232f08dbf5b78.
Conflicts:
arch/arm/mach-omap2/cpuidle44xx.c
---
arch/arm/mach-omap2/cpuidle44xx.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..aae3606 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -83,6 +83,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
{
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+ int cpu_id = smp_processor_id();
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +111,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx->mpu_state == PWRDM_POWER_RET) &&
(cx->mpu_logic_state == PWRDM_POWER_OFF);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +168,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev->cpu == 0 && mpuss_can_lose_context)
cpu_cluster_pm_exit();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu_id);
+
fail:
cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
cpu_done[dev->cpu] = false;
@@ -189,8 +194,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
- .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
-CPUIDLE_FLAG_TIMER_STOP,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = "C2",
.desc = "CPUx OFF, MPUSS CSWR",
@@ -199,8 +203,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
.exit_latency = 460 + 518,
.target_residency = 1100,
- .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
-CPUIDLE_FLAG_TIMER_STOP,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = "C3",
.desc = "CPUx OFF, MPUSS OSWR",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RCU stall on panda
* Paul E. McKenney [140505 11:11]: > On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: > > I keep seeing the RCU stall problem on panda board from 3.10 kernel to > > latest upstream kernel > > and google find some one report it before: > > https://lkml.org/lkml/2012/9/20/519 > > > > Is it the hardware issue or a real software problem? > > I cannot distinguish between hardware and software from the trace below, > but given that you are also seeing a soft lockup, either way you do > appear to have a real problem as opposed to an RCU CPU stall warning > false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread "omap4-panda-es boot issues with v3.15-rc4" I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Regards, Tony > > 95.519653] INFO: rcu_sched self-detected stall on CPU^M > > [ 95.519866] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M > > [ 95.526489] INFO: rcu_sched detected stalls on CPUs/tasks:^M > > [ 95.526489] 1: (1 GPs behind) idle=2e7/1/0 softirq=4404/4405 ^M > > [ 95.526489] (detected by 0, t=4229 jiffies, g=800, c=799, q=440)^M > > [ 95.526519] Task dump for CPU 1:^M > > [ 95.526519] swapper/1 R running 0 0 1 0x^M > > [ 95.559844] (t=4229 jiffies g=800 c=799 q=440)^M > > [ 95.564727] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.15.0-rc4 #93^M > > [ 95.571502] [] (unwind_backtrace) from [] > > (show_stack+0x11/0x14)^M > > [ 95.579711] [] (show_stack) from [] > > (dump_stack+0x75/0x88)^M > > [ 95.587371] [] (dump_stack) from [] > > (rcu_check_callbacks+0x353/0x79c)^M > > [ 95.596038] [] (rcu_check_callbacks) from [] > > (update_process_times+0x33/0x4c)^M > > [ 95.605438] [] (update_process_times) from [] > > (tick_sched_handle.isra.18+0x1f/0x48)^M > > [ 95.615386] [] (tick_sched_handle.isra.18) from [] > > (tick_sched_timer+0x3d/0x5c)^M > > [ 95.624969] [] (tick_sched_timer) from [] > > (__run_hrtimer+0x67/0x310)^M > > [ 95.633544] [] (__run_hrtimer) from [] > > (hrtimer_interrupt+0xe1/0x214)^M > > [ 95.642211] [] (hrtimer_interrupt) from [] > > (tick_receive_broadcast+0x1f/0x30)^M > > [ 95.651611] [] (tick_receive_broadcast) from [] > > (handle_IPI+0xb3/0x120)^M > > [ 95.660461] [] (handle_IPI) from [] > > (gic_handle_irq+0x51/0x54)^M > > [ 95.668487] [] (gic_handle_irq) from [] > > (__irq_svc+0x3f/0x64)^M > > [ 95.676391] Exception stack(0xee0dbf10 to 0xee0dbf58)^M > > [ 95.681762] bf00: 0001 0001 > > ee0d8c40^M > > [ 95.690429] bf20: 3c6bd296 0016 3c6f8c43 0016 eefab540 c08e0c84 > > c0fc7114^M > > [ 95.699066] bf40: 0010 ee0dbf58 c006ef4d c0443890 4033 ^M > > [ 95.706085] [] (__irq_svc) from [] > > (cpuidle_enter_state+0xc0/0xc4)^M > > [ 95.714477] [] (cpuidle_enter_state) from [] > > (cpuidle_enter_state_coupled+0xe1/0x290)^M > > [ 95.724639] [] (cpuidle_enter_state_coupled) from [] > > (cpu_startup_entry+0x1a5/0x494)^M > > [ 95.734680] [] (cpu_startup_entry) from [<80008685>] > > (0x80008685)^M > > [ 95.742095] BUG: soft lockup - CPU#1 stuck for 40s! [swapper/1:0]^M > > [ 95.748535] Modules linked in:^M > > [ 95.751770] irq event stamp: 128730^M > > [ 95.755462] hardirqs last enabled at (128727): [] > > cpuidle_enter_state+0xbf/0xc4^M > > [ 95.764221] hardirqs last disabled at (128728): [] > > __irq_svc+0x33/0x64^M > > [ 95.772064] softirqs last enabled at (128730): [] > > irq_enter+0x59/0x60^M > > [ 95.779907] softirqs last disabled at (128729): [] > > irq_enter+0x46/0x60^M > > [ 95.787750] ^M > > > > > > my RCU and IDLE related kernel config as blow: > > > > CONFIG_TREE_RCU=y > > CONFIG_RCU_STALL_COMMON=y > > CONFIG_RCU_FANOUT=32 > > CONFIG_RCU_FANOUT_LEAF=16 > > CONFIG_TREE_RCU_TRACE=y > > CONFIG_PROVE_RCU=y > > CONFIG_PROVE_RCU_REPEATEDLY=y > > CONFIG_SPARSE_RCU_POINTER=y > > CONFIG_RCU_CPU_STALL_TIMEOUT=21 > > CONFIG_RCU_CPU_STALL_INFO=y > > CONFIG_RCU_TRACE=y > > alexs@alex-panda:~$ cat /proc/config.gz | gunzip | grep IDLE > > CONFIG_NO_HZ_IDLE=y > > CONFIG_GENERIC_SMP_IDLE_THREAD=y > > CONFIG_GENERIC_IDLE_POLL_SETUP=y > > CONFIG_CPU_IDLE=y > > CONFIG_CPU_IDLE_GOV_LADDER=y > > CONFIG_CPU_IDLE_GOV_MENU=y > > CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED=y > > > > -- > > Thanks > > Alex > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
On 12 May 2014 11:12, Jyri Sarha 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson [140512 13:58]: > >> Either case if fine with me. As who knows when the dtc "overlay" will > >> every truly make it mainline, as the capemgr was the only real kernel > >> user of the i2c/at24 eeprom information. > > > > Sounds like we should keep it disabled though so u-boot can be used > > to toggle it while waiting for the capemgr. That's because the board > > has a header for pins, so it's not exactly limited to just the capes. > > > > Anybody working on enabling/disabling cape dtb configurations in u-boot? > > Well, > > Would Tom even approve of that in mainline u-boot? He didn't want my > "invert" the gpio to enable the usb hub on the older beagle xm A/B.. > > http://lists.denx.de/pipermail/u-boot/2014-January/172154.html > > http://lists.denx.de/pipermail/u-boot/2014-January/172274.html Right, no idea. But until we have some way to actually use the capes without conflicting dts entries, I can't merge them. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
>> Either case if fine with me. As who knows when the dtc "overlay" will >> every truly make it mainline, as the capemgr was the only real kernel >> user of the i2c/at24 eeprom information. > > Sounds like we should keep it disabled though so u-boot can be used > to toggle it while waiting for the capemgr. That's because the board > has a header for pins, so it's not exactly limited to just the capes. > > Anybody working on enabling/disabling cape dtb configurations in u-boot? Well, Would Tom even approve of that in mainline u-boot? He didn't want my "invert" the gpio to enable the usb hub on the older beagle xm A/B.. http://lists.denx.de/pipermail/u-boot/2014-January/172154.html http://lists.denx.de/pipermail/u-boot/2014-January/172274.html Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson [140512 13:27]: > >> > > >> > If these pins are not used for i2c2 on some capes, this device > >> > should be set to status = "disabled" state by default. Then > >> > u-boot could re-enable it on the boards that have i2c2 in use. > >> > >> To-date, this is the i2c bus that all capes have placed an at24 eeprom > >> for cape identification. > > > > And how many capes actually implement the eeprom cape identification > > out of the available capes? :) > > Not including one off designs in someone's lab. We will never have an > accurate number. ;) > > So far; just the ones that want their "cape" detected in the default > image currently being shipped by CircuitCo. Otherwise the few that > I've seen without an eeprom, usually follow this default pinmux. > > http://elinux.org/CircuitCo:Basic_Proto_Cape > > Which includes that i2c bus enabled. OK thanks for the info. > Either case if fine with me. As who knows when the dtc "overlay" will > every truly make it mainline, as the capemgr was the only real kernel > user of the i2c/at24 eeprom information. Sounds like we should keep it disabled though so u-boot can be used to toggle it while waiting for the capemgr. That's because the board has a header for pins, so it's not exactly limited to just the capes. Anybody working on enabling/disabling cape dtb configurations in u-boot? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
>> > >> > If these pins are not used for i2c2 on some capes, this device >> > should be set to status = "disabled" state by default. Then >> > u-boot could re-enable it on the boards that have i2c2 in use. >> >> To-date, this is the i2c bus that all capes have placed an at24 eeprom >> for cape identification. > > And how many capes actually implement the eeprom cape identification > out of the available capes? :) Not including one off designs in someone's lab. We will never have an accurate number. ;) So far; just the ones that want their "cape" detected in the default image currently being shipped by CircuitCo. Otherwise the few that I've seen without an eeprom, usually follow this default pinmux. http://elinux.org/CircuitCo:Basic_Proto_Cape Which includes that i2c bus enabled. Either case if fine with me. As who knows when the dtc "overlay" will every truly make it mainline, as the capemgr was the only real kernel user of the i2c/at24 eeprom information. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Robert Nelson [140512 13:00]:
> >>
> >> + i2c2_pins: pinmux_i2c2_pins {
> >> + pinctrl-single,pins = <
> >> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
> >> uart1_ctsn.i2c2_sda */
> >> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
> >> uart1_rtsn.i2c2_scl */
> >> + >;
> >> + };
> >> +
> >> uart0_pins: pinmux_uart0_pins {
> >> pinctrl-single,pins = <
> >> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> >> uart0_rxd.uart0_rxd */
> >>
> >> @@ -222,6 +229,15 @@
> >>
> >> };
> >>
> >> +
> >> +&i2c2 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&i2c2_pins>;
> >> +
> >> + status = "okay";
> >> + clock-frequency = <10>;
> >> +};
> >> +
> >
> > If these pins are not used for i2c2 on some capes, this device
> > should be set to status = "disabled" state by default. Then
> > u-boot could re-enable it on the boards that have i2c2 in use.
>
> To-date, this is the i2c bus that all capes have placed an at24 eeprom
> for cape identification.
And how many capes actually implement the eeprom cape identification
out of the available capes? :)
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] mtd: nand: omap: add support for BCH16_ECC - ELM driver updates
On Fri, May 09, 2014 at 02:29:13PM +0530, Pekon Gupta wrote:
> ELM hardware engine is used to detect ECC errors for BCHx ecc-schemes
> (like BCH4/BCH8/BCH16). This patch extends configuration of ELM registers
> for loading of BCH16 ECC syndrome.
>
> Signed-off-by: Pekon Gupta
> ---
> drivers/mtd/devices/elm.c | 42
> +++
> include/linux/platform_data/elm.h | 3 ++-
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
> index 1fd4a0f..b4b02a1 100644
> --- a/drivers/mtd/devices/elm.c
> +++ b/drivers/mtd/devices/elm.c
> @@ -213,6 +213,34 @@ static void elm_load_syndrome(struct elm_info *info,
> val = cpu_to_be32(*(u32 *) &ecc[0]) >> 12;
> elm_write_reg(info, offset, val);
> break;
> + case BCH16_ECC:
> + val = ecc[25] << 0 | ecc[24] << 8 |
> + ecc[23] << 16 | ecc[22] << 24;
Why can't you use the style of the rest of this switch block? Like:
val = cpu_to_be32(*(u32 *)&ecc[22]);
Or are there alignment assues with doing this?
Anyway, you need to reconcile these two options, since it looks like
you've only written this for little-endian.
> + elm_write_reg(info, offset, val);
> + offset += 4;
> + val = ecc[21] << 0 | ecc[20] << 8 |
> + ecc[19] << 16 | ecc[18] << 24;
(Same applies here, and below.)
> + elm_write_reg(info, offset, val);
> + offset += 4;
> + val = ecc[17] << 0 | ecc[16] << 8 |
> + ecc[15] << 16 | ecc[14] << 24;
> + elm_write_reg(info, offset, val);
> + offset += 4;
> + val = ecc[13] << 0 | ecc[12] << 8 |
> + ecc[11] << 16 | ecc[10] << 24;
> + elm_write_reg(info, offset, val);
> + offset += 4;
> + val = ecc[9] << 0 | ecc[8] << 8 |
> + ecc[7] << 16 | ecc[6] << 24;
> + elm_write_reg(info, offset, val);
> + offset += 4;
> + val = ecc[5] << 0 | ecc[4] << 8 |
> + ecc[3] << 16 | ecc[2] << 24;
> + elm_write_reg(info, offset, val);
> + offset += 4;
> + val = ecc[1] << 0 | ecc[0] << 8;
> + elm_write_reg(info, offset, val);
> + break;
> default:
> pr_err("invalid config bch_type\n");
> }
> @@ -435,6 +463,13 @@ static int elm_context_save(struct elm_info *info)
> for (i = 0; i < ERROR_VECTOR_MAX; i++) {
> offset = i * SYNDROME_FRAGMENT_REG_SIZE;
> switch (bch_type) {
> + case BCH16_ECC:
> + regs->elm_syndrome_fragment_6[i] = elm_read_reg(info,
> + ELM_SYNDROME_FRAGMENT_6 + offset);
> + regs->elm_syndrome_fragment_5[i] = elm_read_reg(info,
> + ELM_SYNDROME_FRAGMENT_5 + offset);
> + regs->elm_syndrome_fragment_4[i] = elm_read_reg(info,
> + ELM_SYNDROME_FRAGMENT_4 + offset);
> case BCH8_ECC:
> regs->elm_syndrome_fragment_3[i] = elm_read_reg(info,
> ELM_SYNDROME_FRAGMENT_3 + offset);
> @@ -473,6 +508,13 @@ static int elm_context_restore(struct elm_info *info)
> for (i = 0; i < ERROR_VECTOR_MAX; i++) {
> offset = i * SYNDROME_FRAGMENT_REG_SIZE;
> switch (bch_type) {
> + case BCH16_ECC:
> + elm_write_reg(info, ELM_SYNDROME_FRAGMENT_6 + offset,
> + regs->elm_syndrome_fragment_6[i]);
> + elm_write_reg(info, ELM_SYNDROME_FRAGMENT_5 + offset,
> + regs->elm_syndrome_fragment_5[i]);
> + elm_write_reg(info, ELM_SYNDROME_FRAGMENT_4 + offset,
> + regs->elm_syndrome_fragment_4[i]);
> case BCH8_ECC:
> elm_write_reg(info, ELM_SYNDROME_FRAGMENT_3 + offset,
> regs->elm_syndrome_fragment_3[i]);
> diff --git a/include/linux/platform_data/elm.h
> b/include/linux/platform_data/elm.h
> index 4edb406..ac2f266 1
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
>>
>> + i2c2_pins: pinmux_i2c2_pins {
>> + pinctrl-single,pins = <
>> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
>> uart1_ctsn.i2c2_sda */
>> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
>> uart1_rtsn.i2c2_scl */
>> + >;
>> + };
>> +
>> uart0_pins: pinmux_uart0_pins {
>> pinctrl-single,pins = <
>> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
>> uart0_rxd.uart0_rxd */
>>
>> @@ -222,6 +229,15 @@
>>
>> };
>>
>> +
>> +&i2c2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&i2c2_pins>;
>> +
>> + status = "okay";
>> + clock-frequency = <10>;
>> +};
>> +
>
> If these pins are not used for i2c2 on some capes, this device
> should be set to status = "disabled" state by default. Then
> u-boot could re-enable it on the boards that have i2c2 in use.
To-date, this is the i2c bus that all capes have placed an at24 eeprom
for cape identification.
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ?
+ devicet...@vger.kernel.org On Fri, May 09, 2014 at 02:29:15PM +0530, Pekon Gupta wrote: > - Adds DT binding property for BCH16 ECC scheme > - Adds describes on factors which determine choice of ECC scheme for > particular device > > Signed-off-by: Pekon Gupta > --- > .../devicetree/bindings/mtd/gpmc-nand.txt | 39 > ++ > 1 file changed, 39 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt > b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt > index 5e1f31b..f2dbb33 100644 > --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt > +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt > @@ -28,6 +28,8 @@ Optional properties: > "ham1" 1-bit Hamming ecc code > "bch4" 4-bit BCH ecc code > "bch8" 8-bit BCH ecc code > + "bch16" 16-bit BCH ECC code > + Refer below "How to select correct ECC scheme for your device ?" > > - ti,nand-xfer-type:A string setting the data transfer > type. One of: > > @@ -90,3 +92,40 @@ Example for an AM33xx board: > }; > }; > > +How to select correct ECC scheme for your device ? > +-- > +Higher ECC scheme usually means better protection against bit-flips and > +increased system lifetime. However, selection of ECC scheme is dependent > +on various other factors like; > +(1) Presence of supporting hardware engines on SoC. > + Some legacy OMAP SoC do not have ELM h/w engine thus such SoC cannot > + support BCHx_HW ECC schemes. But such SoC can support > + BCHx_HW_DETECTION_SW ECC schemes which use s/w library with slight > + CPU performance panalty only when too bit-flips are detected. s/panalty/penalty/ Please do not refer to Linux Kconfig symbols and jargon. It's already confusing to understand what your various permutations of BCHx_HW_DETECTION_SW mean. Please simply speak of hardware support and software library support that can be used to fill in the gaps, using plain English. This is not the place to discuss Linux details. > +(2) Device parameters like OOBSIZE > + Higher ECC schemes require more OOB/Spare area to store ECC. > + So choice of ECC scheme is limited by NAND oobsize. In general > + following expression help determine whether given device can > + accomodate ECC syndrome or not: > + "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE > + where > + OOBSIZE number of bytes in OOB/spare area > + PAGESIZEnumber of bytes in main-area of device page > + ECC_BYTES number of ECC bytes generated to protect > + 512 bytes of data, which is: > + '3' for HAM1_xx ecc schemes > + '7' for BCH4_xx ecc schemes > + '14' for BCH8_xx ecc schemes > + '26' for BCH16_xx ecc schemes > + > + Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 > + Number of spare/OOB bytes required for using BCH16 ecc-scheme > + "(2 + (2048 / 512) * 26) = 106 bytes" is greater than OOBSIZE > + (As per above table for BCH16 ecc-scheme, ECC_BYTES = 26) > + Thus BCH16 cannot be supported on 2K NAND with OOBSIZE=64 bytes > + > + Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 > + Number of spare/OOB bytes required for using BCH16 ecc-scheme > + "(2 + (2048 / 512) * 26) = 106 bytes" is less than OOBSIZE > + (As per above table for BCH16 ecc-scheme, ECC_BYTES = 26) > + Thus BCH16 can be supported on 4K NAND with OOBSIZE=128 bytes Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition
* Matt Ranostay [140509 18:43]:
> Add missing i2c2 bus define to access various cape and
> prototype/breakout board devices.
>
> Signed-off-by: Matt Ranostay
> ---
> arch/arm/boot/dts/am335x-bone-common.dtsi | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 2e7d932..5fdae2e 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -84,6 +84,13 @@
> >;
> };
>
> + i2c2_pins: pinmux_i2c2_pins {
> + pinctrl-single,pins = <
> + 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
> uart1_ctsn.i2c2_sda */
> + 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
> uart1_rtsn.i2c2_scl */
> + >;
> + };
> +
> uart0_pins: pinmux_uart0_pins {
> pinctrl-single,pins = <
> 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> uart0_rxd.uart0_rxd */
>
> @@ -222,6 +229,15 @@
>
> };
>
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +};
> +
If these pins are not used for i2c2 on some capes, this device
should be set to status = "disabled" state by default. Then
u-boot could re-enable it on the boards that have i2c2 in use.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/6] ARM: dts: am335x-evm: fix reg and range property of GPMC NAND node
* Javier Martinez Canillas [140510 10:12]: > Hello Pekon, > > On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta wrote: > > 1) NAND device memory is not directly accessible to CPU, its indirectly > > accessed > >via registers. So the 'reg' property for GPMC NAND nodes should be > > limited to > >address range of internal GPMC registers only. > > 2) Also, minimum granularity of address space under a GPMC chip-select is > > 16MB > >so 'range' property for GPMC NAND node should specify 16MB as its > > memory-size > > This is true for all SoC using the GPMC right? So we need to do the > same modification for all OMAP boards to avoid mapping a bigger > address space unnecessarily. Yes we should fix them all up. See also the commenting standard I suggested in the parallel NAND series. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [v2 Patch 2/6] ARM: TI: Describe the ti reset DT entries
Dan,
On 05/06/2014 08:18 AM, Murphy, Dan wrote:
> Tony
>
> Thanks for the comments
>
> On 05/05/2014 05:01 PM, Tony Lindgren wrote:
>> * Dan Murphy [140505 13:10]:
>>> +
>>> +Required parent properties:
>>> +- compatible : Should be one of,
>>> + "ti,omap4-prm" for OMAP4 PRM instances
>>> + "ti,omap5-prm" for OMAP5 PRM instances
>>> + "ti,dra7-prm" for DRA7xx PRM instances
>>> + "ti,am4-prcm" for AM43xx PRCM instances
>>> + "ti,am3-prcm" for AM33xx PRCM instances
>>> +
>>> +Required child reset property:
>>> +- compatible : Should be
>>> + "resets" for All TI SoCs
>>> +
>>> +example:
>>> + prm: prm@4ae06000 {
>>> + compatible = "ti,omap5-prm";
>>> + reg = <0x4ae06000 0x3000>;
>>> +
>>> + prm_resets: resets {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + #reset-cells = <1>;
>>> + };
>>> + };
>> The reg entries you have in the example below has different format
>> compared to this?
Right, the #size-cells should have been 0, or each reg field updated
with an additional field value of 4 as the registers are all of constant
width - 4 bytes.
>
> This is the parent to the resets. The reg entries below are for
> the child reset signals.
>
>>
>>> +Reset node declaration
>>> +==
>>> +The reset node is declared in a parent child relationship. The main parent
>>> +is the PRCM module which contains the base address. The first child within
>>> +the reset parent declares the target modules reset name. This is followed
>>> by
>>> +the control and status offsets.
>>> +
>>> +Within the first reset child node is a secondary child node which declares
>>> the
>>> +reset signal of interest. Under this node the control and status bits
>>> +are declared. These bits declare the bit mask for the target reset.
>>> +
>>> +
>>> +Required properties:
>>> +reg - This is the register offset from the PRCM parent.
>>> + This must be declared as:
>>> +
>>> + reg = ,
>>> + ;
>>> +
>>> +control-bit - This is the bit within the register which controls the reset
>>> + of the target module. This is declared as a bit mask for the register.
>>> +status-bit - This is the bit within the register which contains the status
>>> of
>>> + the reset of the target module.
>>> + This is declared as a bit mask for the register.
>>> +
>>> +example:
>>> +&prm_resets {
>>> + dsp_rstctrl {
>>> + reg = <0x1c00>,
>>> + <0x1c04>;
>> Shouldn't this be start and size instead of start and end here?
These are two registers - one for control and one for status.
>
> I could do start and size. But the size will be the same for each register.
> AM33xx really hurts the consistency model here as the other patches in the
> series
> it appears that the control and status are consistent but AM33xx the
> registers are all over
> the place.
>
> I have not looked at OMAP2->4 yet for control and status register offsets.
>
>>> + dsp_reset: dsp_reset {
>>> + control-bit = <0x01>;
>>> + status-bit = <0x01>;
>>> + };
>>> + };
>>> +};
>> Are the control-bit and status-bit always the same? If so, you can
>> keep that knowlede private to the the driver.
>
> No there is a case in the am33xx resets file where the status and control
> bits are not the same.
Do we really need two separate properties to represent this, as these
are essentially the relevant bits in the corresponding reg elements.
I guess this is somewhat same as Tony's suggestion about using the reg
field for these sub-nodes, in which case, you would have to add another
#address-cells as 1 for each of the child reset nodes.
regards
Suman
>
>>
>> And maybe you can have the bit offset in a reg property here to
>> avoid adding any custom properties? Something like:
>>
>> dsp_reset: reset@1 {
>> reg = 1;
>> };
>>
>> If reg is not suitable for that, it seems that some generic property
>> to describe the bit offset is needed by quite a few drivers
>> anyways, for things like clocks and regulators.
>
> I will have to look into this. Maybe a generic entry called bit-offset
> that defines the bit or a mask for the registers. It can mimic the reg
> entry.
>
>>> +Client Node Declaration
>>> +==
>>> +This is the consumer of the parent node to declare what resets this
>>> +particular module is interested in.
>>> +
>>> +example:
>>> + src: src@55082000 {
>>> + resets = <&reset_src phandle>;
>>> + reset-names = "";
>>> + };
>>> +
>>> +Required Properties:
>>> +reset_src - This is the parent DT entry for the reset controller
>>> +phandle - This is the phandle of the specific reset to be used by the clien
>>> + dri
[PATCH v2] ARM: OMAP2+: Remove suspend_set_ops from common pm late init
In omap2_common_pm_late_init suspend_set_ops was called to set common
suspend handling functions for all omap platforms. This created two
problems. First, these suspend ops were being set for all platforms,
regardless of whether or not suspend support has been integrated so in
the case of AM33XX, suspend to mem was presented as available but
failed every time. Second, some platforms will need to define a
completely separate set of suspend ops, such as AM33XX, due to
differences from previous omap platforms so there is no need to
always set the common omap ops.
This patch moves the suspend_set_ops call from omap2_common_pm_late_init
into a separate function that then gets called in the omap*_pm_init
functions for each platform.
Signed-off-by: Dave Gerlach
---
v2:
Don't need to expose omap_pm_ops, use omap_common_suspend_init to set
Add kernel-doc for omap_common_suspend_init
arch/arm/mach-omap2/pm.c | 17 -
arch/arm/mach-omap2/pm.h | 8 +++-
arch/arm/mach-omap2/pm24xx.c | 4 +---
arch/arm/mach-omap2/pm34xx.c | 7 +++
arch/arm/mach-omap2/pm44xx.c | 6 +++---
5 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e1b4141..dd31212 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -32,11 +32,13 @@
#include "pm.h"
#include "twl-common.h"
+#ifdef CONFIG_SUSPEND
/*
* omap_pm_suspend: points to a function that does the SoC-specific
* suspend work
*/
-int (*omap_pm_suspend)(void);
+static int (*omap_pm_suspend)(void);
+#endif
#ifdef CONFIG_PM
/**
@@ -243,6 +245,15 @@ static const struct platform_suspend_ops omap_pm_ops = {
.valid = suspend_valid_only_mem,
};
+/**
+ * omap_common_suspend_init - Set common suspend routines for OMAP SoCs
+ * @pm_suspend: function pointer to SoC specific suspend function
+ */
+void omap_common_suspend_init(void *pm_suspend)
+{
+ omap_pm_suspend = pm_suspend;
+ suspend_set_ops(&omap_pm_ops);
+}
#endif /* CONFIG_SUSPEND */
static void __init omap3_init_voltages(void)
@@ -310,9 +321,5 @@ int __init omap2_common_pm_late_init(void)
/* cpufreq dummy device instantiation */
omap_init_cpufreq();
-#ifdef CONFIG_SUSPEND
- suspend_set_ops(&omap_pm_ops);
-#endif
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index d4d0fce..e150102 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -34,7 +34,6 @@ extern void *omap3_secure_ram_storage;
extern void omap3_pm_off_mode_enable(int);
extern void omap_sram_idle(void);
extern int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused);
-extern int (*omap_pm_suspend)(void);
#if defined(CONFIG_PM_OPP)
extern int omap3_opp_init(void);
@@ -147,4 +146,11 @@ static inline void omap_pm_get_oscillator(u32 *tstart, u32
*tshut) { *tstart = *
static inline void omap_pm_setup_sr_i2c_pcb_length(u32 mm) { }
#endif
+#ifdef CONFIG_SUSPEND
+void omap_common_suspend_init(void *pm_suspend);
+#else
+static inline void omap_common_suspend_init(void *pm_suspend)
+{
+}
+#endif /* CONFIG_SUSPEND */
#endif
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 8c07594..a5ea988 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -229,9 +229,7 @@ static void __init prcm_setup_regs(void)
clkdm_for_each(omap_pm_clkdms_setup, NULL);
clkdm_add_wkdep(mpu_clkdm, wkup_clkdm);
-#ifdef CONFIG_SUSPEND
- omap_pm_suspend = omap2_enter_full_retention;
-#endif
+ omap_common_suspend_init(omap2_enter_full_retention);
/* REVISIT: Configure number of 32 kHz clock cycles for sys_clk
* stabilisation */
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 87099bb..90ea2d3 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -391,7 +391,8 @@ restore:
return ret;
}
-
+#else
+#define omap3_pm_suspend NULL
#endif /* CONFIG_SUSPEND */
@@ -705,9 +706,7 @@ int __init omap3_pm_init(void)
per_clkdm = clkdm_lookup("per_clkdm");
wkup_clkdm = clkdm_lookup("wkup_clkdm");
-#ifdef CONFIG_SUSPEND
- omap_pm_suspend = omap3_pm_suspend;
-#endif
+ omap_common_suspend_init(omap3_pm_suspend);
arm_pm_idle = omap3_pm_idle;
omap3_idle_init();
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index eefb30c..0dda6cf 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -96,6 +96,8 @@ static int omap4_pm_suspend(void)
return 0;
}
+#else
+#define omap4_pm_suspend NULL
#endif /* CONFIG_SUSPEND */
static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
@@ -251,9 +253,7 @@ int __init omap4_pm_init(void)
(void) clkdm_for_each(omap_pm_clkdms_setup, NULL);
-#ifdef CONFIG_SUSPEND
- omap_pm_suspend = omap4_pm_suspend;
-#endif
+ omap_common_sus
[PATCH v3 2/4] ARM: dts: Add support for OMAP4 VAR-DVK-OM44
Signed-off-by: Joachim Eastwood
Acked-by: Tomi Valkeinen
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/omap4-var-dvk-om44.dts | 70 ++
3 files changed, 74 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-var-dvk-om44.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index b2f1948a3fd1..189baba40cd6 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -108,6 +108,9 @@ Boards:
- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and
VAR-SOM-OM44 w/WLAN
compatible = "variscite,var-stk-om44", "variscite,var-som-om44",
"ti,omap4460", "ti,omap4";
+- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard,
VAR-SOM-OM44 w/WLAN and LCD touchscreen
+ compatible = "variscite,var-dvk-om44", "variscite,var-som-om44",
"ti,omap4460", "ti,omap4";
+
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3715f902d177..a81a24c7c184 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -284,6 +284,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-panda-es.dtb \
omap4-sdp.dtb \
omap4-sdp-es23plus.dtb \
+ omap4-var-dvk-om44.dtb \
omap4-var-stk-om44.dtb
dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
am437x-gp-evm.dtb
diff --git a/arch/arm/boot/dts/omap4-var-dvk-om44.dts
b/arch/arm/boot/dts/omap4-var-dvk-om44.dts
new file mode 100644
index ..6138d7eb8efa
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-var-dvk-om44.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2014 Joachim Eastwood
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "omap4-var-som-om44.dtsi"
+#include "omap4-var-om44customboard.dtsi"
+
+/ {
+ model = "Variscite VAR-DVK-OM44";
+ compatible = "variscite,var-dvk-om44", "variscite,var-som-om44",
"ti,omap4460", "ti,omap4";
+
+ aliases {
+ display0 = &lcd0;
+ display1 = &hdmi0;
+ };
+
+ lcd0: display {
+ compatible = "innolux,at070tn83", "panel-dpi";
+ label = "lcd";
+ panel-timing {
+ clock-frequency = <>;
+
+ hback-porch = <40>;
+ hactive = <800>;
+ hfront-porch = <40>;
+ hsync-len = <48>;
+
+ vback-porch = <29>;
+ vactive = <480>;
+ vfront-porch = <13>;
+ vsync-len = <3>;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+
+ backlight {
+ compatible = "gpio-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&backlight_pins>;
+
+ gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>; /* gpio 122 */
+ };
+};
+
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_dpi_pins>;
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <24>;
+ };
+ };
+};
+
+&dsi2 {
+ status = "okay";
+ vdd-supply = <&vcxio>;
+};
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] ARM: dts: Add support for OMAP4 Variscite OM44 family
Add support for VAR-SOM-OM44[1] SODIMM system on module from
Variscite. SoM features a OMAP4460, 1GB RAM, Gigabit Ethernet
(LAN7500) and optional WLAN/BT.
Also add support for VAR-STK-OM44 development board from
Variscite. This kit features a VAR-SOM-OM44 and the carrier board
VAR-OM44CustomBoard[2]. The VAR-STK-OM44 is the same as
VAR-DVK-OM44 but without the LCD display.
omap4-var-stk-om44.dts replace the old and very limited
omap4-var-som.dts.
[1]
http://www.variscite.com/products/system-on-module-som/cortex-a9/var-som-om44-cpu-ti-omap-4-omap4460
[2] http://www.variscite.com/products/single-board-computers/var-om44customboard
Signed-off-by: Joachim Eastwood
Acked-by: Tomi Valkeinen
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/boot/dts/Makefile | 2 +-
arch/arm/boot/dts/omap4-var-om44customboard.dtsi | 235 ++
arch/arm/boot/dts/omap4-var-som-om44.dtsi | 343 +
arch/arm/boot/dts/omap4-var-som.dts| 96 --
arch/arm/boot/dts/omap4-var-stk-om44.dts | 16 +
7 files changed, 599 insertions(+), 97 deletions(-)
create mode 100644 arch/arm/boot/dts/omap4-var-om44customboard.dtsi
create mode 100644 arch/arm/boot/dts/omap4-var-som-om44.dtsi
delete mode 100644 arch/arm/boot/dts/omap4-var-som.dts
create mode 100644 arch/arm/boot/dts/omap4-var-stk-om44.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 3bad25965133..b2f1948a3fd1 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -105,6 +105,9 @@ Boards:
- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero",
"ti,omap4430", "ti,omap4";
+- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and
VAR-SOM-OM44 w/WLAN
+ compatible = "variscite,var-stk-om44", "variscite,var-som-om44",
"ti,omap4460", "ti,omap4";
+
- OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
compatible = "ti,omap3-evm", "ti,omap3"
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index abc308083acb..cc5a116a1eca 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -127,6 +127,7 @@ toshiba Toshiba Corporation
toumaz Toumaz
usiUniversal Scientifc Industrial Co., Ltd.
v3 V3 Semiconductor
+variscite Variscite Ltd.
viaVIA Technologies, Inc.
voipac Voipac Technologies s.r.o.
winbond Winbond Electronics corp.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 53d995f4ce12..3715f902d177 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -284,7 +284,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-panda-es.dtb \
omap4-sdp.dtb \
omap4-sdp-es23plus.dtb \
- omap4-var-som.dtb
+ omap4-var-stk-om44.dtb
dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
am437x-gp-evm.dtb
dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
diff --git a/arch/arm/boot/dts/omap4-var-om44customboard.dtsi
b/arch/arm/boot/dts/omap4-var-om44customboard.dtsi
new file mode 100644
index ..f2d2fdb75628
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-var-om44customboard.dtsi
@@ -0,0 +1,235 @@
+/*
+ * Copyright (C) 2014 Joachim Eastwood
+ *
+ * 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.
+ */
+
+#include
+
+/ {
+ aliases {
+ display0 = &hdmi0;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_led_pins>;
+
+ led0 {
+ label = "var:green:led0";
+ gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>; /* gpio 173 */
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1 {
+ label = "var:green:led1";
+ gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>; /* gpio 172 */
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpio_key_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ user-key@184 {
+ label = "user";
+ gpios = <&gpio6 24 GPIO_ACTIVE_HIGH>; /* gpio 184 */
+ linux,code = ;
+ gpio-key,wakeup;
+ };
+ };
+
+ hdmi0: connector@0 {
+
[PATCH v3 3/4] ARM: dts: Add VAR-SOM-OM44 WLAN nodes
Both the VAR-STK-OM44 and VAR-DVK-OM44 boards comes with the
WLAN/BT version of the system on module VAR-SOM-OM44.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/omap4-var-dvk-om44.dts | 1 +
arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi | 68 ++
arch/arm/boot/dts/omap4-var-stk-om44.dts | 1 +
3 files changed, 70 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi
diff --git a/arch/arm/boot/dts/omap4-var-dvk-om44.dts
b/arch/arm/boot/dts/omap4-var-dvk-om44.dts
index 6138d7eb8efa..458d79fa378b 100644
--- a/arch/arm/boot/dts/omap4-var-dvk-om44.dts
+++ b/arch/arm/boot/dts/omap4-var-dvk-om44.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "omap4-var-som-om44.dtsi"
+#include "omap4-var-som-om44-wlan.dtsi"
#include "omap4-var-om44customboard.dtsi"
/ {
diff --git a/arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi
b/arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi
new file mode 100644
index ..cc66af419236
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi
@@ -0,0 +1,68 @@
+/*
+ * Copyright (C) 2014 Joachim Eastwood
+ *
+ * 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.
+ */
+
+/ {
+ /* regulator for wl12xx on sdio4 */
+ wl12xx_vmmc: wl12xx_vmmc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wl12xx_ctrl_pins>;
+ compatible = "regulator-fixed";
+ regulator-name = "vwl1271";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 11 0>; /* gpio 43 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+};
+
+&omap4_pmx_core {
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x118, PIN_INPUT_PULLUP | MUX_MODE0)
/* uart2_cts.uart2_cts */
+ OMAP4_IOPAD(0x11a, PIN_OUTPUT | MUX_MODE0)
/* uart2_rts.uart2_rts */
+ OMAP4_IOPAD(0x11c, PIN_INPUT_PULLUP | MUX_MODE0)
/* uart2_rx.uart2_rx */
+ OMAP4_IOPAD(0x11e, PIN_OUTPUT | MUX_MODE0)
/* uart2_tx.uart2_tx */
+ >;
+ };
+
+ wl12xx_ctrl_pins: pinmux_wl12xx_ctrl_pins {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x062, PIN_INPUT_PULLUP | MUX_MODE3)
/* gpmc_a17.gpio_41 (WLAN_IRQ) */
+ OMAP4_IOPAD(0x064, PIN_OUTPUT | MUX_MODE3)
/* gpmc_a18.gpio_42 (BT_EN) */
+ OMAP4_IOPAD(0x066, PIN_OUTPUT | MUX_MODE3)
/* gpmc_a19.gpio_43 (WLAN_EN) */
+ >;
+ };
+
+ mmc4_pins: pinmux_mmc4_pins {
+ pinctrl-single,pins = <
+ OMAP4_IOPAD(0x154, PIN_INPUT_PULLUP | MUX_MODE1)
/* mcspi4_clk.sdmmc4_clk */
+ OMAP4_IOPAD(0x156, PIN_INPUT_PULLUP | MUX_MODE1)
/* mcspi4_simo.sdmmc4_cmd */
+ OMAP4_IOPAD(0x158, PIN_INPUT_PULLUP | MUX_MODE1)
/* mcspi4_somi.sdmmc4_dat0 */
+ OMAP4_IOPAD(0x15e, PIN_INPUT_PULLUP | MUX_MODE1)
/* uart4_tx.sdmmc4_dat1 */
+ OMAP4_IOPAD(0x15c, PIN_INPUT_PULLUP | MUX_MODE1)
/* uart4_rx.sdmmc4_dat2 */
+ OMAP4_IOPAD(0x15a, PIN_INPUT_PULLUP | MUX_MODE1)
/* mcspi4_cs0.sdmmc4_dat3 */
+ >;
+ };
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "okay";
+};
+
+&mmc4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc4_pins>;
+ vmmc-supply = <&wl12xx_vmmc>;
+ non-removable;
+ bus-width = <4>;
+ cap-power-off-card;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/omap4-var-stk-om44.dts
b/arch/arm/boot/dts/omap4-var-stk-om44.dts
index bc5dbc950964..56b64e618608 100644
--- a/arch/arm/boot/dts/omap4-var-stk-om44.dts
+++ b/arch/arm/boot/dts/omap4-var-stk-om44.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "omap4-var-som-om44.dtsi"
+#include "omap4-var-som-om44-wlan.dtsi"
#include "omap4-var-om44customboard.dtsi"
/ {
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] ARM: OMAP2+: Use pdata quirks for wl12xx on VAR-STK/DVK-OM44
Signed-off-by: Joachim Eastwood
---
arch/arm/mach-omap2/pdata-quirks.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index c3b73351cb7a..ab94f3a87c32 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -254,6 +254,11 @@ static void __init omap4_panda_legacy_init(void)
{
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static void __init var_som_om44_legacy_init(void)
+{
+ legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 41);
+}
#endif
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
@@ -364,6 +369,8 @@ static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
{ "ti,omap4-sdp", omap4_sdp_legacy_init, },
{ "ti,omap4-panda", omap4_panda_legacy_init, },
+ { "variscite,var-dvk-om44", var_som_om44_legacy_init, },
+ { "variscite,var-stk-om44", var_som_om44_legacy_init, },
#endif
#ifdef CONFIG_SOC_AM33XX
{ "ti,am335x-evmsk", am335x_evmsk_legacy_init, },
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] Support for Variscite OM44 modules and boards
Hello, This patch set adds support for Variscite OM44 series of system on modules and boards. Changes v3: * Use new OMAP4_IOPAD macro * Add Tomi's Ack for patches with DSS DT nodes * Rebase on Tony's omap-for-v3.16/dt branch v2: * Use OMAP IOPAD macros Patch 1: Add support for the SoM itself and the reference carrier board. Together these make the VAR-STK-OM44 dev kit. Patch 2: Add support for VAR-DVK-OM44 which is just the STK with a LCD display. Patch 3: Nodes for WLAN/BT support. Patch 4: Add quirks so that WLAN can be used. Still waiting for proper DT bindings. Since this patch set uses the new OMAP4_IOPAD macro the follow patch must be applied: https://patchwork.kernel.org/patch/4160561/ Note that patch 1 and 2 relies upon the DSS panel and HDMI hpq DT patches from Tomi Valkeinen. See Tomi's 3.16/omap branch. The branch from Tomi mentioned above is destined for 3.16. Joachim Eastwood (4): ARM: dts: Add support for OMAP4 Variscite OM44 family ARM: dts: Add support for OMAP4 VAR-DVK-OM44 ARM: dts: Add VAR-SOM-OM44 WLAN nodes ARM: OMAP2+: Use pdata quirks for wl12xx on VAR-STK/DVK-OM44 .../devicetree/bindings/arm/omap/omap.txt | 6 + .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/omap4-var-dvk-om44.dts | 71 + arch/arm/boot/dts/omap4-var-om44customboard.dtsi | 235 ++ arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi | 68 arch/arm/boot/dts/omap4-var-som-om44.dtsi | 343 + arch/arm/boot/dts/omap4-var-som.dts| 96 -- arch/arm/boot/dts/omap4-var-stk-om44.dts | 17 + arch/arm/mach-omap2/pdata-quirks.c | 7 + 10 files changed, 750 insertions(+), 97 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-var-dvk-om44.dts create mode 100644 arch/arm/boot/dts/omap4-var-om44customboard.dtsi create mode 100644 arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi create mode 100644 arch/arm/boot/dts/omap4-var-som-om44.dtsi delete mode 100644 arch/arm/boot/dts/omap4-var-som.dts create mode 100644 arch/arm/boot/dts/omap4-var-stk-om44.dts -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Change IOPAD macro's for OMAP4/5
The OMAP4/5 TRMs primarily list address offsets from the padconf physical address (which is not driver base address) and not always the absolute physical address for padconf registers like some other OMAP TRMs. So create a new macro to use this offset and to avoid confusion between different OMAP parts. Signed-off-by: Joachim Eastwood --- include/dt-bindings/pinctrl/omap.h | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/include/dt-bindings/pinctrl/omap.h b/include/dt-bindings/pinctrl/omap.h index b04528cd033c..827e80964a35 100644 --- a/include/dt-bindings/pinctrl/omap.h +++ b/include/dt-bindings/pinctrl/omap.h @@ -62,12 +62,17 @@ #define OMAP3630_CORE2_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x25a0) (val) #define OMAP3_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2a00) (val) #define AM33XX_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) -#define OMAP4_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0040) (val) -#define OMAP4_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0xe040) (val) #define AM4372_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0800) (val) -#define OMAP5_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2840) (val) -#define OMAP5_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0xc840) (val) #define DRA7XX_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x3400) (val) +/* + * Macros to allow using the offset from the padconf physical address + * instead of the offset from padconf base. + */ +#define OMAP_PADCONF_OFFSET(offset, base_offset) ((offset) - (base_offset)) + +#define OMAP4_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) +#define OMAP5_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) + #endif -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP DSS: panel-dpi and enable gpios
Hello Tomi,
There seems to be a mismatch between your panel-dpi code and DT docs.
The docs state that enable-gpios is optinal but in panel-dpi.c you
have the following code
gpio = devm_gpiod_get(&pdev->dev, "enable");
if (IS_ERR(gpio)) {
dev_err(&pdev->dev, "failed to parse enable gpio\n");
return PTR_ERR(gpio);
} else {
gpiod_direction_output(gpio, 0);
ddata->enable_gpio = gpio;
}
Making probing fail on my DT since I don't use enable-gpios with
[ 0.976989] panel-dpi display.12: failed to parse enable gpio
[ 0.977050] panel-dpi: probe of display.12 failed with error -2
regards
Joachim Eastwood
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
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 signature.asc Description: Digital signature
Re: [PATCH v3 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
* Gupta, Pekon [140509 11:52]:
> >From: Tony Lindgren [mailto:t...@atomide.com]
> >
> >* Pekon Gupta [140422 00:34]:
> >> --- a/arch/arm/boot/dts/am335x-bone.dts
> >> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >> @@ -9,6 +9,7 @@
> >>
> >> #include "am33xx.dtsi"
> >> #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >> &ldo3_reg {
> >>regulator-min-microvolt = <180>;
> >> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> >> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> >> @@ -9,6 +9,7 @@
> >>
> >> #include "am33xx.dtsi"
> >> #include "am335x-bone-common.dtsi"
> >> +#include "am335x-bone-memory-cape.dts"
> >>
> >> &ldo3_reg {
> >>regulator-min-microvolt = <180>;
> >
> >Have you checked that including the capes unconditionally for
> >non-integrated devices is safe? Maybe decompile the dtb using
> >dtc and see what is in the produced dts file?
> >
> >I'm mostly worried about pinmux and GPMC as the pins can be used
> >by other capes and GPMC can have other devices.
> >
> I checked by de-compiling beaglebone.dtb with this patch included,
> where GPMC pinmux conflicts with eMMC (MMC2). It shows that
> both the pin-mux are present, and GPMC node is "disabled" by
> default, whereas the eMMC (MMC2) node.
> So I think this patch is safe pin-muxing wise.
> ---
> gpmc@5000 {
> ...
> status = "disabled";
> pinctrl-names = "default";
> pinctrl-0 = <0x38>;
> }
> mmc@481d8000 {
> ti,hwmods = "mmc2";
> ...
> status = "okay";
> pinctrl-0 = <0x2e>;
> bus-width = <0x8>;
> }
>
> pinmux_emmc_pins {
> pinctrl-single,pins = <0x80 0x32 0x84 0x32 0x0 0x31 0x4
> 0x31 0x8 0x31 0xc 0x31 0x10 0x31 0x14 0x31 0x18 0x31 0x1c 0x31>;
> linux,phandle = <0x2e>;
> phandle = <0x2e>;
> };
> nand_flash_x16 {
> pinctrl-single,pins = <0x0 0x28 0x4 0x28 0x8 0x28 0xc
> 0x28 0x10 0x28 0x14 0x28 0x18 0x28 0x1c 0x28 0x20 0x28 0x24 0x28 0x28 0x28
> 0x2c 0x28 0x30 0x28 0x34 0x28 0x38 0x28 0x3c 0x28 0x70 0x30 0x74 0x17 0x7c
> 0x10 0x90 0x8 0x94 0x8 0x98 0x8 0x9c 0x8>;
> linux,phandle = <0x38>;
> phandle = <0x38>;
> };
> --
OK makes sense as long as the pin names in .dtb are different
for the capes.
> >Also, this should probably also wait until u-boot has been
> >confirmed of being able to enable these devices?
> >
> Would be good if you accept this one, as this will act as reference for
> beaglebone cape users for pin-mux and other GPMC related bindings
What about other GPMC using capes? If we have another cape
that uses a separate GPMC partition we can't just set &gpmc
to status = "disabled" state.
Sorry, I can't merge this until all the issues are sorted out
and we have proven that the concept works by having u-boot
toggle the enabled status for the capes.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro
* Joachim Eastwood [140512 09:27]: > > So you are okey with just OMAP4_IOPAD for both core and wkup pads? Well if we ever wanted to add range checking, the macro would have to have size of the iopad range in it too. But that's probably out of the scope for these macros anyways and is already done by the driver. > If so I'll send out a patch with the stuff above for OMAP4 and 5. > > Then I'll update my patch set, rebase it on your omap-for-v3.16/dt > branch and post it the list. OK thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro
On 12 May 2014 18:16, Tony Lindgren wrote: > * Joachim Eastwood [140511 10:28]: >> On 9 May 2014 18:07, Tony Lindgren wrote: >> > >> > I was thinking that too initially, but then we would have macros that >> > behave >> > in a different way: >> > >> > 1. Calculate the iopad offset from the iopad register area start based on >> >the iopad physical address >> > >> > 2. Calculate the iopad offset from the iopad register area start based on >> >the iopadd offset from the driver base address >> > >> >> One other possibility is to use my original patch in this mail or just >> >> create a OMAP4_IOPAD with offset 0x040 which will on OMAP4 work for >> >> both core and wkup. >> > >> > That also makes the macro behave in a different way depending on the >> > SoC which is not nice. >> >> How about something like this then: >> /* >> * Macros to allow using the offset from the padconf physical address >> * instead of the offset from padconf base. >> */ >> #define OMAP_PADCONF_OFFSET(offset, base_offset) ((offset) - (base_offset)) >> >> #define OMAP4_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) >> #define OMAP5_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) >> >> The OMAP4/5 TRMs list address offsets from the padconf physical >> address (which is not driver base address) and not absolute physical >> address for padconf registers like some other OMAP TRMs. So create a >> new macro to avoid confusion between different OMAP parts. >> >> I can cook up a patch if you like the idea above. > > Sure sounds good to me. The offset is different for at least omap3 > instances, so those should use OMAP3_*_IOPAD macros. So you are okey with just OMAP4_IOPAD for both core and wkup pads? If so I'll send out a patch with the stuff above for OMAP4 and 5. Then I'll update my patch set, rebase it on your omap-for-v3.16/dt branch and post it the list. regards Joachim Eastwood -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro
* Joachim Eastwood [140511 10:28]: > On 9 May 2014 18:07, Tony Lindgren wrote: > > > > I was thinking that too initially, but then we would have macros that behave > > in a different way: > > > > 1. Calculate the iopad offset from the iopad register area start based on > >the iopad physical address > > > > 2. Calculate the iopad offset from the iopad register area start based on > >the iopadd offset from the driver base address > > > >> One other possibility is to use my original patch in this mail or just > >> create a OMAP4_IOPAD with offset 0x040 which will on OMAP4 work for > >> both core and wkup. > > > > That also makes the macro behave in a different way depending on the > > SoC which is not nice. > > How about something like this then: > /* > * Macros to allow using the offset from the padconf physical address > * instead of the offset from padconf base. > */ > #define OMAP_PADCONF_OFFSET(offset, base_offset) ((offset) - (base_offset)) > > #define OMAP4_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) > #define OMAP5_IOPAD(offset, val) OMAP_PADCONF_OFFSET((offset), 0x0040) (val) > > The OMAP4/5 TRMs list address offsets from the padconf physical > address (which is not driver base address) and not absolute physical > address for padconf registers like some other OMAP TRMs. So create a > new macro to avoid confusion between different OMAP parts. > > I can cook up a patch if you like the idea above. Sure sounds good to me. The offset is different for at least omap3 instances, so those should use OMAP3_*_IOPAD macros. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Pekon, A few questions regarding this patch, despite the fact I'm not sure it will ever be included. On 20 Mar 01:04 PM, Pekon Gupta wrote: > + 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/* > gpmc_wait0.gpmc_wait0 */ > + 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/* > gpmc_wpn.gpio0_30 */ Is this output pin? > + 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/* > gpmc_csn0.gpmc_csn0 */ Again: is this output pin? > + gpmc,wait-on-read = "true"; > + gpmc,wait-on-write = "true"; The devicetree binding says these wait properties are bool, so the above should be: gpmc,wait-on-read; gpmc,wait-on-write; But the problem is that there's no wait-pin defined, so this not enabled. Could you explain what should be the correct binding? This is very confusing for me. Thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP dts: Only build dtb if associated SoC is built
* Peter Robinson [140509 14:28]: > On Tue, May 6, 2014 at 6:18 PM, Tony Lindgren wrote: > > * Peter Robinson [140503 17:12]: > >> With ARCH_OMAP2PLUS being separated out into OMAP2/3/4/5 etc all the TI > >> device > >> tree blobs are built no matter the combination of SoCs that are enabled. > >> This > >> often causes a bunch of irrelevant .dts to be built on a multi platform > >> kernel, > >> this enables the building of just the ones relevant to the SoCs that are > >> actually enabled. It also orders the dts file alphabetically. > > > > Sure, makes sense and grouping + sorting also helps to avoid trivial > > merge conflicts. > > > > I've changed the ordering a bit as am335x is based on omap3, and > > omap43x based on omap4. And 3517 is an omap3 with the faster > > Ethernet and few other changes. > > Makes sense. > > > I'll apply the following patch into omap-for-v3.16/dt. BTW, looks > > like you missed a Signed-off-by in your original patch. > > Apologies, I was sure I added it but then I crafted the patch a couple > of times as it's my first first upstream kernel patch so I must have > missed it for the real one. Can I just ack it now with the below? If > so... No problem :) Would add it thanks.. > Signed-off-by: Peter Robinson ..but I had to apply it already already as I wanted to have it applied before other patches adding things to the Makefile. Having just my Signed-off-by should be just fine in this case as I had to edit the patch anyways, and it's just sorting the Makefile and not adding any new code. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP: OMAP5 & AM43x DSS
* Tomi Valkeinen [140512 07:58]: > On 12/05/14 17:36, Tony Lindgren wrote: > > * Tomi Valkeinen [140512 06:26]: > >> Hi Tony, > >> > >> On 09/05/14 14:56, Tomi Valkeinen wrote: > >>> Hi, > >>> > >>> Here are arch/arm/ patches to add display support for OMAP5 and AM43x. > >>> > >>> I have these in my tree, in a branch I will send to Tony for merging. > >>> Most of > >>> these patches have already been around the lists, but I wanted to send > >>> them one > >>> more time to verify that all looks right and everybody is fine with them. > >> > >> I have pushed these to: > >> > >> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.16/omap > >> > >> If you're fine with these, I think we can consider that branch stable. > >> There are probably still a few display related .dts changed for the > >> board coming up, but I'll add those on top of the current commits. > > > > Please coordinate things with Paul and Tero so you at least have proper > > acks for the hwmod and and clock patches. In general we really want to > > queue hwmod and clock changes separately as those can easily mess up things > > in a bad way like we've already seen with overlapping hwmod entries in > > the .dts files. > > Ok. I'm fine with splitting the series if that's easiest way to manage it. > > Paul, Tero? > > > Also, I'm wondering why we still have .clk and .opt_clks entries in the > > hwmod data for am43xx and omap5 which are both device tree based with > > all the clocks coming from .dts files? > > I think they are needed for the omap_device/hwmod stuff to work. Only > omapdss driver knows about the clocks defined in the .dts files, and the > omap_device/hwmod code still needs to do the reset and maybe some other > tasks that require the clocks. We're already populating the hwmod data from dts entries, that's done by omap_device_build_from_dt. Why aren't we doing that for dt defined clocks? I'd rather not start adding new data that will then just be removed, that's what people call "pointless extra churn". Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Felicitări
Felicitări Sunteți unul dintre beneficiarii de pe ordinea de zi a Națiunilor Unite 2014/2015 Grant Award. Informațiile dvs. au fost verificate și suma de șase milioane de euro (6.000.000,00) a fost acordat pentru a vă în programul de granturi al Națiunilor Unite ca Date tale au fost listate pe lista câștigătoare. Această sumă urmează a fi utilizate de dumneavoastră pentru orice scop, de care vor beneficia foloseste comunitatea ta. Informațiile de care avem nevoie pentru verificare sunt: Numele complet: adresa: Următor de Kin: Va oferi, de asemenea, un cont bancar care premiile de finanțare ar trebui să fie depus în. Veți avea nevoie, de asemenea, să plătească doar o taxă administrativă de 721 de euro (șapte sute douăzeci și unu de euro). Ajunge înapoi la noi cât mai curând posibil, astfel încât să puteți trimite certificatul câștigătoare. Biroul Organizației Națiunilor Unite. 2014/2015 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Rework OMAP4+ HDMI audio support
* Jyri Sarha [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/11] improve PWM lookup support without device tree
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 majord...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Hi,
* Pekon Gupta [140512 04:50]:
> +
> +&gpmc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_flash_x16>;
> + ranges = <0 0 0 0x0100>;/* CS0: min address-space configurable
> under GPMC chip-select = 16MB*/
> + nand@0,0 {
> + reg = <0 0 0x380>; /* CS0, offset=0x0, GPMC register-space
> size=0x380 */
Just a nitpick comment on the comments.. But as we've gotten them
wrong for almost every GPMC entry so far, we should fix it.
The "GPMC register-space" here can be a bit confusing still
as they are really the the device IO registers. I suggest we
standardize the comments like this for GPMC:
&gpmc {
pinctrl-names = "default";
pinctrl-0 = <&nand_flash_x16>;
ranges = <0 0 0 0x0100>;/* 16MB GPMC partition */
nand@0,0 {
reg = <0 0 0x380>; /* device IO registers */
...
};
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP: OMAP5 & AM43x DSS
On 12/05/14 17:36, Tony Lindgren wrote: > * Tomi Valkeinen [140512 06:26]: >> Hi Tony, >> >> On 09/05/14 14:56, Tomi Valkeinen wrote: >>> Hi, >>> >>> Here are arch/arm/ patches to add display support for OMAP5 and AM43x. >>> >>> I have these in my tree, in a branch I will send to Tony for merging. Most >>> of >>> these patches have already been around the lists, but I wanted to send them >>> one >>> more time to verify that all looks right and everybody is fine with them. >> >> I have pushed these to: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.16/omap >> >> If you're fine with these, I think we can consider that branch stable. >> There are probably still a few display related .dts changed for the >> board coming up, but I'll add those on top of the current commits. > > Please coordinate things with Paul and Tero so you at least have proper > acks for the hwmod and and clock patches. In general we really want to > queue hwmod and clock changes separately as those can easily mess up things > in a bad way like we've already seen with overlapping hwmod entries in > the .dts files. Ok. I'm fine with splitting the series if that's easiest way to manage it. Paul, Tero? > Also, I'm wondering why we still have .clk and .opt_clks entries in the > hwmod data for am43xx and omap5 which are both device tree based with > all the clocks coming from .dts files? I think they are needed for the omap_device/hwmod stuff to work. Only omapdss driver knows about the clocks defined in the .dts files, and the omap_device/hwmod code still needs to do the reset and maybe some other tasks that require the clocks. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On 12/05/14 17:39, Tony Lindgren wrote: > * Tomi Valkeinen [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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Andreas Müller [140512 01:20]: > On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren wrote: > > * Andreas Müller [140509 14:07]: > >> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tomi Valkeinen [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP: OMAP5 & AM43x DSS
* Tomi Valkeinen [140512 06:26]: > Hi Tony, > > On 09/05/14 14:56, Tomi Valkeinen wrote: > > Hi, > > > > Here are arch/arm/ patches to add display support for OMAP5 and AM43x. > > > > I have these in my tree, in a branch I will send to Tony for merging. Most > > of > > these patches have already been around the lists, but I wanted to send them > > one > > more time to verify that all looks right and everybody is fine with them. > > I have pushed these to: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.16/omap > > If you're fine with these, I think we can consider that branch stable. > There are probably still a few display related .dts changed for the > board coming up, but I'll add those on top of the current commits. Please coordinate things with Paul and Tero so you at least have proper acks for the hwmod and and clock patches. In general we really want to queue hwmod and clock changes separately as those can easily mess up things in a bad way like we've already seen with overlapping hwmod entries in the .dts files. Also, I'm wondering why we still have .clk and .opt_clks entries in the hwmod data for am43xx and omap5 which are both device tree based with all the clocks coming from .dts files? > I also have pushed OMAP5 and AM43xx related OMAPDSS patches to my > for-next branch, so with "3.16/omap" branch and linux-next, the omap5 > and am43xx displays should be functional. The panel parts look OK to me no problem. > How do you want to handle getting the 3.16/omap branch to linux-next? > Will you take "ownership" of the branch, and push it to linux-next? Ideally we'd have small topic branches of clock changes, hwmod changes and .dts changes that we can all merge in as needed. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Javier Martinez Canillas [140512 03:01]: > Hello Tomi, > > On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] usb: musb: Prevent musb_am335x from being removed
On 12 May 10:29 AM, George Cherian wrote: > On 5/8/2014 10:57 PM, Ezequiel Garcia wrote: > >At probe time, the musb_am335x driver registers its childs by > >calling of_platform_populate(), which registers all childs in > >the devicetree hierarchy recursively. > > > >On the other side, the driver's remove() function uses of_device_unregister() > >to remove each child in the musb_am335x driver device struct. > > > >However, when musb_dsps is loaded, its devices are attached to the > >musb_am335x > >driver device struct as musb_am335x childs. Hence, musb_am335x remove() > >will attempt to unregister the devices registered by musb_dsps, which > >produces > >a kernel panic. > > > >In other words, the childs in the "struct device" hierarchy are not the same > >as the childs in the "devicetree" hierarchy. > > > >Ideally, we should be enforcing the removal of the devices registered by > >musb_am335x *only*, instead of all the child devices. However, because of the > >recursive nature of of_platform_populate, this doesn't seem possible. > > > >Therefore, as the only solution at hand, this commit disables musb_am335x > >driver > >removal capability, preventing it from being ever removed. > > > >Just for reference, here's the panic upon module removal: > > > >musb-hdrc musb-hdrc.0.auto: remove, state 4 > >usb usb1: USB disconnect, device number 1 > >musb-hdrc musb-hdrc.0.auto: USB bus 1 deregistered > >Unable to handle kernel NULL pointer dereference at virtual address 008c > >pgd = de11c000 > >[008c] *pgd=9e174831, *pte=, *ppte= > >Internal error: Oops: 17 [#1] ARM > >Modules linked in: musb_am335x(-) musb_dsps musb_hdrc usbcore usb_common > >CPU: 0 PID: 623 Comm: modprobe Not tainted 3.15.0-rc4-1-g24efd13 #69 > >task: de1b7500 ti: de122000 task.ti: de122000 > >PC is at am335x_shutdown+0x10/0x28 > >LR is at am335x_shutdown+0xc/0x28 > >pc : []lr : []psr: a013 > >sp : de123df8 ip : 0004 fp : 00028f00 > >r10: r9 : de122000 r8 : c000e6c4 > >r7 : de0e3c10 r6 : de0e3800 r5 : de624010 r4 : de1ec750 > >r3 : de0e3810 r2 : r1 : 0001 r0 : > >Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > >Control: 10c5387d Table: 9e11c019 DAC: 0015 > >Process modprobe (pid: 623, stack limit = 0xde122240) > >Stack: (0xde123df8 to 0xde124000) > >3de0: de0e3810 bf054488 > >3e00: bf05444c de624010 6013 bf043650 12fc de624010 de0e3810 bf043a20 > >3e20: de0e3810 bf04b240 c0635b88 c02ca37c c02ca364 c02c8db0 de1b7500 de0e3844 > >3e40: de0e3810 c02c8e28 c0635b88 de02824c de0e3810 c02c884c de0e3800 de0e3810 > >3e60: de0e3818 c02c5b20 bf05417c de0e3800 de0e3800 c0635b88 de0f2410 c02ca838 > >3e80: bf05417c de0e3800 bf055438 c02ca8cc de0e3c10 bf054194 de0e3c10 c02ca37c > >3ea0: c02ca364 c02c8db0 de1b7500 de0e3c44 de0e3c10 c02c8e28 c0635b88 de02824c > >3ec0: de0e3c10 c02c884c de0e3c10 de0e3c10 de0e3c18 c02c5b20 de0e3c10 de0e3c10 > >3ee0: bf059000 a013 c02c5bc0 bf05900c de0e3c10 c02c5c48 > >3f00: de0dd0c0 de1ec970 de0f2410 bf05929c de0f2444 bf05902c de0f2410 c02ca37c > >3f20: c02ca364 c02c8db0 bf05929c de0f2410 bf05929c c02c94c8 bf05929c > >3f40: 0800 c02c8ab4 bf0592e0 c007fc40 c00dd820 6273756d 336d615f 00783533 > >3f60: c064a0ac de1b7500 de122000 de1b7500 c000e590 0001 c000e6c4 c0060160 > >3f80: 00028e70 00028e70 00028ea4 0081 6010 00028e70 00028e70 00028ea4 > >3fa0: 0081 c000e500 00028e70 00028e70 00028ea4 0800 becb59f8 00027608 > >3fc0: 00028e70 00028e70 00028ea4 0081 0001 0001 00028f00 > >3fe0: b6e6b6f0 becb59d4 000160e8 b6e6b6fc 6010 00028ea4 > >[] (am335x_shutdown) from [] (dsps_musb_exit+0x3c/0x4c > >[musb_dsps]) > >[] (dsps_musb_exit [musb_dsps]) from [] > >(musb_shutdown+0x80/0x90 [musb_hdrc]) > >[] (musb_shutdown [musb_hdrc]) from [] > >(musb_remove+0x24/0x68 [musb_hdrc]) > >[] (musb_remove [musb_hdrc]) from [] > >(platform_drv_remove+0x18/0x1c) > >[] (platform_drv_remove) from [] > >(__device_release_driver+0x70/0xc8) > >[] (__device_release_driver) from [] > >(device_release_driver+0x20/0x2c) > >[] (device_release_driver) from [] > >(bus_remove_device+0xdc/0x10c) > >[] (bus_remove_device) from [] (device_del+0x104/0x198) > >[] (device_del) from [] (platform_device_del+0x14/0x9c) > >[] (platform_device_del) from [] > >(platform_device_unregister+0xc/0x20) > >[] (platform_device_unregister) from [] > >(dsps_remove+0x18/0x38 [musb_dsps]) > >[] (dsps_remove [musb_dsps]) from [] > >(platform_drv_remove+0x18/0x1c) > >[] (platform_drv_remove) from [] > >(__device_release_driver+0x70/0xc8) > >[] (__device_release_driver) from [] > >(device_release_driver+0x20/0x2c) > >[] (device_release_driver) from [] > >(bus_remove_device+0xdc/0x10c) > >[] (bus_remove_device) from [] (device_del+0x104/0x198) > >[] (device_del) from [] (device_unregister+0xc/0x20) > >[] (device_unregist
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 12 May 10:29 AM, George Cherian wrote: > On 4/25/2014 2:41 AM, Ezequiel Garcia wrote: > >The DMA controller is needed for the USB controller to be correctly > >registered. Therefore, if the DMA node is located at the end an unecessary > >probe deferral is produced systematically. > > > >This is easily fixed by moving the node at the beggining of the child list, > >so it's probed first. > > > >Signed-off-by: Ezequiel Garcia > Acked-by: George Cherian Actually, I'm having second thoughts about this patch. I think it's really fragile to depend on the devicetree ordering. Instead, I've prepared a patch that forces the driver to probe the nodes in strict order, based in the compatible string. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] mmc: omap_hsmmc: use devm_clk_get
On 12 May 2014 15:33, Balaji T K wrote:
> On Monday 12 May 2014 02:03 PM, Ulf Hansson wrote:
>>
>> On 9 May 2014 18:46, Balaji T K wrote:
>>>
>>> With devm_clk_get conversion clk_put can be removed in clean up path
>>>
>>> Signed-off-by: Balaji T K
>>> ---
>>> drivers/mmc/host/omap_hsmmc.c | 15 ---
>>> 1 files changed, 4 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/omap_hsmmc.c
>>> b/drivers/mmc/host/omap_hsmmc.c
>>> index b4de63b..b8ae7ee 100644
>>> --- a/drivers/mmc/host/omap_hsmmc.c
>>> +++ b/drivers/mmc/host/omap_hsmmc.c
>>> @@ -1922,7 +1922,7 @@ static int omap_hsmmc_probe(struct platform_device
>>> *pdev)
>>>
>>> spin_lock_init(&host->irq_lock);
>>>
>>> - host->fclk = clk_get(&pdev->dev, "fck");
>>> + host->fclk = devm_clk_get(&pdev->dev, "fck");
>>> if (IS_ERR(host->fclk)) {
>>> ret = PTR_ERR(host->fclk);
>>> host->fclk = NULL;
>>> @@ -1941,7 +1941,7 @@ static int omap_hsmmc_probe(struct platform_device
>>> *pdev)
>>>
>>> omap_hsmmc_context_save(host);
>>>
>>> - host->dbclk = clk_get(&pdev->dev, "mmchsdb_fck");
>>> + host->dbclk = devm_clk_get(&pdev->dev, "mmchsdb_fck");
>>> /*
>>> * MMC can still work without debounce clock.
>>> */
>>> @@ -1949,7 +1949,6 @@ static int omap_hsmmc_probe(struct platform_device
>>> *pdev)
>>> host->dbclk = NULL;
>>> } else if (clk_prepare_enable(host->dbclk) != 0) {
>>> dev_warn(mmc_dev(host->mmc), "Failed to enable debounce
>>> clk\n");
>>> - clk_put(host->dbclk);
>>> host->dbclk = NULL;
>>
>>
>> You should use the IS_ERR macro, no need to reset dbclk to NULL.
>>
>
> Agreed, IS_ERR macro usage deserves patch on its own.
> will create separate patch on top of this series.
Or you just update this patch, since it would touch there very same
piece of code. :-)
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] mmc: omap_hsmmc: use devm_clk_get
On Monday 12 May 2014 02:03 PM, Ulf Hansson wrote:
On 9 May 2014 18:46, Balaji T K wrote:
With devm_clk_get conversion clk_put can be removed in clean up path
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b4de63b..b8ae7ee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1922,7 +1922,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
spin_lock_init(&host->irq_lock);
- host->fclk = clk_get(&pdev->dev, "fck");
+ host->fclk = devm_clk_get(&pdev->dev, "fck");
if (IS_ERR(host->fclk)) {
ret = PTR_ERR(host->fclk);
host->fclk = NULL;
@@ -1941,7 +1941,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_context_save(host);
- host->dbclk = clk_get(&pdev->dev, "mmchsdb_fck");
+ host->dbclk = devm_clk_get(&pdev->dev, "mmchsdb_fck");
/*
* MMC can still work without debounce clock.
*/
@@ -1949,7 +1949,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->dbclk = NULL;
} else if (clk_prepare_enable(host->dbclk) != 0) {
dev_warn(mmc_dev(host->mmc), "Failed to enable debounce
clk\n");
- clk_put(host->dbclk);
host->dbclk = NULL;
You should use the IS_ERR macro, no need to reset dbclk to NULL.
Agreed, IS_ERR macro usage deserves patch on its own.
will create separate patch on top of this series.
Thanks and Regards
Balaji T K
}
@@ -2105,11 +2104,8 @@ err_irq:
dma_release_channel(host->rx_chan);
pm_runtime_put_sync(host->dev);
pm_runtime_disable(host->dev);
- clk_put(host->fclk);
- if (host->dbclk) {
+ if (host->dbclk)
Use IS_ERR instead.
clk_disable_unprepare(host->dbclk);
- clk_put(host->dbclk);
- }
err1:
iounmap(host->base);
mmc_free_host(mmc);
@@ -2144,11 +2140,8 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
pm_runtime_put_sync(host->dev);
pm_runtime_disable(host->dev);
- clk_put(host->fclk);
- if (host->dbclk) {
+ if (host->dbclk)
Use IS_ERR instead.
clk_disable_unprepare(host->dbclk);
- clk_put(host->dbclk);
- }
omap_hsmmc_gpio_free(host->pdata);
iounmap(host->base);
--
1.7.5.4
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP: OMAP5 & AM43x DSS
Hi Tony, On 09/05/14 14:56, Tomi Valkeinen wrote: > Hi, > > Here are arch/arm/ patches to add display support for OMAP5 and AM43x. > > I have these in my tree, in a branch I will send to Tony for merging. Most of > these patches have already been around the lists, but I wanted to send them > one > more time to verify that all looks right and everybody is fine with them. I have pushed these to: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 3.16/omap If you're fine with these, I think we can consider that branch stable. There are probably still a few display related .dts changed for the board coming up, but I'll add those on top of the current commits. I also have pushed OMAP5 and AM43xx related OMAPDSS patches to my for-next branch, so with "3.16/omap" branch and linux-next, the omap5 and am43xx displays should be functional. How do you want to handle getting the 3.16/omap branch to linux-next? Will you take "ownership" of the branch, and push it to linux-next? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v5 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
Hello Pekon, On Mon, May 12, 2014 at 1:49 PM, Pekon Gupta wrote: > *changes v4 -> v5* > use lower-case hexadecimal numbers > add comments for using different memory sizes in and properties > fix 'reg size' property for GPMC and ELM nodes in dra7.dtsi > > > *changes v3 -> v4* > fixed and property for all GPMC DT nodes > added fix for am335x-evm and am437x-epos-evm > rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > +omap-for-v3.16/dt > > > *changes v2 -> v3* > rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > :master > merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series > > > *changes v1 -> v2* > [PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks > http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon > ' > http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren > ' > [PATCH v2 2/2] > > > *original v1* > This patch-set adds parallel NAND support on following TI platforms > - AM335x (am335x-bone LT, am335x-boneblack): > - AM43xx (am437x-gp-evm) > > > Minal Shah (1): > ARM: dts: dra7: add support for parallel NAND flash > > Pekon Gupta (3): > ARM: dts: am335x-bone: add support for beaglebone NAND cape > ARM: dts: am437x-gp-evm: add support for parallel NAND flash > ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition > > arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 > ++ > arch/arm/boot/dts/am335x-bone.dts | 1 + > arch/arm/boot/dts/am335x-boneblack.dts| 1 + > arch/arm/boot/dts/am437x-gp-evm.dts | 107 + > arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- > arch/arm/boot/dts/dra7-evm.dts| 117 +++ > arch/arm/boot/dts/dra7.dtsi | 20 > 7 files changed, 377 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts > Looks good to me. For the whole series: Reviewed-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
On 12/05/14 15:02, Tero Kristo wrote: > On 05/08/2014 12:06 PM, Tomi Valkeinen wrote: >> The current DPLL code does not try to round the clock rate, and instead >> returns an error if the requested clock rate cannot be produced exactly >> by the DPLL. >> >> It could be argued that this is a bug, but as the current drivers may >> depend on that behavior, a new flag 'ti,round-rate' is added which >> enables clock rate rounding. > > Someone could probably argue that this flag is not a hardware feature, I fully agree. > but instead is used to describe linux-kernel behavior, and would > probably be frowned upon by the DT enthusiasts. Othen than that, I like > this approach better than a global setting, but would like second > opinions here. I think the dpll code should always do rounding. That's what round_rate() is supposed to do, afaik. The current behavior of not rounding and returning an error is a bug in my opinion. So, if you ask me, the whole flag is just for the purpose of keeping the current drivers working, which could depend on the broken behavior. But I think we cannot have such drivers (functional, at least) in any case, as the clk-divider driver is broken and doesn't handle the errors the dpll code currently returns for non-exact rates. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] ARM: OMAP2+: fix dpll round_rate() to actually round
On 08/05/14 01:16, Paul Walmsley wrote: >> It's true that the original patch changes the dpll behavior when an >> exact match is not found. However, I think our drivers always request an >> exact match, and in that case the original patch doesn't change the >> behavior in practice. >> >> In theory it's possible that a driver requests a non-exact clock from >> the dpll, and when it gets an error, it does something else. > > The path that worries me at the moment is the set-rate path. That calls > __clk_round_rate() (if the user hasn't called it already) and silently > tries to set the clock to the altered rate. Hmm, so you mean a driver could call set_rate, and presume it only uses exact rates the dpll can produce, and presumes that set_rate returns an error if the dpll cannot produce the requested rate? Isn't that what I said? If a driver has such behavior, I think it still doesn't work, as (correct me if I'm wrong) we always have the clk-divider after a dpll. And the clk-divider doesn't handle the error, so neither can the driver. Or what kind of scenario do you have in mind? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
On 05/08/2014 12:06 PM, Tomi Valkeinen wrote:
The current DPLL code does not try to round the clock rate, and instead
returns an error if the requested clock rate cannot be produced exactly
by the DPLL.
It could be argued that this is a bug, but as the current drivers may
depend on that behavior, a new flag 'ti,round-rate' is added which
enables clock rate rounding.
Someone could probably argue that this flag is not a hardware feature,
but instead is used to describe linux-kernel behavior, and would
probably be frowned upon by the DT enthusiasts. Othen than that, I like
this approach better than a global setting, but would like second
opinions here.
-Tero
Signed-off-by: Tomi Valkeinen
---
Documentation/devicetree/bindings/clock/ti/dpll.txt | 2 ++
drivers/clk/ti/dpll.c | 3 +++
include/linux/clk/ti.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
index 30bfdb7c9f18..7912d876e858 100644
--- a/Documentation/devicetree/bindings/clock/ti/dpll.txt
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -48,6 +48,8 @@ Optional properties:
- ti,low-power-stop : DPLL supports low power stop mode, gating output
- ti,low-power-bypass : DPLL output matches rate of parent bypass clock
- ti,lock : DPLL locks in programmed rate
+- ti,round-rate : if not set, the dpll will return an error if asked for a
+ clock rate that it cannot produce exactly.
Examples:
dpll_core_ck: dpll_core_ck@44e00490 {
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7e498a44f97d..c5858c46b58c 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -265,6 +265,9 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (dpll_mode)
dd->modes = dpll_mode;
+ if (of_property_read_bool(node, "ti,round-rate"))
+ clk_hw->flags |= DPLL_USE_ROUNDED_RATE;
+
ti_clk_register_dpll(&clk_hw->hw, node);
return;
diff --git a/include/linux/clk/ti.h b/include/linux/clk/ti.h
index 4a21a872dbbd..79e8a7876457 100644
--- a/include/linux/clk/ti.h
+++ b/include/linux/clk/ti.h
@@ -155,6 +155,7 @@ struct clk_hw_omap {
#define INVERT_ENABLE (1 << 4) /* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2(1 << 5)
#define MEMMAP_ADDRESSING (1 << 6)
+#define DPLL_USE_ROUNDED_RATE (1 << 7) /* dpll's round_rate() returns
rounded rate */
/* CM_CLKEN_PLL*.EN* bit values - not all are available for every DPLL */
#define DPLL_LOW_POWER_STOP 0x1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Inquiry about your products,
Dear Sir/Madam, My name is Mr. Agyemang Kwesi. I am the Proprietor of Kwesi Global Limited. My office address is at NTHC Residential Area, Comm. 14, Tema, Ghana. I am doing import/export business since 1998 with my wife. We also represent some foreign companies in Ghana. We found posts about your company and products on the internet and we are pleased to inform you that we are interested in your products. Please send me your brochure, product catalog and pricing information. Also tell me your nearest sales office to Ghana. Kwesi Global Limited promotes itself as a turn-key solutions provider while providing our clients with the ability to the services they need. Business consulting is a broad term and many consulting firms fall short in their ability to facilitate a wide range of services. Kwesi Global Limited is different in that our seasoned core business development team utilizes confident interactions with a circle of available resource to meet client real needs. We hope for a positive response from you. Sincerely yours Mr. Agyemang Kwesi Kwesi Global Limited NTHC Residential Area, Comm. 14, Tema Ghana. Tel: +233 50-2596 304 Mobile: +233 545 485 124 1. Company Registration number CA-411 2. Company VAT number 524E002284 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition
MTD NAND partition for file-system should start at offset=0xA0
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index cf8bdf1..9f6a176 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -360,7 +360,7 @@
};
partition@9 {
label = "NAND.file-system";
- reg = <0x0080 0x1F60>;
+ reg = <0x00a0 0x1f60>;
};
};
};
--
1.8.5.1.163.gd7aced9
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] ARM: dts: am437x-gp-evm: add support for parallel NAND flash
Adds pinmux and DT node for Micron (MT29F4G08AB) x8 NAND device present on
am437x-gp-evm board.
(1) As NAND Flash data lines are muxed with eMMC, Thus at a given time either
eMMC or NAND can be enabled. Selection between eMMC and NAND is controlled:
(a) By dynamically driving following GPIO pin from software
SPI2_CS0(GPIO) == 0 NAND is selected (default)
SPI2_CS0(GPIO) == 1 eMMC is selected
(b) By statically using Jumper (J89) on the board
(2) As NAND device connnected to this board has page-size=4K and oob-size=224,
So ROM code expects boot-loaders to be flashed in BCH16 ECC scheme for
NAND boot.
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am437x-gp-evm.dts | 107
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 2e0c636..bd7ca86 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,6 +98,27 @@
0x264 (PIN_INPUT_PULLUP | MUX_MODE7) /*
spi2_d0.gpio3_22 */
>;
};
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins = <
+ 0x26C(PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
spi2_cs0.gpio/eMMCorNANDsel */
+ 0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0.gpmc_ad0 */
+ 0x4 (PIN_INPUT | MUX_MODE0) /* gpmc_ad1.gpmc_ad1 */
+ 0x8 (PIN_INPUT | MUX_MODE0) /* gpmc_ad2.gpmc_ad2 */
+ 0xc (PIN_INPUT | MUX_MODE0) /* gpmc_ad3.gpmc_ad3 */
+ 0x10 (PIN_INPUT | MUX_MODE0) /* gpmc_ad4.gpmc_ad4 */
+ 0x14 (PIN_INPUT | MUX_MODE0) /* gpmc_ad5.gpmc_ad5 */
+ 0x18 (PIN_INPUT | MUX_MODE0) /* gpmc_ad6.gpmc_ad6 */
+ 0x1c (PIN_INPUT | MUX_MODE0) /* gpmc_ad7.gpmc_ad7 */
+ 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_wpn.gpmc_wpn */
+ 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
+ 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
+ >;
+ };
};
&i2c0 {
@@ -174,3 +195,89 @@
dr_mode = "host";
status = "okay";
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x8>;
+ ranges = <0 0 0 0x0100>;/* CS0: min address-space configurable
under GPMC chip-select = 16MB */
+ nand@0,0 {
+ reg = <0 0 0x380>; /* CS0, offset=0, GPMC register-space
size=0x380 */
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <8>;
+ gpmc,device-width = <1>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <40>;
+ gpmc,cs-wr-off-ns = <40>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <25>;
+ gpmc,adv-wr-off-ns = <25>;
+ gpmc,we-on-ns = <0>;
+ gpmc,we-off-ns = <20>;
+ gpmc,oe-on-ns = <3>;
+ gpmc,oe-off-ns = <30>;
+ gpmc,access-ns = <30>;
+ gpmc,rd-cycle-ns = <40>;
+ gpmc,wr-cycle-ns = <40>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this is equal to size of erase-block */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "NAND.SPL";
+ reg = <0x 0x0004>;
+ };
+ partition@1 {
+ label = "NAND.SPL.backup1";
+ reg = <0x0004 0x0004>;
+ };
+ partition@2 {
+ label = "NAND.SPL.backup2";
+ reg = <0x0008 0x0004>;
+ };
+ partition@3 {
+
[PATCH v5 3/4] ARM: dts: dra7: add support for parallel NAND flash
From: Minal Shah
DRA7xx platform has in-build GPMC and ELM h/w engines which can be used
for accessing externel NAND flash device. This patch:
- adds generic DT binding in dra7.dtsi for enabling GPMC and ELM h/w engines
- adds DT binding for Micron NAND Flash (MT29F2G16AADWP) present on dra7-evm
*Important*
On DRA7 EVM, GPMC_WPN and NAND_BOOTn are controlled by DIP switch
So following board settings are required for NAND device detection:
SW5.9 (GPMC_WPN) = LOW
SW5.1 (NAND_BOOTn) = HIGH
Signed-off-by: Minal Shah
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/dra7-evm.dts | 117 +
arch/arm/boot/dts/dra7.dtsi| 20 +++
2 files changed, 137 insertions(+)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 5f1f6da..c86755d 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -108,6 +108,37 @@
0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /*
gpmc_cs3.qspi1_cs1 */
>;
};
+
+ nand_flash_x16: nand_flash_x16 {
+ /* On DRA7 EVM, GPMC_WPN and NAND_BOOTn comes from DIP switch
+* So NAND flash requires following switch settings:
+* SW5.9 (GPMC_WPN) = LOW
+* SW5.1 (NAND_BOOTn) = HIGH */
+ pinctrl-single,pins = <
+ 0x0 (PIN_INPUT | MUX_MODE0)/* gpmc_ad0
*/
+ 0x4 (PIN_INPUT | MUX_MODE0)/* gpmc_ad1
*/
+ 0x8 (PIN_INPUT | MUX_MODE0)/* gpmc_ad2
*/
+ 0xc (PIN_INPUT | MUX_MODE0)/* gpmc_ad3
*/
+ 0x10(PIN_INPUT | MUX_MODE0)/* gpmc_ad4
*/
+ 0x14(PIN_INPUT | MUX_MODE0)/* gpmc_ad5
*/
+ 0x18(PIN_INPUT | MUX_MODE0)/* gpmc_ad6
*/
+ 0x1c(PIN_INPUT | MUX_MODE0)/* gpmc_ad7
*/
+ 0x20(PIN_INPUT | MUX_MODE0)/* gpmc_ad8
*/
+ 0x24(PIN_INPUT | MUX_MODE0)/* gpmc_ad9
*/
+ 0x28(PIN_INPUT | MUX_MODE0)/* gpmc_ad10
*/
+ 0x2C(PIN_INPUT | MUX_MODE0)/* gpmc_ad11
*/
+ 0x30(PIN_INPUT | MUX_MODE0)/* gpmc_ad12
*/
+ 0x34(PIN_INPUT | MUX_MODE0)/* gpmc_ad13
*/
+ 0x38(PIN_INPUT | MUX_MODE0)/* gpmc_ad14
*/
+ 0x3C(PIN_INPUT | MUX_MODE0)/* gpmc_ad15
*/
+ 0xd8(PIN_INPUT_PULLUP | MUX_MODE0) /* gpmc_wait0
*/
+ 0xcc(PIN_OUTPUT | MUX_MODE0)/* gpmc_wen
*/
+ 0xb4(PIN_OUTPUT_PULLUP | MUX_MODE0) /* gpmc_csn0
*/
+ 0xc4(PIN_OUTPUT | MUX_MODE0)/*
gpmc_advn_ale */
+ 0xc8(PIN_OUTPUT | MUX_MODE0)/* gpmc_oen_ren
*/
+ 0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
+ >;
+ };
};
&i2c1 {
@@ -353,3 +384,89 @@
};
};
};
+
+&elm {
+ status = "okay";
+};
+
+&gpmc {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_flash_x16>;
+ ranges = <0 0 0 0x0100>; /* CS0: min. address-space configurable
under GPMC chip-select = 16MB */
+ nand@0,0 {
+ reg = <0 0 0x380>; /* CS0, offet=0x0, GPMC register-space
size=0x380 */
+ ti,nand-ecc-opt = "bch8";
+ ti,elm-id = <&elm>;
+ nand-bus-width = <16>;
+ gpmc,device-width = <2>;
+ gpmc,sync-clk-ps = <0>;
+ gpmc,cs-on-ns = <0>;
+ gpmc,cs-rd-off-ns = <40>;
+ gpmc,cs-wr-off-ns = <40>;
+ gpmc,adv-on-ns = <0>;
+ gpmc,adv-rd-off-ns = <30>;
+ gpmc,adv-wr-off-ns = <30>;
+ gpmc,we-on-ns = <5>;
+ gpmc,we-off-ns = <25>;
+ gpmc,oe-on-ns = <2>;
+ gpmc,oe-off-ns = <20>;
+ gpmc,access-ns = <20>;
+ gpmc,wr-access-ns = <40>;
+ gpmc,rd-cycle-ns = <40>;
+ gpmc,wr-cycle-ns = <40>;
+ gpmc,wait-on-read = "true";
+ gpmc,wait-on-write = "true";
+ gpmc,bus-turnaround-ns = <0>;
+ gpmc,cycle2cycle-delay-ns = <0>;
+ gpmc,clk-activation-ns = <0>;
+ gpmc,wait-monitoring-ns = <0>;
+ gpmc,wr-data-mux-bus-ns = <0>;
+ /* MTD partition table */
+ /* All SPL-* partitions are sized to minimal length
+* which can be independently programmable. For
+* NAND flash this i
[PATCH v5 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
Beaglebone Board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for
following versions of Beaglebone(AM335x) NAND capes
(a) NAND Device with bus-width=16, block-size=128k, page-size=2k, oob-size=64
(b) NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224
Further information and datasheets can be found at [1] and [2]
* How to boot from NAND using Memory Expander + NAND Cape ? *
- Important: As BOOTSEL values are sampled only at POR, so after changing any
setting on SW2 (DIP switch), disconnect and reconnect all board power supply
(including mini-USB console port) to POR the beaglebone.
- Selection of ECC scheme
for NAND cape(a), ROM code expects BCH8_HW ecc-scheme
for NAND cape(b), ROM code expects BCH16_HW ecc-scheme
- Selection of boot modes can be controlled via DIP switch(SW2) present on
Memory Expander cape, so first boot via MMC or other sources to flash NAND
device and then switch to SW2[SWITCH_BOOT]=ON to boot from NAND Cape.
SW2[SWITCH_BOOT] == OFF follow default boot order MMC-> SPI -> UART -> USB
SW2[SWITCH_BOOT] == ON boot mode selected via DIP switch(SW2)
- For NAND boot following switch settings need to be followed
SW2[ 0] = ON (SYSBOOT[ 0]==0: NAND boot mode selected )
SW2[ 1] = ON (SYSBOOT[ 1]==0: -- do -- )
SW2[ 2] = OFF (SYSBOOT[ 2]==1: -- do -- )
SW2[ 3] = OFF (SYSBOOT[ 3]==1: -- do -- )
SW2[ 4] = ON (SYSBOOT[ 4]==0: -- do -- )
SW2[ 8] = OFF (SYSBOOT[ 8]==1: 0:x8 device, 1:x16 device )
SW2[ 9] = ON (SYSBOOT[ 9]==0: ECC done by ROM )
SW2[10] = ON (SYSBOOT[10]==0: Non Muxed device )
SW2[11] = ON (SYSBOOT[11]==0:-- do -- )
[1] http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
[2]
http://beagleboardtoys.info/index.php?title=BeagleBone_4Gb_16-Bit_NAND_Module
Signed-off-by: Pekon Gupta
---
arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 ++
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts| 1 +
3 files changed, 132 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts
diff --git a/arch/arm/boot/dts/am335x-bone-memory-cape.dts
b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
new file mode 100644
index 000..d6cb9ff
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-memory-cape.dts
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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 DTS adds supports for capes using GPMC interface to connect external
+ * memory like NAND, NOR Flash to Beaglebone-LT (white) and Beaglebone-Black.
+ */
+
+
+&am33xx_pinmux {
+ nand_flash_x16: nand_flash_x16 {
+ pinctrl-single,pins = <
+ 0x00 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad0.gpmc_ad0 */
+ 0x04 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad1.gpmc_ad1 */
+ 0x08 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad2.gpmc_ad2 */
+ 0x0c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad3.gpmc_ad3 */
+ 0x10 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad4.gpmc_ad4 */
+ 0x14 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad5.gpmc_ad5 */
+ 0x18 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad6.gpmc_ad6 */
+ 0x1c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad7.gpmc_ad7 */
+ 0x20 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad8.gpmc_ad8 */
+ 0x24 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad9.gpmc_ad9 */
+ 0x28 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad10.gpmc_ad10
*/
+ 0x2c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad11.gpmc_ad11
*/
+ 0x30 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad12.gpmc_ad12
*/
+ 0x34 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad13.gpmc_ad13
*/
+ 0x38 (MUX_MODE0 | PIN_INPUT)/* gpmc_ad14.gpmc_ad14
*/
+ 0x3c (MUX_MODE0 | PIN_INPUT)/* gpmc_ad15.gpmc_ad15
*/
+ 0x70 (MUX_MODE0 | PIN_INPUT_PULLUP )/*
gpmc_wait0.gpmc_wait0 */
+ 0x74 (MUX_MODE7 | PIN_OUTPUT_PULLUP)/*
gpmc_wpn.gpio0_30 */
+ 0x7c (MUX_MODE0 | PIN_OUTPUT_PULLUP)/*
gpmc_csn0.gpmc_csn0 */
+ 0x90 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_advn_ale.gpmc_advn_ale */
+ 0x94 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_oen_ren.gpmc_oen_ren */
+ 0x98 (MUX_MODE0 | PIN_OUTPUT) /*
gpmc_wen.gpmc_wen */
+ 0x9c (MUX_MODE0 | PIN_OUTPUT)
[PATCH v5 0/4] add parallel NAND support for TI's new OMAPx and AMxx platforms (Part-2)
*changes v4 -> v5* use lower-case hexadecimal numbers add comments for using different memory sizes in and properties fix 'reg size' property for GPMC and ELM nodes in dra7.dtsi *changes v3 -> v4* fixed and property for all GPMC DT nodes added fix for am335x-evm and am437x-epos-evm rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap +omap-for-v3.16/dt *changes v2 -> v3* rebased on git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap :master merged leftover patches (dra7-evm and am43x-epos-evm fix) from Part-1 series *changes v1 -> v2* [PATCH v2 1/2] created new DTS for memory-capes based on following feedbacks http://www.spinics.net/lists/linux-omap/msg104348.html from 'Nishanth Menon ' http://www.spinics.net/lists/linux-omap/msg104447.html from 'Tony Lindgren ' [PATCH v2 2/2] *original v1* This patch-set adds parallel NAND support on following TI platforms - AM335x (am335x-bone LT, am335x-boneblack): - AM43xx (am437x-gp-evm) Minal Shah (1): ARM: dts: dra7: add support for parallel NAND flash Pekon Gupta (3): ARM: dts: am335x-bone: add support for beaglebone NAND cape ARM: dts: am437x-gp-evm: add support for parallel NAND flash ARM: dts: am43xx: fix starting offset of NAND.filesystem MTD partition arch/arm/boot/dts/am335x-bone-memory-cape.dts | 130 ++ arch/arm/boot/dts/am335x-bone.dts | 1 + arch/arm/boot/dts/am335x-boneblack.dts| 1 + arch/arm/boot/dts/am437x-gp-evm.dts | 107 + arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- arch/arm/boot/dts/dra7-evm.dts| 117 +++ arch/arm/boot/dts/dra7.dtsi | 20 7 files changed, 377 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/am335x-bone-memory-cape.dts -- 1.8.5.1.163.gd7aced9 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On 09/05/14 17:37, Tony Lindgren wrote: > * Tomi Valkeinen [140509 01:02]: >> On 09/05/14 02:20, Tony Lindgren wrote: >>> * Tony Lindgren [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: 10800 != 11520 >>> [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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On 09/05/14 17:37, Tony Lindgren wrote: > * Tomi Valkeinen [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) = 5760 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 5760 > - LCD - > LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 5760lck div 1 > pck 1920pck 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) = 10800 > - DISPC - > dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK) > fck 10800 > - LCD - > LCD clk source = DSS_FCK (DSS1_ALWON_FCLK) > lck 10800 lck div 1 > pck 1800pck 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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Hello Tomi, On Mon, May 12, 2014 at 11:40 AM, Tomi Valkeinen 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
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 signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Hello Tomi,
On Mon, May 12, 2014 at 9:38 AM, Tomi Valkeinen 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 QVGAomapfb.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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/19] ARM: omap2plus_defconfig: Enable OMAP5 HDMI support
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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/19] OMAPDSS: hdmi4: Integrated ASoC DAI component driver implementation
Integrate ASoC DAI component driver in to the OMAP4 hdmi driver. The
patch also updates the relevant entry in ti,omap4-dss DT binding
document.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/video/ti,omap4-dss.txt |4 +
drivers/video/fbdev/omap2/dss/hdmi4.c | 199
2 files changed, 203 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
index b8c29fb..b059640 100644
--- a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -107,6 +107,10 @@ Required properties:
- clocks: handles to fclk and pll clock
- clock-names: "fck", "sys_clk"
+Required properties if hdmi audio support is enabled:
+- dmas: DMA controller phandle for HDMI audio output
+- dma-names: "audio_tx"
+
Optional nodes:
- Video port for HDMI output
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 71f9175..dbdb3ed 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -34,6 +34,16 @@
#include
#include
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#endif
+
#include "hdmi4_core.h"
#include "dss.h"
#include "dss_features.h"
@@ -52,6 +62,13 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_hdmi_dac_reg;
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+ struct snd_dmaengine_dai_dma_data dma_data;
+ struct omap_dss_audio dss_audio;
+ struct snd_aes_iec958 iec;
+ struct snd_cea_861_aud_if cea;
+#endif
+
bool core_enabled;
struct omap_dss_device output;
@@ -509,6 +526,182 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+static int hdmi_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ int ret;
+ /*
+* Make sure that the period bytes are multiple of the DMA packet size.
+* Largest packet size we use is 32 32-bit words = 128 bytes
+*/
+ ret = snd_pcm_hw_constraint_step(substream->runtime, 0,
+SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128);
+ if (ret < 0) {
+ dev_err(dai->dev, "could not apply constraint\n");
+ return ret;
+ }
+
+ mutex_lock(&hdmi.lock);
+ ret = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
+ mutex_unlock(&hdmi.lock);
+ if (!ret) {
+ dev_err(dai->dev, "audio not supported\n");
+ return -ENODEV;
+ }
+
+ snd_soc_dai_set_dma_data(dai, substream, &hdmi.dma_data);
+
+ return 0;
+}
+
+static int hdmi_dai_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ int r;
+
+ mutex_lock(&hdmi.lock);
+
+ if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
+ r = -EPERM;
+ goto err;
+ }
+
+ r = hdmi_wp_audio_enable(&hdmi.wp, true);
+
+err:
+ mutex_unlock(&hdmi.lock);
+ return r;
+}
+
+static int hdmi_dai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ int err;
+
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ hdmi.dma_data.maxburst = 16;
+ break;
+ case SNDRV_PCM_FORMAT_S24_LE:
+ hdmi.dma_data.maxburst = 32;
+ break;
+ default:
+ dev_err(dai->dev, "format not supported!\n");
+ return -EINVAL;
+ }
+
+ hdmi.dss_audio.iec = &hdmi.iec;
+ hdmi.dss_audio.cea = &hdmi.cea;
+ err = hdmi_dss_audio_from_hw_params(params, &hdmi.dss_audio, dai);
+ if (err)
+ return err;
+
+ mutex_lock(&hdmi.lock);
+
+ if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
+ err = -EPERM;
+ goto err;
+ }
+
+ err = hdmi4_audio_config(&hdmi.core, &hdmi.wp, &hdmi.dss_audio,
+hdmi.cfg.timings.pixelclock);
+err:
+ mutex_unlock(&hdmi.lock);
+ return err;
+}
+
+static int hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ int err = 0;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ err = hdmi4_audio_start(&hdmi.core, &hdmi.wp);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ hdmi4_audio_stop(&hdmi.core, &hdmi.wp);
+ break;
+
[PATCH 03/19] OMAPDSS: hdmi4: Remove callbacks for an external ASoC DAI driver
Removes the OMAP4 HDMI audio callbacks for an external audio driver and
the old external DAI driver does not work anymore after this patch.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi4.c | 113 -
1 file changed, 113 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi4.c
b/drivers/video/fbdev/omap2/dss/hdmi4.c
index 626aad2..71f9175 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi4.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi4.c
@@ -509,112 +509,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- mutex_lock(&hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi_wp_audio_enable(&hdmi.wp, true);
- if (r)
- goto err;
-
- mutex_unlock(&hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(&hdmi.lock);
- return r;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
- hdmi_wp_audio_enable(&hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return hdmi4_audio_start(&hdmi.core, &hdmi.wp);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
- hdmi4_audio_stop(&hdmi.core, &hdmi.wp);
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- bool r;
-
- mutex_lock(&hdmi.lock);
-
- r = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
-
- mutex_unlock(&hdmi.lock);
- return r;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- int r;
- u32 pclk = hdmi.cfg.timings.pixelclock;
-
- mutex_lock(&hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi4_audio_config(&hdmi.core, &hdmi.wp, audio, pclk);
- if (r)
- goto err;
-
- mutex_unlock(&hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(&hdmi.lock);
- return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- return false;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- return -EPERM;
-}
-#endif
-
static const struct omapdss_hdmi_ops hdmi_ops = {
.connect= hdmi_connect,
.disconnect = hdmi_disconnect,
@@ -627,13 +521,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
.get_timings= hdmi_display_get_timings,
.read_edid = hdmi_read_edid,
-
- .audio_enable = hdmi_audio_enable,
- .audio_disable = hdmi_audio_disable,
- .audio_start= hdmi_audio_start,
- .audio_stop = hdmi_audio_stop,
- .audio_supported= hdmi_audio_supported,
- .audio_config = hdmi_audio_config,
};
static void hdmi_init_output(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/19] ASoC: omap: Remove obsolete HDMI audio code and Kconfig options
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.
Signed-off-by: Jyri Sarha
---
sound/soc/omap/Kconfig | 13 --
sound/soc/omap/Makefile |4 -
sound/soc/omap/omap-hdmi-card.c | 87 --
sound/soc/omap/omap-hdmi.c | 364 ---
sound/soc/omap/omap-hdmi.h | 38
5 files changed, 506 deletions(-)
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
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index e006593..aecd8eb 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -12,9 +12,6 @@ config SND_OMAP_SOC_MCBSP
config SND_OMAP_SOC_MCPDM
tristate
-config SND_OMAP_SOC_HDMI
- tristate
-
config SND_OMAP_SOC_N810
tristate "SoC Audio support for Nokia N810"
depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C
@@ -100,16 +97,6 @@ config SND_OMAP_SOC_OMAP_ABE_TWL6040
- PandaBoard (4430)
- PandaBoardES (4460)
-config SND_OMAP_SOC_OMAP_HDMI
- tristate "SoC Audio support for Texas Instruments OMAP HDMI"
- depends on SND_OMAP_SOC && OMAP4_DSS_HDMI && OMAP2_DSS
- select SND_OMAP_SOC_HDMI
- select SND_SOC_HDMI_CODEC
- select OMAP4_DSS_HDMI_AUDIO
- help
- Say Y if you want to add support for SoC HDMI audio on Texas
Instruments
- OMAP4 chips
-
config SND_OMAP_SOC_OMAP3_PANDORA
tristate "SoC Audio support for OMAP3 Pandora"
depends on TWL4030_CORE && SND_OMAP_SOC && MACH_OMAP3_PANDORA
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index a725905..5832fe1 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -3,13 +3,11 @@ snd-soc-omap-objs := omap-pcm.o
snd-soc-omap-dmic-objs := omap-dmic.o
snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
snd-soc-omap-mcpdm-objs := omap-mcpdm.o
-snd-soc-omap-hdmi-objs := omap-hdmi.o
obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
-obj-$(CONFIG_SND_OMAP_SOC_HDMI) += snd-soc-omap-hdmi.o
# OMAP Machine Support
snd-soc-n810-objs := n810.o
@@ -20,7 +18,6 @@ snd-soc-am3517evm-objs := am3517evm.o
snd-soc-omap-abe-twl6040-objs := omap-abe-twl6040.o
snd-soc-omap-twl4030-objs := omap-twl4030.o
snd-soc-omap3pandora-objs := omap3pandora.o
-snd-soc-omap-hdmi-card-objs := omap-hdmi-card.o
obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o
obj-$(CONFIG_SND_OMAP_SOC_RX51) += snd-soc-rx51.o
@@ -30,4 +27,3 @@ obj-$(CONFIG_SND_OMAP_SOC_AM3517EVM) += snd-soc-am3517evm.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040) += snd-soc-omap-abe-twl6040.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP_TWL4030) += snd-soc-omap-twl4030.o
obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o
-obj-$(CONFIG_SND_OMAP_SOC_OMAP_HDMI) += snd-soc-omap-hdmi-card.o
diff --git a/sound/soc/omap/omap-hdmi-card.c b/sound/soc/omap/omap-hdmi-card.c
deleted file mode 100644
index f649fe8..000
--- a/sound/soc/omap/omap-hdmi-card.c
+++ /dev/null
@@ -1,87 +0,0 @@
-/*
- * omap-hdmi-card.c
- *
- * OMAP ALSA SoC machine driver for TI OMAP HDMI
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
- * Author: Ricardo Neri
- *
- * 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, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-
-#define DRV_NAME "omap-hdmi-audio"
-
-static struct snd_soc_dai_link omap_hdmi_dai = {
- .name = "HDMI",
- .stream_name = "HDMI",
- .cpu_dai_name = "omap-hdmi-audio-dai",
- .platform_name = "omap-hdmi-audio-dai",
- .codec_name = "hdmi-audio-codec",
- .codec_dai_name = "hdmi-hifi",
-};
-
-static struct snd_soc_card snd_soc_omap_hdmi = {
- .name = "OMAPHDMI",
- .owner = THIS_MODULE,
- .dai_link = &omap_hdmi_dai,
- .num_links = 1,
-};
-
-static int omap_hdmi_probe(struct platform_device *pdev)
-{
- struct snd_soc_card *card = &snd_soc_omap_hdmi;
- int ret;
-
- card->dev = &pdev->dev;
-
-
[PATCH 12/19] OMAPDSS: Remove obsolete audio code
Removes all code related to external audio driver callbacks. There is
no need for those now that sound/soc/omap/omap-hdmi.c is removed.
Signed-off-by: Jyri Sarha
---
.../fbdev/omap2/displays-new/connector-hdmi.c | 99
.../fbdev/omap2/displays-new/encoder-tpd12s015.c | 56 ---
include/video/omapdss.h| 31 --
3 files changed, 186 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 4420ccb..aa8231a 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
@@ -170,98 +170,6 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
return in->ops.hdmi->detect(in);
}
-static int hdmic_audio_enable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
- int r;
-
- /* enable audio only if the display is active */
- if (!omapdss_device_is_enabled(dssdev))
- return -EPERM;
-
- r = in->ops.hdmi->audio_enable(in);
- if (r)
- return r;
-
- dssdev->audio_state = OMAP_DSS_AUDIO_ENABLED;
-
- return 0;
-}
-
-static void hdmic_audio_disable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
-
- in->ops.hdmi->audio_disable(in);
-
- dssdev->audio_state = OMAP_DSS_AUDIO_DISABLED;
-}
-
-static int hdmic_audio_start(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
- int r;
-
- /*
-* No need to check the panel state. It was checked when trasitioning
-* to AUDIO_ENABLED.
-*/
- if (dssdev->audio_state != OMAP_DSS_AUDIO_ENABLED)
- return -EPERM;
-
- r = in->ops.hdmi->audio_start(in);
- if (r)
- return r;
-
- dssdev->audio_state = OMAP_DSS_AUDIO_PLAYING;
-
- return 0;
-}
-
-static void hdmic_audio_stop(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
-
- in->ops.hdmi->audio_stop(in);
-
- dssdev->audio_state = OMAP_DSS_AUDIO_ENABLED;
-}
-
-static bool hdmic_audio_supported(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
-
- if (!omapdss_device_is_enabled(dssdev))
- return false;
-
- return in->ops.hdmi->audio_supported(in);
-}
-
-static int hdmic_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
- int r;
-
- /* config audio only if the display is active */
- if (!omapdss_device_is_enabled(dssdev))
- return -EPERM;
-
- r = in->ops.hdmi->audio_config(in, audio);
- if (r)
- return r;
-
- dssdev->audio_state = OMAP_DSS_AUDIO_CONFIGURED;
-
- return 0;
-}
-
static struct omap_dss_driver hdmic_driver = {
.connect= hdmic_connect,
.disconnect = hdmic_disconnect,
@@ -277,13 +185,6 @@ static struct omap_dss_driver hdmic_driver = {
.read_edid = hdmic_read_edid,
.detect = hdmic_detect,
-
- .audio_enable = hdmic_audio_enable,
- .audio_disable = hdmic_audio_disable,
- .audio_start= hdmic_audio_start,
- .audio_stop = hdmic_audio_stop,
- .audio_supported= hdmic_audio_supported,
- .audio_config = hdmic_audio_config,
};
static int hdmic_probe_pdata(struct platform_device *pdev)
diff --git a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
index 7e33686..d47e30f 100644
--- a/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/fbdev/omap2/displays-new/encoder-tpd12s015.c
@@ -193,55 +193,6 @@ static bool tpd_detect(struct omap_dss_device *dssdev)
return gpio_get_value_cansleep(ddata->hpd_gpio);
}
-static int tpd_audio_enable(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->audio_enable(in);
-}
-
-static void tpd_audio_disable(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
- struct omap_dss_device *in = ddata->in;
-
- in->ops.hdmi->audio_disable(in);
-}
-
-static int tpd_audio_start(struct omap_dss_device *dssdev)
-{
-
[PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/Kconfig | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index 8921a7a..ecc2f50 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI HDMI support for OMAP4 based SoCs. config OMAP4_DSS_HDMI_AUDIO - bool + bool "HDMI audio support for OMAP4" + depends on OMAP4_DSS_HDMI + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP4 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. config OMAP5_DSS_HDMI bool "HDMI support for OMAP5" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/19] ARM: omap5.dtsi: Add audio related parameters to hdmi node
Adds HDMI audio sDMA properties. Signed-off-by: Jyri Sarha --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/19] ARM: omap5-uevm.dts: Add hdmi audio related nodes
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
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/19] ARM: omap2plus_defconfig: Enable OMAP4+ HDMI audio support
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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/19] ASoC: omap-pcm: Move omap-pcm under include/sound
Make including the omap-pcm.h outside sound/soc/omap more convenient.
Signed-off-by: Jyri Sarha
---
include/sound/omap-pcm.h | 30 ++
sound/soc/davinci/davinci-mcasp.c |2 +-
sound/soc/omap/omap-dmic.c|2 +-
sound/soc/omap/omap-hdmi.c|2 +-
sound/soc/omap/omap-mcbsp.c |2 +-
sound/soc/omap/omap-mcpdm.c |2 +-
sound/soc/omap/omap-pcm.h | 30 --
7 files changed, 35 insertions(+), 35 deletions(-)
create mode 100644 include/sound/omap-pcm.h
delete mode 100644 sound/soc/omap/omap-pcm.h
diff --git a/include/sound/omap-pcm.h b/include/sound/omap-pcm.h
new file mode 100644
index 000..c1d2f31
--- /dev/null
+++ b/include/sound/omap-pcm.h
@@ -0,0 +1,30 @@
+/*
+ * omap-pcm.h - OMAP PCM driver
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc.
+ *
+ * Author: Peter Ujfalusi
+ *
+ * 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.
+ */
+
+#ifndef __OMAP_PCM_H__
+#define __OMAP_PCM_H__
+
+#if IS_ENABLED(CONFIG_SND_OMAP_SOC)
+int omap_pcm_platform_register(struct device *dev);
+#else
+static inline int omap_pcm_platform_register(struct device *dev)
+{
+ return 0;
+}
+#endif /* CONFIG_SND_OMAP_SOC */
+
+#endif /* __OMAP_PCM_H__ */
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 14058dc..9afb146 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -33,10 +33,10 @@
#include
#include
#include
+#include
#include "davinci-pcm.h"
#include "davinci-mcasp.h"
-#include "../omap/omap-pcm.h"
#define MCASP_MAX_AFIFO_DEPTH 64
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 53da041..6925d71 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -40,9 +40,9 @@
#include
#include
#include
+#include
#include "omap-dmic.h"
-#include "omap-pcm.h"
struct omap_dmic {
struct device *dev;
diff --git a/sound/soc/omap/omap-hdmi.c b/sound/soc/omap/omap-hdmi.c
index 537a1ec..eb9c392 100644
--- a/sound/soc/omap/omap-hdmi.c
+++ b/sound/soc/omap/omap-hdmi.c
@@ -34,9 +34,9 @@
#include
#include
#include
+#include
#include "omap-hdmi.h"
-#include "omap-pcm.h"
#define DRV_NAME "omap-hdmi-audio-dai"
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index af2764a..10d6cec 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -34,11 +34,11 @@
#include
#include
#include
+#include
#include
#include "mcbsp.h"
#include "omap-mcbsp.h"
-#include "omap-pcm.h"
#define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_96000)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index d8ebb52..f0e2ebe 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -40,9 +40,9 @@
#include
#include
#include
+#include
#include "omap-mcpdm.h"
-#include "omap-pcm.h"
struct mcpdm_link_config {
u32 link_mask; /* channel mask for the direction */
diff --git a/sound/soc/omap/omap-pcm.h b/sound/soc/omap/omap-pcm.h
deleted file mode 100644
index c1d2f31..000
--- a/sound/soc/omap/omap-pcm.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * omap-pcm.h - OMAP PCM driver
- *
- * Copyright (C) 2014 Texas Instruments, Inc.
- *
- * Author: Peter Ujfalusi
- *
- * 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.
- */
-
-#ifndef __OMAP_PCM_H__
-#define __OMAP_PCM_H__
-
-#if IS_ENABLED(CONFIG_SND_OMAP_SOC)
-int omap_pcm_platform_register(struct device *dev);
-#else
-static inline int omap_pcm_platform_register(struct device *dev)
-{
- return 0;
-}
-#endif /* CONFIG_SND_OMAP_SOC */
-
-#endif /* __OMAP_PCM_H__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/19] OMAPDSS: hdmi-common: Add hdmi_dss_audio_from_hw_params()
Add common function for struct omap_dss_audio initialization from
struct snd_pcm_hw_params.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi.h|5 ++
drivers/video/fbdev/omap2/dss/hdmi_common.c | 117 ++-
2 files changed, 121 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index fbee078..65bf072 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -433,6 +433,11 @@ int hdmi_parse_lanes_of(struct platform_device *pdev,
struct device_node *ep,
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) ||
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts);
+struct snd_pcm_hw_params;
+struct snd_soc_dai;
+int hdmi_dss_audio_from_hw_params(struct snd_pcm_hw_params *params,
+ struct omap_dss_audio *dss_audio,
+ struct snd_soc_dai *dai);
int hdmi_wp_audio_enable(struct hdmi_wp_data *wp, bool enable);
int hdmi_wp_audio_core_req_enable(struct hdmi_wp_data *wp, bool enable);
void hdmi_wp_audio_config_format(struct hdmi_wp_data *wp,
diff --git a/drivers/video/fbdev/omap2/dss/hdmi_common.c
b/drivers/video/fbdev/omap2/dss/hdmi_common.c
index 9a2c39c..85a2407 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi_common.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi_common.c
@@ -19,6 +19,12 @@
#include
#include
#include
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) ||
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+#include
+#include
+#include
+#include
+#endif
#include "hdmi.h"
@@ -364,7 +370,7 @@ int hdmi_parse_lanes_of(struct platform_device *pdev,
struct device_node *ep,
return 0;
}
-#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
+#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO) ||
defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n, u32 *cts)
{
u32 deep_color;
@@ -463,4 +469,113 @@ int hdmi_compute_acr(u32 pclk, u32 sample_freq, u32 *n,
u32 *cts)
return 0;
}
+
+int hdmi_dss_audio_from_hw_params(struct snd_pcm_hw_params *params,
+ struct omap_dss_audio *dss_audio,
+ struct snd_soc_dai *dai)
+{
+ struct snd_aes_iec958 *iec = dss_audio->iec;
+ struct snd_cea_861_aud_if *cea = dss_audio->cea;
+
+ /*
+* fill the IEC-60958 channel status word
+*/
+ /* initialize the word bytes */
+ memset(iec->status, 0, sizeof(iec->status));
+
+ /* specify IEC-60958-3 (commercial use) */
+ iec->status[0] &= ~IEC958_AES0_PROFESSIONAL;
+
+ /* specify that the audio is LPCM*/
+ iec->status[0] &= ~IEC958_AES0_NONAUDIO;
+
+ iec->status[0] |= IEC958_AES0_CON_NOT_COPYRIGHT;
+
+ iec->status[0] |= IEC958_AES0_CON_EMPHASIS_NONE;
+
+ iec->status[0] |= IEC958_AES1_PRO_MODE_NOTID;
+
+ iec->status[1] = IEC958_AES1_CON_GENERAL;
+
+ iec->status[2] |= IEC958_AES2_CON_SOURCE_UNSPEC;
+
+ iec->status[2] |= IEC958_AES2_CON_CHANNEL_UNSPEC;
+
+ switch (params_rate(params)) {
+ case 32000:
+ iec->status[3] |= IEC958_AES3_CON_FS_32000;
+ break;
+ case 44100:
+ iec->status[3] |= IEC958_AES3_CON_FS_44100;
+ break;
+ case 48000:
+ iec->status[3] |= IEC958_AES3_CON_FS_48000;
+ break;
+ case 88200:
+ iec->status[3] |= IEC958_AES3_CON_FS_88200;
+ break;
+ case 96000:
+ iec->status[3] |= IEC958_AES3_CON_FS_96000;
+ break;
+ case 176400:
+ iec->status[3] |= IEC958_AES3_CON_FS_176400;
+ break;
+ case 192000:
+ iec->status[3] |= IEC958_AES3_CON_FS_192000;
+ break;
+ default:
+ dev_err(dai->dev, "rate not supported!\n");
+ return -EINVAL;
+ }
+
+ /* specify the clock accuracy */
+ iec->status[3] |= IEC958_AES3_CON_CLOCK_1000PPM;
+
+ /*
+* specify the word length. The same word length value can mean
+* two different lengths. Hence, we need to specify the maximum
+* word length as well.
+*/
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ iec->status[4] |= IEC958_AES4_CON_WORDLEN_20_16;
+ iec->status[4] &= ~IEC958_AES4_CON_MAX_WORDLEN_24;
+ break;
+ case SNDRV_PCM_FORMAT_S24_LE:
+ iec->status[4] |= IEC958_AES4_CON_WORDLEN_24_20;
+ iec->status[4] |= IEC958_AES4_CON_MAX_WORDLEN_24;
+ break;
+ default:
+ dev_err(dai->dev, "format not supported!\n");
+ return -EINVAL;
+ }
+
+ /*
+* Fill the CEA-861 audio infoframe (see spec for details)
+*/
+
+ cea->db1_ct_cc = (params_chan
[PATCH 00/19] Rework OMAP4+ HDMI audio support
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/19] OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO
Use correct variable name for base address. Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/hdmi5_core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c index 270ebdd..af88e3c 100644 --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c @@ -786,7 +786,7 @@ static void hdmi5_core_audio_config(struct hdmi_core_data *core, REG_FLD_MOD(base, HDMI_CORE_AUD_GP_POL, 1, 0, 0); /* unmute audio */ - REG_FLD_MOD(core_sys_base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4); + REG_FLD_MOD(base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4); } static void hdmi5_core_audio_infoframe_cfg(struct hdmi_core_data *core, -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/19] OMAPDSS: hdmi.h: Add HDMI_AUDIO_LAYOUT_6CH enum value
The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in
hdmi_core_audio_layout enum. I found the correct value from ti-linux
3.8 tree.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi.h
b/drivers/video/fbdev/omap2/dss/hdmi.h
index 65bf072..ea4a168 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi.h
+++ b/drivers/video/fbdev/omap2/dss/hdmi.h
@@ -159,7 +159,8 @@ enum hdmi_audio_blk_strt_end_sig {
enum hdmi_core_audio_layout {
HDMI_AUDIO_LAYOUT_2CH = 0,
- HDMI_AUDIO_LAYOUT_8CH = 1
+ HDMI_AUDIO_LAYOUT_8CH = 1,
+ HDMI_AUDIO_LAYOUT_6CH = 2
};
enum hdmi_core_cts_mode {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/19] ARM: omap2plus_defconfig: Build DSS HDMI support for OMAP4 in kernel
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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP5_DSS_HDMI_AUDIO
Signed-off-by: Jyri Sarha --- drivers/video/fbdev/omap2/dss/Kconfig |9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig index ecc2f50..b28e175 100644 --- a/drivers/video/fbdev/omap2/dss/Kconfig +++ b/drivers/video/fbdev/omap2/dss/Kconfig @@ -90,8 +90,15 @@ config OMAP5_DSS_HDMI specification. config OMAP5_DSS_HDMI_AUDIO + bool "HDMI audio support for OMAP5" depends on OMAP5_DSS_HDMI - bool + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC + default y + help + HDMI audio support for OMAP5 based SoCs. Adds integrated + ASoC Digital Audio Interface component driver into OMAPDSS + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with + devicetree description for full HDMI audio support. config OMAP2_DSS_SDI bool "SDI support" -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/19] OMAPDSS: hdmi5: Remove callbacks for an external ASoC DAI driver
Removes the OMAP5 HDMI audio callbacks for an external audio driver and
the old external DAI driver does not work anymore after this patch.
Signed-off-by: Jyri Sarha
---
drivers/video/fbdev/omap2/dss/hdmi5.c | 113 -
1 file changed, 113 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index c468b9e..49a85c9 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -534,112 +534,6 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
-#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- mutex_lock(&hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi_wp_audio_enable(&hdmi.wp, true);
- if (r)
- goto err;
-
- mutex_unlock(&hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(&hdmi.lock);
- return r;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
- hdmi_wp_audio_enable(&hdmi.wp, false);
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return hdmi_wp_audio_core_req_enable(&hdmi.wp, true);
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
- hdmi_wp_audio_core_req_enable(&hdmi.wp, false);
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- bool r;
-
- mutex_lock(&hdmi.lock);
-
- r = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
-
- mutex_unlock(&hdmi.lock);
- return r;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- int r;
- u32 pclk = hdmi.cfg.timings.pixelclock;
-
- mutex_lock(&hdmi.lock);
-
- if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
- r = -EPERM;
- goto err;
- }
-
- r = hdmi5_audio_config(&hdmi.core, &hdmi.wp, audio, pclk);
- if (r)
- goto err;
-
- mutex_unlock(&hdmi.lock);
- return 0;
-
-err:
- mutex_unlock(&hdmi.lock);
- return r;
-}
-#else
-static int hdmi_audio_enable(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_disable(struct omap_dss_device *dssdev)
-{
-}
-
-static int hdmi_audio_start(struct omap_dss_device *dssdev)
-{
- return -EPERM;
-}
-
-static void hdmi_audio_stop(struct omap_dss_device *dssdev)
-{
-}
-
-static bool hdmi_audio_supported(struct omap_dss_device *dssdev)
-{
- return false;
-}
-
-static int hdmi_audio_config(struct omap_dss_device *dssdev,
- struct omap_dss_audio *audio)
-{
- return -EPERM;
-}
-#endif
-
static const struct omapdss_hdmi_ops hdmi_ops = {
.connect= hdmi_connect,
.disconnect = hdmi_disconnect,
@@ -652,13 +546,6 @@ static const struct omapdss_hdmi_ops hdmi_ops = {
.get_timings= hdmi_display_get_timings,
.read_edid = hdmi_read_edid,
-
- .audio_enable = hdmi_audio_enable,
- .audio_disable = hdmi_audio_disable,
- .audio_start= hdmi_audio_start,
- .audio_stop = hdmi_audio_stop,
- .audio_supported= hdmi_audio_supported,
- .audio_config = hdmi_audio_config,
};
static void hdmi_init_output(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/19] OMAPDSS: hdmi5: Integrated ASoC DAI component driver implementation
Integrate ASoC DAI component driver in to the OMAP5 hdmi driver. The
patch also updates the relevant entry in ti,omap5-dss DT binding
document.
Signed-off-by: Jyri Sarha
---
.../devicetree/bindings/video/ti,omap5-dss.txt |4 +
drivers/video/fbdev/omap2/dss/hdmi5.c | 199
2 files changed, 203 insertions(+)
diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
index 38ffc8f..795f5cf 100644
--- a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
+++ b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
@@ -88,6 +88,10 @@ Required properties:
- clocks: handles to fclk and pll clock
- clock-names: "fck", "sys_clk"
+Required properties if hdmi audio support is enabled:
+- dmas: DMA controller phandle for HDMI audio output
+- dma-names: "audio_tx"
+
Optional nodes:
- Video port for HDMI output
diff --git a/drivers/video/fbdev/omap2/dss/hdmi5.c
b/drivers/video/fbdev/omap2/dss/hdmi5.c
index 49a85c9..c6a8862 100644
--- a/drivers/video/fbdev/omap2/dss/hdmi5.c
+++ b/drivers/video/fbdev/omap2/dss/hdmi5.c
@@ -39,6 +39,16 @@
#include
#include
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#endif
+
#include "hdmi5_core.h"
#include "dss.h"
#include "dss_features.h"
@@ -57,6 +67,13 @@ static struct {
struct clk *sys_clk;
struct regulator *vdda_reg;
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+ struct snd_dmaengine_dai_dma_data dma_data;
+ struct omap_dss_audio dss_audio;
+ struct snd_aes_iec958 iec;
+ struct snd_cea_861_aud_if cea;
+#endif
+
bool core_enabled;
struct omap_dss_device output;
@@ -534,6 +551,182 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
return r;
}
+#if defined(CONFIG_OMAP5_DSS_HDMI_AUDIO)
+static int hdmi_dai_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ int ret;
+ /*
+* Make sure that the period bytes are multiple of the DMA packet size.
+* Largest packet size we use is 32 32-bit words = 128 bytes
+*/
+ ret = snd_pcm_hw_constraint_step(substream->runtime, 0,
+SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 128);
+ if (ret < 0) {
+ dev_err(dai->dev, "could not apply constraint\n");
+ return ret;
+ }
+
+ mutex_lock(&hdmi.lock);
+ ret = hdmi_mode_has_audio(hdmi.cfg.cm.mode);
+ mutex_unlock(&hdmi.lock);
+ if (!ret) {
+ dev_err(dai->dev, "audio not supported\n");
+ return -ENODEV;
+ }
+
+ snd_soc_dai_set_dma_data(dai, substream, &hdmi.dma_data);
+
+ return 0;
+}
+
+static int hdmi_dai_prepare(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ int r;
+
+ mutex_lock(&hdmi.lock);
+
+ if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
+ r = -EPERM;
+ goto err;
+ }
+
+ r = hdmi_wp_audio_enable(&hdmi.wp, true);
+
+err:
+ mutex_unlock(&hdmi.lock);
+ return r;
+}
+
+static int hdmi_dai_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ int err;
+
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_S16_LE:
+ hdmi.dma_data.maxburst = 16;
+ break;
+ case SNDRV_PCM_FORMAT_S24_LE:
+ hdmi.dma_data.maxburst = 32;
+ break;
+ default:
+ dev_err(dai->dev, "format not supported!\n");
+ return -EINVAL;
+ }
+
+ hdmi.dss_audio.iec = &hdmi.iec;
+ hdmi.dss_audio.cea = &hdmi.cea;
+ err = hdmi_dss_audio_from_hw_params(params, &hdmi.dss_audio, dai);
+ if (err)
+ return err;
+
+ mutex_lock(&hdmi.lock);
+
+ if (!hdmi_mode_has_audio(hdmi.cfg.cm.mode)) {
+ err = -EPERM;
+ goto err;
+ }
+
+ err = hdmi5_audio_config(&hdmi.core, &hdmi.wp, &hdmi.dss_audio,
+hdmi.cfg.timings.pixelclock);
+err:
+ mutex_unlock(&hdmi.lock);
+ return err;
+}
+
+static int hdmi_dai_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ int err = 0;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ err = hdmi_wp_audio_core_req_enable(&hdmi.wp, true);
+ break;
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ hdmi_wp_audio_core_req_enable(&hdmi.wp, false);
+ break;
+
[PATCH 13/19] ARM: omap4.dtsi: Add audio related parametes to hdmi node
Adds HDMI audio sDMA properties. Signed-off-by: Jyri Sarha --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
On Mon, May 12, 2014 at 11:05 AM, Gupta, Pekon wrote: >>From: Javier Martinez Canillas [mailto:jav...@dowhile0.org] > [...] > >>> Newer platforms have upgraded version of GPMC engine which supports >>> BCH16 ECC scheme in hardware. Thus the GPMC address space was >>> expanded to include some extra registers required for BCH16 ECC [2]. >>> >>> >> >>I see and did the GPMC register space became that big to need to map 8KB? >> >>Although the smallest unit for ioremap is PAGE_SIZE and using any of >>these reg sizes: >> >>reg = <0x6e00 0x02d0>; >>reg = <0x6e00 0x0400>; >>reg = <0x6e00 0x1000>; >> >>in practice have the same effect, DTS should describe the hardware and >>not an implementation detail so I think that we should use only the >>register size that is defined in the TRM. >> > Yes, I agree with you. > I have fixed this in newer version of the patch and will be sending it soon. > But this series will only contain updates for new platforms with addition > of NAND node in DTS, so that this series is not stalled for any reason. > For fixing existing platform/boards DTS I'll send another series soon. > Yes, I agree that fixing existing platforms is a matter of a different series, I just didn't want to introduce more :-) > For now, I'll use GPMC address-space size = 0x380 as it matches with > actual hardware and is working. > Perfect, thanks a lot! >>> >>> [1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5) >>> >>> [2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5) >>> (Though the AM335x address space mentions 0x368 as last address, >>> it should be 0x378. I have raised documentation bug for it). >>> >>> >>> with regards, pekon >> >>Best regards, >>Javier >> >>[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334 Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
>From: Javier Martinez Canillas [mailto:jav...@dowhile0.org] [...] >> Newer platforms have upgraded version of GPMC engine which supports >> BCH16 ECC scheme in hardware. Thus the GPMC address space was >> expanded to include some extra registers required for BCH16 ECC [2]. >> >> > >I see and did the GPMC register space became that big to need to map 8KB? > >Although the smallest unit for ioremap is PAGE_SIZE and using any of >these reg sizes: > >reg = <0x6e00 0x02d0>; >reg = <0x6e00 0x0400>; >reg = <0x6e00 0x1000>; > >in practice have the same effect, DTS should describe the hardware and >not an implementation detail so I think that we should use only the >register size that is defined in the TRM. > Yes, I agree with you. I have fixed this in newer version of the patch and will be sending it soon. But this series will only contain updates for new platforms with addition of NAND node in DTS, so that this series is not stalled for any reason. For fixing existing platform/boards DTS I'll send another series soon. For now, I'll use GPMC address-space size = 0x380 as it matches with actual hardware and is working. >> >> [1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5) >> >> [2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5) >> (Though the AM335x address space mentions 0x368 as last address, >> it should be 0x378. I have raised documentation bug for it). >> >> >> with regards, pekon > >Best regards, >Javier > >[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
Re: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hello Pekon,
On Mon, May 12, 2014 at 9:03 AM, Gupta, Pekon wrote:
> Hello,
>
> From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
>>On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta wrote:
>>> From: Minal Shah
> [...]
>>> +&gpmc {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&nand_flash_x16>;
>>> + ranges = <0 0 0 0x100>;
>>> + nand@0,0 {
>>> + reg = <0 0 0x380>;
> [...]
>
>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>> index 37a0595..6af775a 100644
>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>> @@ -776,6 +776,26 @@
>>> interrupts = <0 343 0x4>;
>>> status = "disabled";
>>> };
>>> +
>>> + elm: elm@48078000 {
>>> + compatible = "ti,am3352-elm";
>>> + reg = <0x48078000 0x2000>;
>>
>>It is really necessary to map all this 8 KB address space for GPMC registers?
>>
>>I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
>>that the GPMC module register address space size is 16 MB while in
>>practice the registers use less than 1 KB (0..0x02d0 to be exact) so
>>in arch/arm/boot/dts/omap3.dtsi we have:
>>
> These are not GPMC registers. Platforms from OMAP4 and beyond
> (like AM335x, OMAP5) have another small hardware engine called ELM [1]
> (Error Locater Module) in addition to GPMC, which is used for detecting
> ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c
>
Yes, I know what ELM is, I just made a mistake when adding my comments
inline. I actually meant the 8KB from the following device node:
> + gpmc: gpmc@5000 {
> + compatible = "ti,am3352-gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x5000 0x2000>;
> + interrupts = ;
> + gpmc,num-cs = <8>;
> + gpmc,num-waitpins = <2>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + status = "disabled";
> + };
> However, thanks for pointing out, this address-space for ELM is incorrect.
> Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1].
>
And yes, comments applies to ELM register address space as well.
>>gpmc: gpmc@6e00 {
>>...
>>reg = <0x6e00 0x02d0>;
>>...
>>};
>>
>>Shouldn't this be similar (the same?) for DRA7 GPMC device node?
>>
> Newer platforms have upgraded version of GPMC engine which supports
> BCH16 ECC scheme in hardware. Thus the GPMC address space was
> expanded to include some extra registers required for BCH16 ECC [2].
>
>
I see and did the GPMC register space became that big to need to map 8KB?
Although the smallest unit for ioremap is PAGE_SIZE and using any of
these reg sizes:
reg = <0x6e00 0x02d0>;
reg = <0x6e00 0x0400>;
reg = <0x6e00 0x1000>;
in practice have the same effect, DTS should describe the hardware and
not an implementation detail so I think that we should use only the
register size that is defined in the TRM.
>
> [1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
>
> [2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
> (Though the AM335x address space mentions 0x368 as last address,
> it should be 0x378. I have raised documentation bug for it).
>
>
> with regards, pekon
Best regards,
Javier
[0]: http://lxr.free-electrons.com/source/arch/arm/mm/ioremap.c#L334
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] mmc: omap_hsmmc: use devm_clk_get
On 9 May 2014 18:46, Balaji T K wrote:
> With devm_clk_get conversion clk_put can be removed in clean up path
>
> Signed-off-by: Balaji T K
> ---
> drivers/mmc/host/omap_hsmmc.c | 15 ---
> 1 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index b4de63b..b8ae7ee 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1922,7 +1922,7 @@ static int omap_hsmmc_probe(struct platform_device
> *pdev)
>
> spin_lock_init(&host->irq_lock);
>
> - host->fclk = clk_get(&pdev->dev, "fck");
> + host->fclk = devm_clk_get(&pdev->dev, "fck");
> if (IS_ERR(host->fclk)) {
> ret = PTR_ERR(host->fclk);
> host->fclk = NULL;
> @@ -1941,7 +1941,7 @@ static int omap_hsmmc_probe(struct platform_device
> *pdev)
>
> omap_hsmmc_context_save(host);
>
> - host->dbclk = clk_get(&pdev->dev, "mmchsdb_fck");
> + host->dbclk = devm_clk_get(&pdev->dev, "mmchsdb_fck");
> /*
> * MMC can still work without debounce clock.
> */
> @@ -1949,7 +1949,6 @@ static int omap_hsmmc_probe(struct platform_device
> *pdev)
> host->dbclk = NULL;
> } else if (clk_prepare_enable(host->dbclk) != 0) {
> dev_warn(mmc_dev(host->mmc), "Failed to enable debounce
> clk\n");
> - clk_put(host->dbclk);
> host->dbclk = NULL;
You should use the IS_ERR macro, no need to reset dbclk to NULL.
> }
>
> @@ -2105,11 +2104,8 @@ err_irq:
> dma_release_channel(host->rx_chan);
> pm_runtime_put_sync(host->dev);
> pm_runtime_disable(host->dev);
> - clk_put(host->fclk);
> - if (host->dbclk) {
> + if (host->dbclk)
Use IS_ERR instead.
> clk_disable_unprepare(host->dbclk);
> - clk_put(host->dbclk);
> - }
> err1:
> iounmap(host->base);
> mmc_free_host(mmc);
> @@ -2144,11 +2140,8 @@ static int omap_hsmmc_remove(struct platform_device
> *pdev)
>
> pm_runtime_put_sync(host->dev);
> pm_runtime_disable(host->dev);
> - clk_put(host->fclk);
> - if (host->dbclk) {
> + if (host->dbclk)
Use IS_ERR instead.
> clk_disable_unprepare(host->dbclk);
> - clk_put(host->dbclk);
> - }
>
> omap_hsmmc_gpio_free(host->pdata);
> iounmap(host->base);
> --
> 1.7.5.4
>
Kind regards
Ulf Hansson
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On Sun, May 11, 2014 at 4:42 PM, Tony Lindgren wrote: > * Andreas Müller [140509 14:07]: >> On Fri, May 9, 2014 at 9:38 AM, Tomi Valkeinen 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
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 QVGAomapfb.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
signature.asc
Description: OpenPGP digital signature
RE: [PATCH v4 3/6] ARM: dts: dra7: add support for parallel NAND flash
Hello,
From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
>On Fri, May 9, 2014 at 10:46 PM, Pekon Gupta wrote:
>> From: Minal Shah
[...]
>> +&gpmc {
>> + status = "okay";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&nand_flash_x16>;
>> + ranges = <0 0 0 0x100>;
>> + nand@0,0 {
>> + reg = <0 0 0x380>;
[...]
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 37a0595..6af775a 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -776,6 +776,26 @@
>> interrupts = <0 343 0x4>;
>> status = "disabled";
>> };
>> +
>> + elm: elm@48078000 {
>> + compatible = "ti,am3352-elm";
>> + reg = <0x48078000 0x2000>;
>
>It is really necessary to map all this 8 KB address space for GPMC registers?
>
>I don't have access to the DRA7 TRM but for example the OMAP3 TRM says
>that the GPMC module register address space size is 16 MB while in
>practice the registers use less than 1 KB (0..0x02d0 to be exact) so
>in arch/arm/boot/dts/omap3.dtsi we have:
>
These are not GPMC registers. Platforms from OMAP4 and beyond
(like AM335x, OMAP5) have another small hardware engine called ELM [1]
(Error Locater Module) in addition to GPMC, which is used for detecting
ECC errors in hardware. ELM Driver $KERNEL/drivers/mtd/devices/elm.c
However, thanks for pointing out, this address-space for ELM is incorrect.
Last ELM register offset is 0xFC0 (ELM_ERROR_LOCATION_15_7) [1].
>gpmc: gpmc@6e00 {
>...
>reg = <0x6e00 0x02d0>;
>...
>};
>
>Shouldn't this be similar (the same?) for DRA7 GPMC device node?
>
Newer platforms have upgraded version of GPMC engine which supports
BCH16 ECC scheme in hardware. Thus the GPMC address space was
expanded to include some extra registers required for BCH16 ECC [2].
>Thanks a lot and best regards,
>Javier
[1] http://www.ti.com/lit/gpn/am3359(Section 7.4 to 7.4.5)
[2] http://www.ti.com/lit/gpn/am3359(Section 7.1 to 7.1.5)
(Though the AM335x address space mentions 0x368 as last address,
it should be 0x378. I have raised documentation bug for it).
with regards, pekon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
