Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Andy Shevchenko]

On Wed, Nov 18, 2015 at 5:51 PM, Arnd Bergmann  wrote:
> On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
>> >
>> > I assume that the sst-firmware.c case is a mistake, it should just use a
>> > plain DMA_SLAVE and not DMA_MEMCPY.
>>
>> Other way around.
>>
>
> Ok, I see. In that case I guess it also shouldn't call
> dmaengine_slave_config(), right? I don't think that's valid
> on a MEMCPY channel.

Hmm… That's right, though I suspect still one thing why it's done this
way. Let's ask Vinod and Liam about that.

-- 
With Best Regards,
Andy Shevchenko
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
> >> 2. non slave channel requests, where only the functionality matters, like
> >> memcpy, interleaved, memset, etc.
> >> We could have a simple:
> >> dma_request_channel(mask);
> >>
> >> But looking at the drivers using dmaengine legacy dma_request_channel() 
> >> API:
> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
> >> drivers/misc/carma/carma-fpga.c 
> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
> >> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
> >> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
> >> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
> >>
> >> as examples.
> >> Not sure how valid are these...

I just had a look myself. carma has been removed fortunately in linux-next,
so we don't have to worry about that any more.

I assume that the sst-firmware.c case is a mistake, it should just use a
plain DMA_SLAVE and not DMA_MEMCPY.

Aside from these, everyone else uses either DMA_CYCLIC in addition to
DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is
redundant in slave drivers and can be removed.

> > It's usually not much harder to separate out the legacy case from
> > the normal dma_request_slave_channel_reason(), so those drivers don't
> > really need to use the unified compat API.
> 
> The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
> Currently there is no way to get the reason why the dma channel request fails
> when using the _compat() version of the API, which is used by drivers which
> can be used in DT or in legacy mode as well. Sure, they all could have local
> if(){}else{} for handling this, but it is not a nice thing.
> 
> As it was discussed instead of adding the _reason() version for the _compat
> call, we should simplify the dmaengine API for getting the channel and at the
> same time we will have ERR_PTR returned instead of NULL.

What I meant was that we don't need to handle them with the unified
simple interface. The users of DMA_CYCLIC can just keep using
an internal helper that only deals with the legacy case, or use
dma_request_slave() or whatever is the new API for the DT case.

Arnd
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Andy Shevchenko]

On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi  wrote:
> Hi Vinod,
>
> bringing this old thread back to life as I just started to work on this.

What I remember we need to convert drivers to use new API meanwhile it
is good to keep old one to avoid patch storm which does nothing useful
(IIRC Russel's opinion).

On the other hand there are a lot of drivers that are used on the set
of platforms starting from legacy and abandoned ones (like AVR32) to
relatively new and newest.

And I'm not a fan of those thousands of API calls either.

-- 
With Best Regards,
Andy Shevchenko
--
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: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Grygorii Strashko]

Hi Mark,

On 11/18/2015 04:15 PM, Mark Rutland wrote:
> On Wed, Nov 18, 2015 at 04:01:55PM +0200, Grygorii Strashko wrote:
>> Keep ARM TWD and Global timer's nodes disabled by default - if someone
>> would like to use them then those nodes have to be enabled explicitly
>> in board file.
>>
>> The reason for this change is:
>> - ARM TWD is not always-on timer on am437x and it will stop in low
>>CPUIdle states and, therefore, broadcast timer has to configured
>>properly if CPU_IDLE=y.
>> - ARM Global timer is not always-on timer on am437x and it can't be
>>used as clocksource device if CPU_IDLE=y.
> 
> I don't understand. What timer do you use in the absence of a TWD, and
> if it is better why is it not used even if TWD is present?

OMAP GP timer as clockevent device
"ti,omap-counter32k" as clocksource
both are in wakeup (always-on) PM domain.

I see some problems with selecting clocksource/event device (but may be I'm 
mistaken):
- Current clock event will be selected using "rating" field in 
clock_event_device
  structure and now ARM TWD has higer value (350) vs OMAP GP timer (300),
  so ARM TWD will be always selected if it's present. 
- we have to force all am437x user to use kernel cmdline parameter 
"clocksource="
  if ARM Global timer is present, but shouldn't be used. But even in this case,
  it will be selected as sched_clock.

We can see benefits from using these timers when Power mangement is not the 
case,
for example on -RT kernel where CPUIdle is not the target.

By this change, and taking into account discovered issues, I want to make 
people,
who would like to use these timers on AM437x based boards, responsible for such
decision with assumption that they know what they are doing.
And this is simplest way I found to disable those timers without modifying 
kernel.

> 
>> - ARM Global timer driver doesn't support CPUfreq now.
> 
> Surely that should be fixed in the driver (e.g. make it fail to probe if
> CPUfreq is present)? It's broken for any other users too...

May be.

Also, there is additional issue with ARM global timer which I've not
mentioned here, because I sent the fix for it already (in progress):
https://lkml.org/lkml/2015/11/13/456

and there is ongoing discussion:
http://www.spinics.net/lists/arm-kernel/msg459649.html

-- 
regards,
-grygorii
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Andy Shevchenko]

On Wed, Nov 18, 2015 at 5:07 PM, Arnd Bergmann  wrote:
> On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
>> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
>> > On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>> >> 2. non slave channel requests, where only the functionality matters, like
>> >> memcpy, interleaved, memset, etc.
>> >> We could have a simple:
>> >> dma_request_channel(mask);
>> >>
>> >> But looking at the drivers using dmaengine legacy dma_request_channel() 
>> >> API:
>> >> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>> >> drivers/misc/carma/carma-fpga.c 
>> >> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>> >> drivers/misc/carma/carma-fpga-program.c 
>> >> DMA_MEMCPY|DMA_SLAVE|DMA_SG
>> >> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
>> >> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
>> >>
>> >> as examples.
>> >> Not sure how valid are these...
>
> I just had a look myself. carma has been removed fortunately in linux-next,
> so we don't have to worry about that any more.
>
> I assume that the sst-firmware.c case is a mistake, it should just use a
> plain DMA_SLAVE and not DMA_MEMCPY.

Other way around.

-- 
With Best Regards,
Andy Shevchenko
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
> >
> > I assume that the sst-firmware.c case is a mistake, it should just use a
> > plain DMA_SLAVE and not DMA_MEMCPY.
> 
> Other way around.
> 

Ok, I see. In that case I guess it also shouldn't call
dmaengine_slave_config(), right? I don't think that's valid
on a MEMCPY channel.

Arnd
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Vinod Koul]

On Wed, Nov 18, 2015 at 04:51:54PM +0100, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote:
> > >
> > > I assume that the sst-firmware.c case is a mistake, it should just use a
> > > plain DMA_SLAVE and not DMA_MEMCPY.
> > 
> > Other way around.
> > 
> 
> Ok, I see. In that case I guess it also shouldn't call
> dmaengine_slave_config(), right? I don't think that's valid
> on a MEMCPY channel.

Yes it is not valid. In this case the dma driver should invoke a generic memcpy
and not need slave parameters, knowing the hw and reason for this (firmware
download to DSP memory), this doesn't qualify for slave case.
In fact filter function doesn't need a channel, any channel in this
controller will be good

-- 
~Vinod
--
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: [BISECTED] v4.4-rc1 GPIO regression on OMAP1

[Aaro Koskinen]

Hi,

On Wed, Nov 18, 2015 at 02:58:38PM +0200, Grygorii Strashko wrote:
> On 11/17/2015 11:42 PM, Aaro Koskinen wrote:
> >Amstrad E3 computer (OMAP1) boot crashes early with v4.4-rc1. Bisected to:
> >
> > 450fa54cfd66e3dda6eda26256637ee8928af12a is the first bad commit
> > commit 450fa54cfd66e3dda6eda26256637ee8928af12a
> > Author: Grygorii Strashko 
> > Date:   Fri Sep 25 12:28:03 2015 -0700
> > 
> > gpio: omap: convert to use generic irq handler
>
> Could you check pls if below change will solve this issue, pls?
> 
> iff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 56d2d02..2905e0d 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1129,7 +1129,7 @@ static int omap_gpio_chip_init(struct gpio_bank *bank,
> struct irq_chip *irqc)
> }
> 
> ret = gpiochip_irqchip_add(>chip, irqc,
> -  irq_base, handle_bad_irq,
> +  irq_base, handle_simple_irq,
>IRQ_TYPE_NONE);

This works!

A.
--
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: omap2: Kconfig: select TWD and global timer on AM43xx devices

[santosh shilimkar]

On 11/18/2015 6:33 AM, Grygorii Strashko wrote:

On 11/13/2015 06:39 PM, santosh shilimkar wrote:

On 11/13/2015 5:07 AM, Mason wrote:

On 13/11/2015 13:48, Grygorii Strashko wrote:

On 11/12/2015 08:06 PM, Felipe Balbi wrote:

Make sure to tell the kernel that AM437x has
TWD and global timers.

Signed-off-by: Felipe Balbi 
---

Hi Tony,

now that all dependencies are in place, we can
finally enable twd and global_timer for AM437x.


Is AM437x SMP SOC ?


No. But it has ARM TWD and GT


Is TWD on AM437x works in low power states ?


No. But TWD, seems, is not a problem here if omap gp timer
can be used as broadcast device.


Probably I haven't followed the recent updates, but does
the TWD supports C3STOP on UP systems ? The broadcast
code was SMP only in past, and TWD use to die in
low power state on past OMAP SOCs.

If either of these are still the issue then
TWD shouldn't be used.



Yep. I see the problem with ARM Global timer here if
CPUIdle is enabled and ARM Global timer is selected as
clocksource device.


Its expected and well known limitation.


I think, it will be right thing to disable "global_timer"
and "local_timer" nodes in am437x.dtsi by default - if
someone would like to use them then those nodes have
to be enabled explicitly in board file.
(TWD timer will be enabled on OMAP multi SoC build
  irrespectively of HAVE_ARM_TWD is selected for am437x or not,
  because it will be selected for omap4).
I've just sent corresponding patch:
  http://www.spinics.net/lists/arm-kernel/msg461141.html

Also, probably, it could be reasonable to:
- make ARM_GLOBAL_TIMER fully selectable option and allow select it from 
defconfig.

- or - update this patch as below
-   select ARM_GLOBAL_TIMER
-   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+   select ARM_GLOBAL_TIMER if !CPU_IDLE
+   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK if ARM_GLOBAL_TIMER



+1
--
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 v2] hw_random: omap3-rom-rng: convert timer to delayed work

[Aaro Koskinen]

We cannot put the HW RNG to idle using a timer because we cannot disable
clocks from atomic context. Use a delayed work instead.

Fixes a warning with CONFIG_DEBUG_MUTEXES on Nokia N900 during boot.

Reported-by: Sebastian Reichel 
Signed-off-by: Aaro Koskinen 
---

v2: Include workqueue.h instead of timer.h.

 drivers/char/hw_random/omap3-rom-rng.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/omap3-rom-rng.c 
b/drivers/char/hw_random/omap3-rom-rng.c
index a405cdc..8da14f1 100644
--- a/drivers/char/hw_random/omap3-rom-rng.c
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -29,11 +29,11 @@
 /* param1: ptr, param2: count, param3: flag */
 static u32 (*omap3_rom_rng_call)(u32, u32, u32);
 
-static struct timer_list idle_timer;
+static struct delayed_work idle_work;
 static int rng_idle;
 static struct clk *rng_clk;
 
-static void omap3_rom_rng_idle(unsigned long data)
+static void omap3_rom_rng_idle(struct work_struct *work)
 {
int r;
 
@@ -51,7 +51,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
u32 r;
u32 ptr;
 
-   del_timer_sync(_timer);
+   cancel_delayed_work_sync(_work);
if (rng_idle) {
clk_prepare_enable(rng_clk);
r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
@@ -65,7 +65,7 @@ static int omap3_rom_rng_get_random(void *buf, unsigned int 
count)
 
ptr = virt_to_phys(buf);
r = omap3_rom_rng_call(ptr, count, RNG_GEN_HW);
-   mod_timer(_timer, jiffies + msecs_to_jiffies(500));
+   schedule_delayed_work(_work, msecs_to_jiffies(500));
if (r != 0)
return -EINVAL;
return 0;
@@ -102,7 +102,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   setup_timer(_timer, omap3_rom_rng_idle, 0);
+   INIT_DELAYED_WORK(_work, omap3_rom_rng_idle);
rng_clk = devm_clk_get(>dev, "ick");
if (IS_ERR(rng_clk)) {
pr_err("unable to get RNG clock\n");
@@ -118,6 +118,7 @@ static int omap3_rom_rng_probe(struct platform_device *pdev)
 
 static int omap3_rom_rng_remove(struct platform_device *pdev)
 {
+   cancel_delayed_work_sync(_work);
hwrng_unregister(_rom_rng_ops);
clk_disable_unprepare(rng_clk);
return 0;
-- 
2.4.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: Minimal support for dm814x

[Matthijs van Duin]

On 18 November 2015 at 09:26, Delio Brignoli  wrote:
>> This works in principle, but both minimizing the DCO and (often
>> needlessly) using the fractional multiplier seem like recipes to
>> maximize the clock jitter. Mind you, I don't know how much jitter
>> we’re talking about here, I don't recall having seen specs about this.
>
> We haven’t seen any specs either but testing shows that changing DCO mode 
> causes
> the PLL to lose lock at least temporarily.

Losing lock on reconfiguration is entirely a separate matter from
clock jitter. The fractional multiplier works by essentially by
alternating between the nearest integer multiplier values. This will
be smoothed out by the loop filter, but it's not going to vanish.

To put this in perspective, some docs (I can't immediately find which
one) warned that when using the fractional multiplier of DPLLS, its
value needed to be at least 100 to ensure max 2.5% jitter. To put this
in perspective, if I grab the datasheet of an audio DAC I find:
   Although the architecture of the PCM4104 is tolerant to
   phase jitter on the system clock, it is recommended that
   the user provide a low jitter clock (100 picoseconds or less)
   for optimal performance.
For a typical 24.576 MHz audio system clock that means max 0.25%
jitter. Whoops :P

Now DPLLLJ will presumably do better, but without actual specs the
safe option is to avoid the fractional multiplier altogether.

Matthijs
--
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: [BISECTED] v4.4-rc1 GPIO regression on OMAP1

[Grygorii Strashko]

Hi Aaro,

On 11/17/2015 11:42 PM, Aaro Koskinen wrote:

Amstrad E3 computer (OMAP1) boot crashes early with v4.4-rc1. Bisected to:

450fa54cfd66e3dda6eda26256637ee8928af12a is the first bad commit
commit 450fa54cfd66e3dda6eda26256637ee8928af12a
Author: Grygorii Strashko 
Date:   Fri Sep 25 12:28:03 2015 -0700

gpio: omap: convert to use generic irq handler

Reverting the commit works (as a quick workaround at least).

The crash log:

[0.253612] Unable to handle kernel NULL pointer dereference at virtual 
address 
[0.262613] pgd = c0004000
[0.265754] [] *pgd=
[0.269862] Internal error: Oops: 75 [#1] ARM
[0.274734] Modules linked in:
[0.278313] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.4.0-rc1-e3-los_afe0c+-2-g25379c0-dirty #1
[0.288246] Hardware name: Amstrad E3 (Delta)
[0.293146] task: c1836000 ti: c1838000 task.ti: c1838000
[0.299155] PC is at irq_gc_mask_set_bit+0x1c/0x60
[0.304525] LR is at __irq_do_set_handler+0x118/0x15c
[0.310165] pc : []lr : []psr: 60d3
[0.310165] sp : c1839c90  ip : c1862c64  fp : c1839c9c
[0.322740] r10:   r9 : c0411950  r8 : c0411bbc
[0.328533] r7 :   r6 : c185c310  r5 : c00444e8  r4 : c185c300
[0.335687] r3 : c1854b50  r2 :   r1 :   r0 : c185c310
[0.342858] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment 
kernel
[0.351153] Control: 317f  Table: 10004000  DAC: 0057
[0.357494] Process swapper (pid: 1, stack limit = 0xc1838190)
[0.363917] Stack: (0xc1839c90 to 0xc183a000)
[0.368837] 9c80: c1839cc4 c1839ca0 
c0047d4c c0048480
[0.377916] 9ca0:   0050 c185c300 c00444e8  
c1839cec c1839cc8
[0.386989] 9cc0: c0047dd4 c0047c44 c0046f40 a053 0050 c00444e8 
 0050
[0.396064] 9ce0: c1839d0c c1839cf0 c0047e1c c0047da0 c1862c64 0050 
 0050
[0.405139] 9d00: c1839d24 c1839d10 c01b345c c0047dfc c185cb00 c185c310 
c1839d54 c1839d28
[0.414214] 9d20: c0049670 c01b3430 c0075888 c0043440 c1854b50 0001 
0010 0050
[0.423293] 9d40: c185cb00 c0411bbc c1839d7c c1839d58 c0049894 c0049604 
 c1862c64
[0.432375] 9d60: c1854b50 c1862c64 c0419280 c1862c64 c1839d9c c1839d80 
c01b3328 c004980c
[0.441456] 9d80: c1862c64 c1862c64 c1862c10 c1854b50 c1839ddc c1839da0 
c01b79f4 c01b32d4
[0.450530] 9da0:   c0411958 c0419294  c0411950 
c0419294 c0411984
[0.459605] 9dc0: c0419294  c03e45e8  c1839df4 c1839de0 
c01fcf58 c01b7708
[0.468684] 9de0: c0411950 c045ce30 c1839e1c c1839df8 c01fb668 c01fcf3c 
c0411950 c0419294
[0.477759] 9e00: c0411984   c03e45e8 c1839e3c c1839e20 
c01fb844 c01fb518
[0.486836] 9e20:  c0419294 c01fb7a4  c1839e64 c1839e40 
c01f9a90 c01fb7b4
[0.495913] 9e40: c185434c c185b450 c185b514 c0419294 c185b4e0 c041d9c8 
c1839e74 c1839e68
[0.504991] 9e60: c01fb078 c01f9a28 c1839e9c c1839e78 c01facf8 c01fb068 
c03931d0 c1839e88
[0.514069] 9e80: c0419294 c040bb80 c1804960 c03f5a08 c1839eb4 c1839ea0 
c01fbdb0 c01fab7c
[0.523150] 9ea0: c040bb80 c040bb80 c1839ec4 c1839eb8 c01fcf18 c01fbd40 
c1839ed4 c1839ec8
[0.532227] 9ec0: c03f5a20 c01fcef0 c1839f4c c1839ed8 c000966c c03f5a18 
c1839efc c1839ee8
[0.541304] 9ee0: c03e4604 c019b3b4 c03e2700 c1ffcd34 c1839f4c c1839f00 
c00314ec c03e45f8
[0.550384] 9f00:   0002 0002  c03e2024 
c038f2fc 
[0.559465] 9f20: c1839f4c 0002 c03ff81c 0002 c03ff820 005e 
c042ba80 c042ba80
[0.568543] 9f40: c1839f94 c1839f50 c03e4e14 c00095f0 0002 0002 
 c03e45e8
[0.577625] 9f60: 9b7bd08b c0406660 ad19cf47  c0305764  
 
[0.586701] 9f80:   c1839fac c1839f98 c0305774 c03e4d18 
 c0305764
[0.595775] 9fa0:  c1839fb0 c000a440 c0305774   
 
[0.604845] 9fc0:       
 
[0.613916] 9fe0:     0013  
faef8a80 f438707c
[0.622908] Backtrace:
[0.625894] [] (irq_gc_mask_set_bit) from [] 
(__irq_do_set_handler+0x118/0x15c)
[0.635897] [] (__irq_do_set_handler) from [] 
(__irq_set_handler+0x44/0x5c)
[0.645458]  r6: r5:c00444e8 r4:c185c300
[0.650746] [] (__irq_set_handler) from [] 
(irq_set_chip_and_handler_name+0x30/0x34)
[0.661128]  r7:0050 r6: r5:c00444e8 r4:0050
[0.667559] [] (irq_set_chip_and_handler_name) from [] 
(gpiochip_irq_map+0x3c/0x8c)
[0.677869]  r7:0050 r6: r5:0050 r4:c1862c64
[0.684300] [] (gpiochip_irq_map) from [] 
(irq_domain_associate+0x7c/0x1c4)
[0.693885]  r5:c185c310 r4:c185cb00
[0.698072] [] 

Re: Minimal support for dm814x

[Delio Brignoli]

On 18 Nov 2015, at 11:01, Matthijs van Duin  wrote:
> On 18 November 2015 at 09:26, Delio Brignoli  
> wrote:
>>> This works in principle, but both minimizing the DCO and (often
>>> needlessly) using the fractional multiplier seem like recipes to
>>> maximize the clock jitter. Mind you, I don't know how much jitter
>>> we’re talking about here, I don't recall having seen specs about this.
>> 
>> We haven’t seen any specs either but testing shows that changing DCO mode 
>> causes
>> the PLL to lose lock at least temporarily.
> 
> Losing lock on reconfiguration is entirely a separate matter from
> clock jitter.

Sure, I just wanted to report a case in which the implementation you mention 
does something which may be undesirable.

> The fractional multiplier works by essentially by
> alternating between the nearest integer multiplier values. This will
> be smoothed out by the loop filter, but it’s not going to vanish.

[…]

> Now DPLLLJ will presumably do better, but without actual specs the
> safe option is to avoid the fractional multiplier altogether.

Still FYI, using adpll_ti814x.c from the linux-omap3 tree from the Arago 
project (i.e. the one you are talking about) hacked to prefer searching for 
neighbouring m2 values to DCO switching works OK for us (i.e. resulting jitter 
is low enough for our audio applications).

—
Delio

--
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: Minimal support for dm814x

[Delio Brignoli]

On 18 Nov 2015, at 06:22, Matthijs van Duin  wrote:
> The PLL code looks pretty mediocre to me. In particular, they make no
> effort whatsoever to configure an exact ratio. It seems their
> algorithm uses whatever pre divider was already programmed,

I believe the implementors assumed the bootloader was setting up the PLL, its 
adjustment may have been an afterthought added in order to support PTP.

> This works in principle, but both minimizing the DCO and (often
> needlessly) using the fractional multiplier seem like recipes to
> maximize the clock jitter. Mind you, I don't know how much jitter
> we’re talking about here, I don't recall having seen specs about this.

We haven’t seen any specs either but testing shows that changing DCO mode 
causes the PLL to lose lock at least temporarily.

—
Delio



--
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, am335x: add support for the bosch shc board

[Heiko Schocher]

Hello Dave,

Am 17.11.2015 um 22:29 schrieb Dave Gerlach:

Hi,
On 11/17/2015 02:24 AM, Heiko Schocher wrote:

add support for the am335x based shc board.

UART: 0-2 and 4
DRAM: 512 MiB
MMC:  OMAP SD/MMC: 0 @ 26 MHz
   OMAP SD/MMC: 1 @ 26 MHz
I2C:  at24 eeprom, pcf8563
USB:  USB1 (host)

Signed-off-by: Heiko Schocher 
---
The following patches are needed to get all working
for the shc board:
- disable clkout on pcf8563
   accepted.
   http://www.spinics.net/lists/devicetree/msg98542.html

- leds: leds-gpio: add shutdown function
   accepted.
   https://lkml.org/lkml/2015/10/13/169

- net: phy: smsc: disable energy detect mode
   accepted
   [PATCH v2 2/2] net: phy: smsc: disable energy detect mode
   https://lkml.org/lkml/2015/10/17/2
   [PATCH v2 1/2] drivers: net: cpsw: add phy-handle parsing
   https://lkml.org/lkml/2015/10/17/4

- ARM: OMAP2+: omap_hwmod: Introduce ti,no-init dt property
   http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/328204.html
   @Dave: What is the current state of this patch?
   I have the same problem here on this am335x based board



A different approach is being taken for resolving the issue of rtc hwmod on 
am43x epos evm [1],
which is what I was attempting to solve with the patch you have linked. We 
decided to avoid changing
omap_hwmod code and I haven't been pursuing the ti,no-init flag anymore.


Maybe I overlook something, but I cannot see, how [1] solves the RTC
hwmod problem on am335x SoC based boards. Not all boards have this problem,
so the RTC hwmod cannot be disabled for all am335x boards ...

It must be somehow configurable for boards ... I have am335x boards
which use the rtc from the SoC


Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg121987.html


bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
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: omap2: Kconfig: select TWD and global timer on AM43xx devices

[Grygorii Strashko]

On 11/13/2015 06:39 PM, santosh shilimkar wrote:
> On 11/13/2015 5:07 AM, Mason wrote:
>> On 13/11/2015 13:48, Grygorii Strashko wrote:
>>> On 11/12/2015 08:06 PM, Felipe Balbi wrote:
 Make sure to tell the kernel that AM437x has
 TWD and global timers.

 Signed-off-by: Felipe Balbi 
 ---

 Hi Tony,

 now that all dependencies are in place, we can
 finally enable twd and global_timer for AM437x.

> Is AM437x SMP SOC ? 

No. But it has ARM TWD and GT

> Is TWD on AM437x works in low power states ?

No. But TWD, seems, is not a problem here if omap gp timer
can be used as broadcast device.

> Probably I haven't followed the recent updates, but does
> the TWD supports C3STOP on UP systems ? The broadcast
> code was SMP only in past, and TWD use to die in
> low power state on past OMAP SOCs.
> 
> If either of these are still the issue then
> TWD shouldn't be used.
> 

Yep. I see the problem with ARM Global timer here if
CPUIdle is enabled and ARM Global timer is selected as
clocksource device.

I think, it will be right thing to disable "global_timer"
and "local_timer" nodes in am437x.dtsi by default - if
someone would like to use them then those nodes have
to be enabled explicitly in board file.
(TWD timer will be enabled on OMAP multi SoC build
 irrespectively of HAVE_ARM_TWD is selected for am437x or not,
 because it will be selected for omap4). 
I've just sent corresponding patch: 
 http://www.spinics.net/lists/arm-kernel/msg461141.html

Also, probably, it could be reasonable to:
- make ARM_GLOBAL_TIMER fully selectable option and allow select it from 
defconfig.

- or - update this patch as below
-   select ARM_GLOBAL_TIMER
-   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+   select ARM_GLOBAL_TIMER if !CPU_IDLE
+   select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK if ARM_GLOBAL_TIMER



Thanks.
-- 
regards,
-grygorii
--
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: [4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Mark Rutland]

On Wed, Nov 18, 2015 at 04:01:55PM +0200, Grygorii Strashko wrote:
> Keep ARM TWD and Global timer's nodes disabled by default - if someone
> would like to use them then those nodes have to be enabled explicitly
> in board file.
> 
> The reason for this change is:
> - ARM TWD is not always-on timer on am437x and it will stop in low
>   CPUIdle states and, therefore, broadcast timer has to configured
>   properly if CPU_IDLE=y.
> - ARM Global timer is not always-on timer on am437x and it can't be
>   used as clocksource device if CPU_IDLE=y.

I don't understand. What timer do you use in the absence of a TWD, and
if it is better why is it not used even if TWD is present?

> - ARM Global timer driver doesn't support CPUfreq now.

Surely that should be fixed in the driver (e.g. make it fail to probe if
CPUfreq is present)? It's broken for any other users too...

Mark.

> Cc: Felipe Balbi 
> Cc: Santosh Shilimkar 
> Signed-off-by: Grygorii Strashko 
> ---
>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index d83ff9c..11376e3 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -75,6 +75,7 @@
>   interrupts = ;
>   interrupt-parent = <>;
>   clocks = <_mpu_m2_ck>;
> + status = "disabled";
>   };
>  
>   local_timer: timer@48240600 {
> @@ -83,6 +84,7 @@
>   interrupts = ;
>   interrupt-parent = <>;
>   clocks = <_mpu_m2_ck>;
> + status = "disabled";
>   };
>  
>   l2-cache-controller@48242000 {
> -- 
> 2.6.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Peter Ujfalusi]

Hi Vinod,

bringing this old thread back to life as I just started to work on this.

On 06/24/2015 07:24 PM, Vinod Koul wrote:

>> We would end up with the following APIs, all returning with error code on 
>> failure:
>> dma_request_slave_channel(dev, name);
>> dma_request_channel_legacy(mask, fn, fn_param);
>> dma_request_slave_channel_compat(mask, fn, fn_param, dev, name);
>> dma_request_any_channel(mask);
> This is good idea but still we end up with 4 APIs. Why not just converge to
> two API, one legacy + memcpy + filer fn and one untimate API for slave?

Looked at the current API and it's use and, well, it is a bit confusing.

What I hoped that we can separate users to two category:
1. Slave channel requests, where we request a specific channel to handle HW
requests/triggers.
For this we could have:
dma_request_slave_channel(dev, name, fn, fn_param);

In DT/ACPI only drivers we can NULL out the fn and fn_param, in pure legacy
mode we null out the name, I would keep the dev so we could print dev specific
error in dmaengine core, but it could be optional, IN case of drivers used
both DT/ACPI and legacy mode all parameter can be filled and the core will
decide what to do.
For the legacy needs the dmaengine code would provide the mask dows with
DMA_SLAVE flag set.

2. non slave channel requests, where only the functionality matters, like
memcpy, interleaved, memset, etc.
We could have a simple:
dma_request_channel(mask);

But looking at the drivers using dmaengine legacy dma_request_channel() API:
Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG
drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY

as examples.
Not sure how valid are these...

Some drivers do pass fn and fn_param when requesting channel for DMA_MEMCPY
drivers/misc/mic/host/mic_device.h
drivers/mtd/nand/fsmc_nand.c
sound/soc/intel/common/sst-firmware.c (well, this request DMA_SLAVE capability
at the same time).

Some driver sets the fn_param w/o fn, which means fn_param is ignored.

So the
dma_request_slave_channel(dev, name, fn, fn_param);
dma_request_channel(mask);

almost covers the current users and would be pretty clean ;)

If we add the mask to the slave channel API - which will become universal,
drop in replacement for dma_request_channel, and we might have only one API:

dma_request_channel(dev, name, mask, fn, fn_param);

> 
> Internally we may have 4 APIs for cleaner handling...
> 
> Thoughts... ??

Yes, as we need to arrange the code internally to keep things neat.

-- 
Péter
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Arnd Bergmann]

On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
> 2. non slave channel requests, where only the functionality matters, like
> memcpy, interleaved, memset, etc.
> We could have a simple:
> dma_request_channel(mask);
> 
> But looking at the drivers using dmaengine legacy dma_request_channel() API:
> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
> drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG
> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
> 
> as examples.
> Not sure how valid are these...

It's usually not much harder to separate out the legacy case from
the normal dma_request_slave_channel_reason(), so those drivers don't
really need to use the unified compat API.

Arnd
--
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 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()

[Peter Ujfalusi]

On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>> 2. non slave channel requests, where only the functionality matters, like
>> memcpy, interleaved, memset, etc.
>> We could have a simple:
>> dma_request_channel(mask);
>>
>> But looking at the drivers using dmaengine legacy dma_request_channel() API:
>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>> drivers/misc/carma/carma-fpga.c 
>> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
>> drivers/media/platform/soc_camera/mx3_camera.c  DMA_SLAVE|DMA_PRIVATE
>> sound/soc/intel/common/sst-firmware.c   DMA_SLAVE|DMA_MEMCPY
>>
>> as examples.
>> Not sure how valid are these...
> 
> It's usually not much harder to separate out the legacy case from
> the normal dma_request_slave_channel_reason(), so those drivers don't
> really need to use the unified compat API.

The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
Currently there is no way to get the reason why the dma channel request fails
when using the _compat() version of the API, which is used by drivers which
can be used in DT or in legacy mode as well. Sure, they all could have local
if(){}else{} for handling this, but it is not a nice thing.

As it was discussed instead of adding the _reason() version for the _compat
call, we should simplify the dmaengine API for getting the channel and at the
same time we will have ERR_PTR returned instead of NULL.

-- 
Péter
--
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

[4.4-rc][PATCH] ARM: dts: am4372: disable arm twd and global timer's nodes

[Grygorii Strashko]

Keep ARM TWD and Global timer's nodes disabled by default - if someone
would like to use them then those nodes have to be enabled explicitly
in board file.

The reason for this change is:
- ARM TWD is not always-on timer on am437x and it will stop in low
  CPUIdle states and, therefore, broadcast timer has to configured
  properly if CPU_IDLE=y.
- ARM Global timer is not always-on timer on am437x and it can't be
  used as clocksource device if CPU_IDLE=y.
- ARM Global timer driver doesn't support CPUfreq now.

Cc: Felipe Balbi 
Cc: Santosh Shilimkar 
Signed-off-by: Grygorii Strashko 
---
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..11376e3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -75,6 +75,7 @@
interrupts = ;
interrupt-parent = <>;
clocks = <_mpu_m2_ck>;
+   status = "disabled";
};
 
local_timer: timer@48240600 {
@@ -83,6 +84,7 @@
interrupts = ;
interrupt-parent = <>;
clocks = <_mpu_m2_ck>;
+   status = "disabled";
};
 
l2-cache-controller@48242000 {
-- 
2.6.3

--
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] net: cpsw: Fix ethernet regression for dm814x

[Tony Lindgren]

Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
id to common file") started using of_machine_is_compatible for detecting
type but missed at dm8148 causing Ethernet to stop working.

Let's fix the issue by adding handling for dm814x.

Cc: Mugunthan V N 
Signed-off-by: Tony Lindgren 
---
 drivers/net/ethernet/ti/cpsw-common.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -78,6 +78,9 @@ static int cpsw_am33xx_cm_get_macid(struct device *dev, u16 
offset, int slave,
 
 int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr)
 {
+   if (of_machine_is_compatible("ti,dm8148"))
+   return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+
if (of_machine_is_compatible("ti,am33xx"))
return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
 
-- 
2.6.2

--
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] clk: gpio: Get parent clk names already in of_gpio_clk_setup()

[Stephen Boyd]

On 11/17, Jyri Sarha wrote:
> Get parent clk names already in of_gpio_clk_setup() and store the
> names in struct clk_gpio_delayed_register_data. of_clk_get_parent_name()
> can not be called in struct of_clk_provider's get() callback since it
> may make a recursive call to of_clk_get_from_provider() and this in turn
> tries to recursively lock of_clk_mutex.
> 
> Signed-off-by: Jyri Sarha 
> Cc: Sergej Sawazki 
> ---
> Something has changed in Linux mainline so that getting the clk
> parent names in struct of_clk_provider's get() callback does not work
> anymore. This patch should fix the problem.

Something would be commit 0a4807c2f9a4 (clk: Make
of_clk_get_parent_name() robust with #clock-cells = 1, 2015-10-14)?

The patch looks good. Given that there's one user of this code in
mainline I'll push this as a fix for v4.4.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 01/39] pinctrl: Move am4372 and dra7 macros to the the SoC header files

[Tony Lindgren]

* Javier Martinez Canillas  [151117 05:51]:
> Hello Linus,
> 
> On 11/17/2015 10:47 AM, Linus Walleij wrote:
> > On Fri, Nov 13, 2015 at 5:53 AM, Javier Martinez Canillas
> >  wrote:
> > 
> >> The  header file defines a set of macros
> >> for different SoCs families that falls under the OMAP sub-arch, that
> >> allow to define the padconf register physical address instead of the
> >> register offset from the padconf base.
> >>
> >> But the am43xx and dra7xx SoCs families have their own pinctrl header
> >> file so the DTS using these SoCs aren't able to use the AM4372_IOPAD()
> >> and DRA7XX_CORE_IOPAD() macros since  is
> >> not included.
> >>
> >> Move the macros to the correct header files so can be used by the DTS.
> >>
> >> Signed-off-by: Javier Martinez Canillas 
> > 
> > I need Tony's ACK on this.
> >
> 
> OK, I believe he was waiting for yours to pick the series though ;)

Yeah probably best to keep this series together if you're OK with that.

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] net: cpsw: Fix ethernet regression for dm814x

[Mugunthan V N]

On Thursday 19 November 2015 06:57 AM, Tony Lindgren wrote:
> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
> id to common file") started using of_machine_is_compatible for detecting
> type but missed at dm8148 causing Ethernet to stop working.
> 
> Let's fix the issue by adding handling for dm814x.
> 
> Cc: Mugunthan V N 
> Signed-off-by: Tony Lindgren 

Acked-by: Mugunthnan V N 

Regards
Mugunthan V N
--
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 0/2] adding spi alias for qspi

[Mugunthan V N]

Adding missed spi alias for qspi which helps probe the qspi
device in U-Boot.

Mugunthan V N (2):
  dts: dra7: add spi alias for qspi
  arm: dts: am4372: add spi alias for qspi

 arch/arm/boot/dts/am4372.dtsi | 1 +
 arch/arm/boot/dts/dra7.dtsi   | 1 +
 2 files changed, 2 insertions(+)

-- 
2.6.2.280.g74301d6

--
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 1/2] dts: dra7: add spi alias for qspi

[Mugunthan V N]

Set the alias for qspi to spi0

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index bc672fb..b2badf9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -41,6 +41,7 @@
ethernet1 = _emac1;
d_can0 = 
d_can1 = 
+   spi0 = 
};
 
timer {
-- 
2.6.2.280.g74301d6

--
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 2/2] arm: dts: am4372: add spi alias for qspi

[Mugunthan V N]

Set the alias for qspi to spi0

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..bb03b80 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -30,6 +30,7 @@
serial5 = 
ethernet0 = _emac0;
ethernet1 = _emac1;
+   spi0 = 
};
 
cpus {
-- 
2.6.2.280.g74301d6

--
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