Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

2015-10-22 Thread Felipe Balbi 

Hi,

I just noticed that commit 073db4a51ee4 (mtd: fix: avoid race condition
when accessing mtd->usecount) caused a regression at least when removing
m25p80. Wonder if you guys would know of a quick fix, other than
reverting $commit in HEAD (yes, that makes the problem go away, but
regresses on what $commit tried to fix, of course).

More info about the regression follows, together with bisection log:

# modprobe -r m25p80
[   53.419251] 
[   53.420838] ==
[   53.427300] [ INFO: possible circular locking dependency detected ]
[   53.433865] 4.3.0-rc6 #96 Not tainted
[   53.437686] ---
[   53.444220] modprobe/372 is trying to acquire lock:
[   53.449320]  (>lock){+.+...}, at: [] 
del_mtd_blktrans_dev+0x80/0xdc
[   53.457271] 
[   53.457271] but task is already holding lock:
[   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
del_mtd_device+0x18/0x100
[   53.471321] 
[   53.471321] which lock already depends on the new lock.
[   53.471321] 
[   53.479856] 
[   53.479856] the existing dependency chain (in reverse order) is:
[   53.487660] 
-> #1 (mtd_table_mutex){+.+.+.}:
[   53.492331][] blktrans_open+0x34/0x1a4
[   53.497879][] __blkdev_get+0xc4/0x3b0
[   53.503364][] blkdev_get+0x108/0x320
[   53.508743][] do_dentry_open+0x218/0x314
[   53.514496][] path_openat+0x4c0/0xf9c
[   53.519959][] do_filp_open+0x5c/0xc0
[   53.525336][] do_sys_open+0xfc/0x1cc
[   53.530716][] ret_fast_syscall+0x0/0x1c
[   53.536375] 
-> #0 (>lock){+.+...}:
[   53.540587][] mutex_lock_nested+0x38/0x3cc
[   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
[   53.552606][] blktrans_notify_remove+0x7c/0x84
[   53.558891][] del_mtd_device+0x74/0x100
[   53.564544][] del_mtd_partitions+0x80/0xc8
[   53.570451][] mtd_device_unregister+0x24/0x48
[   53.576637][] spi_drv_remove+0x1c/0x34
[   53.582207][] __device_release_driver+0x88/0x114
[   53.588663][] device_release_driver+0x20/0x2c
[   53.594843][] bus_remove_device+0xd8/0x108
[   53.600748][] device_del+0x10c/0x210
[   53.606127][] device_unregister+0xc/0x20
[   53.611849][] __unregister+0x10/0x20
[   53.617211][] device_for_each_child+0x50/0x7c
[   53.623387][] spi_unregister_master+0x58/0x8c
[   53.629578][] release_nodes+0x15c/0x1c8
[   53.635223][] __device_release_driver+0x90/0x114
[   53.641689][] driver_detach+0xb4/0xb8
[   53.647147][] bus_remove_driver+0x4c/0xa0
[   53.652970][] SyS_delete_module+0x11c/0x1e4
[   53.658976][] ret_fast_syscall+0x0/0x1c
[   53.664621] 
[   53.664621] other info that might help us debug this:
[   53.664621] 
[   53.672979]  Possible unsafe locking scenario:
[   53.672979] 
[   53.679169]CPU0CPU1
[   53.683900]
[   53.688633]   lock(mtd_table_mutex);
[   53.692383]lock(>lock);
[   53.698306]lock(mtd_table_mutex);
[   53.704658]   lock(>lock);
[   53.707946] 
[   53.707946]  *** DEADLOCK ***
[   53.707946] 
[   53.714123] 5 locks held by modprobe/372:
[   53.718305]  #0:  (>mutex){..}, at: [] 
driver_detach+0x44/0xb8
[   53.726147]  #1:  (>mutex){..}, at: [] 
driver_detach+0x50/0xb8
[   53.733985]  #2:  (>mutex){..}, at: [] 
device_release_driver+0x18/0x2c
[   53.742541]  #3:  (mtd_partitions_mutex){+.+.+.}, at: [] 
del_mtd_partitions+0x1c/0xc8
[   53.751656]  #4:  (mtd_table_mutex){+.+.+.}, at: [] 
del_mtd_device+0x18/0x100
[   53.760048] 
[   53.760048] stack backtrace:
[   53.764591] CPU: 0 PID: 372 Comm: modprobe Not tainted 4.3.0-rc6 #96
[   53.771217] Hardware name: Generic AM43 (Flattened Device Tree)
[   53.777419] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   53.785511] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[   53.793063] [] (dump_stack) from [] 
(print_circular_bug+0x1c8/0x30c)
[   53.801500] [] (print_circular_bug) from [] 
(__lock_acquire+0x1a48/0x1cd8)
[   53.810480] [] (__lock_acquire) from [] 
(lock_acquire+0xac/0x12c)
[   53.818649] [] (lock_acquire) from [] 
(mutex_lock_nested+0x38/0x3cc)
[   53.827103] [] (mutex_lock_nested) from [] 
(del_mtd_blktrans_dev+0x80/0xdc)
[   53.836199] [] (del_mtd_blktrans_dev) from [] 
(blktrans_notify_remove+0x7c/0x84)
[   53.845735] [] (blktrans_notify_remove) from [] 
(del_mtd_device+0x74/0x100)
[   53.854833] [] (del_mtd_device) from [] 
(del_mtd_partitions+0x80/0xc8)
[   53.863469] [] (del_mtd_partitions) from [] 
(mtd_device_unregister+0x24/0x48)
[   53.872733] [] (mtd_device_unregister) from [] 
(spi_drv_remove+0x1c/0x34)
[   53.881633] [] (spi_drv_remove) from [] 
(__device_release_driver+0x88/0x114)
[   53.890788] [] (__device_release_driver) from [] 
(device_release_driver+0x20/0x2c)
[   53.900483] []

NULL pointer deref when reloading snd_soc_simple_card

2015-10-22 Thread Felipe Balbi 

Hi,

I just triggered a NULL point deref with the following commands running
on AM437x SK board. This is with v4.3-rc6:

modprobe -r snd_soc_simple_card
sleep 1
modprobe snd_soc_simple_card
sleep 1

details below:

[  228.020921] Unable to handle kernel NULL pointer dereference at virtual 
address 00f8
[  228.029546] pgd = ed4bc000
[  228.032375] [00f8] *pgd=
[  228.036154] Internal error: Oops: 5 [#1] SMP ARM
[  228.040968] Modules linked in: snd_soc_simple_card(+) matrix_keypad 
matrix_keymap pwm_bl xhci_plat_hcd xhci_hcd usbcore joydev m25p80 spi_nor 
lis3lv02d_i2c lis3lv02d input_polldev cpufreq_dt thermal_sys hwmon dwc3_omap 
extcon tps65218_pwrbutton omap_wdt spi_ti_qspi evdev rtc_omap leds_gpio 
led_class dwc3 udc_core usb_common omapfb cfbfillrect cfbimgblt cfbcopyarea 
panel_dpi snd_soc_tlv320aic3x snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap 
snd_soc_core omapdss snd_compress snd_pcm_dmaengine snd_pcm pwm_tiecap 
snd_timer snd soundcore phy_omap_usb2 autofs4 [last unloaded: 
snd_soc_simple_card]
[  228.096008] CPU: 0 PID: 710 Comm: modprobe Not tainted 
4.3.0-rc6-1-gada6475ae6e4 #97
[  228.104436] Hardware name: Generic AM43 (Flattened Device Tree)
[  228.110608] task: ed4b9140 ti: ed52e000 task.ti: ed52e000
[  228.116370] PC is at dapm_wcache_lookup+0x50/0x7c [snd_soc_core]
[  228.122664] LR is at dapm_wcache_lookup+0x38/0x7c [snd_soc_core]
[  228.128922] pc : []lr : []psr: a0070013
[  228.128922] sp : ed52fba8  ip : 0005  fp : 
[  228.140883] r10: bf17d238  r9 : bf1f138c  r8 : bf1f616c
[  228.146327] r7 : bf1f138c  r6 : bf1f616c  r5 : ee6f5158  r4 : 00f4
[  228.153126] r3 : 0100  r2 : 0052  r1 : ed1057c1  r0 : 
[  228.159925] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  228.167354] Control: 10c5387d  Table: ad4bc059  DAC: 0051
[  228.173339] Process modprobe (pid: 710, stack limit = 0xed52e218)
[  228.179689] Stack: (0xed52fba8 to 0xed53)
[  228.184233] fba0:    ee7c58c0 bf1f6050 bf16f244 
 ed52fc28
[  228.192765] fbc0: ee577800 c1014a44  c06430d8 0001  
ee6c6e90 ee6f50a0
[  228.201294] fbe0:    c09c3354 60070013 c00943bc 
ed4b9700 0004
[  228.209835] fc00: 0004 ed4b9140 0006 bf1f138c bf1ef834 c0091884 
c063f37c ed4b9140
[  228.218365] fc20: 0001 c118a28c ed4b9140 c00919e8 ee6f506c 60070013 
ee6f5070 c063f37c
[  228.226899] fc40: 0001  bf16f430 0003 0004 ed4b9140 
0006 
[  228.235417] fc60: bf1ef834 c0091884 c0641060 bf1f138c  ee7c58c0 
0004 001b
[  228.243938] fc80: bf1f138c bf17d238  bf16f468  0012 
ee7c58c0 ee7c58c0
[  228.252463] fca0: ee6c6e90 ee6c6e90 0004 ee6c6ec0  bf1ef834 
 bf1efcec
[  228.260989] fcc0: ee7c5828  ee7c5810 ee6f5010 ee7c58c0 ee7c5858 
ed496010 bf169ef4
[  228.269506] fce0: ee6f5180 0002 0634 ee6f5010   
 
[  228.278029] fd00: ed440e0c bf16cb2c  ee6f5020 ee6f5180 bf17fd60 
0001 ee6f5028
[  228.286547] fd20: ee6f5168 60070013   3304  
ee178410 ee6f5010
[  228.295065] fd40: ed105c90 ee6f5010 ee178410 ee178410 ee178400 0001 
12f9f228 bf17968c
[  228.303583] fd60: ee6f5010 fdfb 0001 87d8 ee178410 bf0faa38 
 ee178410
[  228.312108] fd80: ee178410 ee178410 ee178410 bf0fb28c fdfb 004e 
ed060e00 c03dff28
[  228.320626] fda0: ee178410 c11be018 bf0fb28c  004e c03de5dc 
ee178410 bf0fb28c
[  228.329143] fdc0: ee178444 c098df20  c03de76c  bf0fb28c 
c03de6d8 c03dca40
[  228.337666] fde0: ee0362a4 ee179f10 bf0fb28c ed462ec0  c03ddba4 
bf0fb080 c09123a0
[  228.346188] fe00: ed060d40 bf0fb28c c09123a0 ed060d40 bf0fd000 c03defb0 
c09123a0 c09123a0
[  228.354713] fe20: ed060d40 c0009804 60070093    
000f 
[  228.363240] fe40: ef7c4464 4000 002e c0091ccc ed060e40 00d0 
00d0 c0162850
[  228.371760] fe60: ed52ff58 c0091ccc c090e108 eec0 a0070013 bf0fb300 
bf0fb300 c09c34a8
[  228.380285] fe80: ed060e40 bf0fb300 bf0fb348 0001 12f9f228 c011b55c 
ed060e08 bf0fb300
[  228.388815] fea0: ed52ff58 c09c34a8 ed060e08 c00cc6cc bf0fb30c 7fff 
 c00c9e60
[  228.397340] fec0: c119bfa4 bf0fb458 c090e990 bf0fb51c f07fa7bc bf0fb30c 
 c064c2c0
[  228.405863] fee0: f07cd000 0002d80c 02e60649  000f  
 
[  228.414388] ff00:       
 
[  228.422911] ff20:     0170  
0003 7f606ddc
[  228.431432] ff40: 017b c000f8e4 ed52e000  7f61a2e8 c00ccf24 
f07cd000 0002d80c
[  228.439952] ff60: f07fa0dc f07eebe5 f07ef600 1690 19d0  
 
[  228.448475] ff80: 002c 002d 0014 0018 000f  
7f607a28 
[

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

2015-10-22 Thread Brian Norris 
Hi Felipe,

First of all, this is only a quick response. I could easily be missing
something obvious.

On Thu, Oct 22, 2015 at 02:01:02PM -0500, Felipe Balbi wrote:
> 
> Hi,
> 
> I just noticed that commit 073db4a51ee4 (mtd: fix: avoid race condition
> when accessing mtd->usecount) caused a regression at least when removing
> m25p80. Wonder if you guys would know of a quick fix, other than
> reverting $commit in HEAD (yes, that makes the problem go away, but
> regresses on what $commit tried to fix, of course).
> 
> More info about the regression follows, together with bisection log:

Not all deadlocks alleged by lockdep are true deadlocks. Are you able to
reproduce a real deadlock? (I know, it's not always easy to hit, so I'm
not discounting this based on lack of evidence.)

In particular, I think something like this warning was mentioned
previously, and I looked into it a bit but didn't have the time to
figure out for sure (and figure out how to squash the potential false
positive). Hence, I'm responding now, even if I'm not 100% sure. More
below.

> # modprobe -r m25p80
> [   53.419251] 
> [   53.420838] ==
> [   53.427300] [ INFO: possible circular locking dependency detected ]
> [   53.433865] 4.3.0-rc6 #96 Not tainted
> [   53.437686] ---
> [   53.444220] modprobe/372 is trying to acquire lock:
> [   53.449320]  (>lock){+.+...}, at: [] 
> del_mtd_blktrans_dev+0x80/0xdc
> [   53.457271] 
> [   53.457271] but task is already holding lock:
> [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
> del_mtd_device+0x18/0x100
> [   53.471321] 
> [   53.471321] which lock already depends on the new lock.
> [   53.471321] 
> [   53.479856] 
> [   53.479856] the existing dependency chain (in reverse order) is:
> [   53.487660] 
> -> #1 (mtd_table_mutex){+.+.+.}:
> [   53.492331][] blktrans_open+0x34/0x1a4
> [   53.497879][] __blkdev_get+0xc4/0x3b0
> [   53.503364][] blkdev_get+0x108/0x320
> [   53.508743][] do_dentry_open+0x218/0x314
> [   53.514496][] path_openat+0x4c0/0xf9c
> [   53.519959][] do_filp_open+0x5c/0xc0
> [   53.525336][] do_sys_open+0xfc/0x1cc
> [   53.530716][] ret_fast_syscall+0x0/0x1c
> [   53.536375] 
> -> #0 (>lock){+.+...}:
> [   53.540587][] mutex_lock_nested+0x38/0x3cc
> [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
> [   53.552606][] blktrans_notify_remove+0x7c/0x84
> [   53.558891][] del_mtd_device+0x74/0x100
> [   53.564544][] del_mtd_partitions+0x80/0xc8
> [   53.570451][] mtd_device_unregister+0x24/0x48
> [   53.576637][] spi_drv_remove+0x1c/0x34
> [   53.582207][] __device_release_driver+0x88/0x114
> [   53.588663][] device_release_driver+0x20/0x2c
> [   53.594843][] bus_remove_device+0xd8/0x108
> [   53.600748][] device_del+0x10c/0x210
> [   53.606127][] device_unregister+0xc/0x20
> [   53.611849][] __unregister+0x10/0x20
> [   53.617211][] device_for_each_child+0x50/0x7c
> [   53.623387][] spi_unregister_master+0x58/0x8c
> [   53.629578][] release_nodes+0x15c/0x1c8
> [   53.635223][] __device_release_driver+0x90/0x114
> [   53.641689][] driver_detach+0xb4/0xb8
> [   53.647147][] bus_remove_driver+0x4c/0xa0
> [   53.652970][] SyS_delete_module+0x11c/0x1e4
> [   53.658976][] ret_fast_syscall+0x0/0x1c

Actually, the more I look at this, the more I think the warning is
probably correct. I might have been thinking of a different false
positive.

Tentatively: I think the right fix might be to reverse the ordering of
acquire/release of the mtd_table_mutex and dev->lock throughout
mtd_blkdevs.c. See below.

> [   53.664621] 
> [   53.664621] other info that might help us debug this:
> [   53.664621] 
> [   53.672979]  Possible unsafe locking scenario:
> [   53.672979] 
> [   53.679169]CPU0CPU1
> [   53.683900]
> [   53.688633]   lock(mtd_table_mutex);
> [   53.692383]lock(>lock);
> [   53.698306]lock(mtd_table_mutex);
> [   53.704658]   lock(>lock);
> [   53.707946] 
> [   53.707946]  *** DEADLOCK ***
> [   53.707946] 
> [   53.714123] 5 locks held by modprobe/372:
> [   53.718305]  #0:  (>mutex){..}, at: [] 
> driver_detach+0x44/0xb8
> [   53.726147]  #1:  (>mutex){..}, at: [] 
> driver_detach+0x50/0xb8
> [   53.733985]  #2:  (>mutex){..}, at: [] 
> device_release_driver+0x18/0x2c
> [   53.742541]  #3:  (mtd_partitions_mutex){+.+.+.}, at: [] 
> del_mtd_partitions+0x1c/0xc8
> [   53.751656]  #4:  (mtd_table_mutex){+.+.+.}, at: [] 
> del_mtd_device+0x18/0x100
> [   53.760048] 
> [   53.760048] stack backtrace:
> [   53.764591] CPU: 0 PID: 372 Comm: modprobe Not tainted 4.3.0-rc6 #96
> [   53.771217] Hardware name: Generic

Re: [PATCH/RESEND] ARM: Remove __ref on hotplug cpu die path

2015-10-22 Thread Olof Johansson 
On Mon, Oct 19, 2015 at 01:05:33PM -0700, Stephen Boyd wrote:
> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
> 
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
> 
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.
> 
> Cc: Tony Lindgren 
> Acked-by: Barry Song 
> Acked-by: Andy Gross 
> Acked-by: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: Stephen Warren 
> Acked-by: Thierry Reding 
> Cc: Alexandre Courbot 
> Acked-by: Linus Walleij 
> Acked-by: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Mark Rutland 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Collected the acks and resent.

Applied to next/cleanup. Thanks!


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

ALSA DMA ping-pong

2015-10-22 Thread Ran Shalit 
Hello,

I hope someone can help me understand the concept of ping-pong dma with ALSA.
I am using davinci soc: /sound/soc/davinci/davinci_pcm.c
But I am not sure if it using ping-pong dma or not.
In the header of "davinci_pcm_enqueue_dma" function it states "Not
used with ping/pong", but inside I see that it use period parameter in
order to set the offset inside the dma buffer which is used.
So, does it mean that ping-pong is used or not ?

/*
 * Not used with ping/pong
 */
static void davinci_pcm_enqueue_dma(struct snd_pcm_substream *substream)
.

period_size = snd_pcm_lib_period_bytes(substream);
dma_offset = prtd->period * period_size;
dma_pos = runtime->dma_addr + dma_offset;



acnt = prtd->params->acnt;
edma_set_src(link, src, INCR, W8BIT);
edma_set_dest(link, dst, INCR, W8BIT);
..
}

Regards,
Ran
--
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/4] Cleanup legacy OMAP IOMMU device creation

2015-10-22 Thread Suman Anna 
Hi Tony,

On 09/16/2015 06:48 PM, Suman Anna wrote:
> Hi Tony,
> 
> The following series removes the legacy platform device creation
> logic for OMAP IOMMU devices. I will cleanup the legacy support
> from the OMAP IOMMU driver in a subsequent merge window after
> this series makes it to mainline.
> 
> Patches are based on 4.3-rc1 + the OMAP3 ISP instantiation cleanup
> patch [1]. All the patches need to be picked up sequentially,
> otherwise a NULL pointer dereference crash might be seen on OMAP3
> legacy boots as the dev attribute structure is deferenced directly
> in mach-omap2/omap-iommu.c during platform data creation. Also, the
> last patch removes the structure definition altogether, so will
> cause build issues if picked separately from the hwmod cleanup
> patches.
> 
> I do not have any boards where I can still perform a legacy-style
> boot, so patches verified using DT-boot only.
> 
> regards
> Suman
> 
> [1] https://patchwork.kernel.org/patch/6806891/
> 
> Suman Anna (4):
>   ARM: OMAP2+: Remove legacy device instantiation of IOMMUs
>   ARM: OMAP3: hwmod data: Remove legacy IOMMU data
>   ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs
>   ARM: OMAP2+: Remove omap_mmu_dev_attr structure

Ping on this series. You should be able to pick up atleast patch 1 if
not picking all, now that the OMAP3 ISP cleanup patch is staged in your
omap-for-4.4/cleanup branch.

Thanks
Suman

> 
>  arch/arm/mach-omap2/omap-iommu.c   | 66 
> --
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 42 ---
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 31 --
>  include/linux/platform_data/iommu-omap.h   |  9 
>  4 files changed, 148 deletions(-)
>  delete mode 100644 arch/arm/mach-omap2/omap-iommu.c
> 

--
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: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-22 Thread Tony Lindgren 
* Tony Lindgren  [151021 16:44]:
> Hi all,
> 
> I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> 
> ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> 
> With the commit above reverted things work fine with DMA and USB gadgets.
> 
> This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> 
> Anybody got ideas what might be wrong? Some wrong runtime PM usage
> under drivers/usb/musb?

Here's some more debug info on where things are different initializing
the USB gadgets. I added some printks and diffed the dmesg output. The
added calls from commit ddef08dd00f5 start with dd:


+dd __device_attach pm_runtime_put parent 480ab000.usb_otg_hs
+dd driver_probe_device pm_runtime_get_sync parent 0-0048
 twl4030_usb 4807.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module
+dd driver_probe_device pm_runtime_put parent 0-0048
+dd __device_attach pm_runtime_get_sync parent 480ab000.usb_otg_hs
+dd driver_probe_device pm_runtime_get_sync parent 480ab000.usb_otg_hs
 musb musb-hdrc.0.auto _pm_runtime_get_sync
 musb musb-hdrc.0.auto _pm_runtime_get_sync
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, 
HB-ISO Rx, HB-ISO Tx, SoftConn)
@@ -273,11 +695,24 @@
 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 usb usb1: Product: MUSB HDRC host driver
-usb usb1: Manufacturer: Linux 4.3.0-rc6-5-gb037ac9 musb-hcd
+usb usb1: Manufacturer: Linux 4.3.0-rc6-5-g24b084c musb-hcd
 usb usb1: SerialNumber: musb-hdrc.0.auto
+dd __device_attach pm_runtime_get_sync parent musb-hdrc.0.auto
+dd driver_probe_device pm_runtime_get_sync parent musb-hdrc.0.auto
+dd __device_attach pm_runtime_get_sync parent usb1
+dd driver_probe_device pm_runtime_get_sync parent usb1
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 1 port detected
+dd driver_probe_device pm_runtime_put parent usb1
+dd __device_attach pm_runtime_put parent usb1
+dd driver_probe_device pm_runtime_put parent musb-hdrc.0.auto
+dd __device_attach pm_runtime_put parent musb-hdrc.0.auto
 musb musb-hdrc.0.auto _pm_runtime_put
+dd driver_probe_device pm_runtime_put parent 480ab000.usb_otg_hs
+dd __device_attach pm_runtime_put parent 480ab000.usb_otg_hs
 modprobe: module 'usb_core' not found
 userial_init: registered 4 ttyGS* devices
 Mass Storage Function, version: 2009/09/11

The musb driver is using autosuspend like Felipe pointed out offline,
so maybe that's where things go wrong with commit ddef08dd00f5?

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: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

2015-10-22 Thread Felipe Balbi 

(fixing Tony's address)

Felipe Balbi  writes:
> Hi,
>
> I just noticed that commit 073db4a51ee4 (mtd: fix: avoid race condition
> when accessing mtd->usecount) caused a regression at least when removing
> m25p80. Wonder if you guys would know of a quick fix, other than
> reverting $commit in HEAD (yes, that makes the problem go away, but
> regresses on what $commit tried to fix, of course).
>
> More info about the regression follows, together with bisection log:
>
> # modprobe -r m25p80
> [   53.419251] 
> [   53.420838] ==
> [   53.427300] [ INFO: possible circular locking dependency detected ]
> [   53.433865] 4.3.0-rc6 #96 Not tainted
> [   53.437686] ---
> [   53.444220] modprobe/372 is trying to acquire lock:
> [   53.449320]  (>lock){+.+...}, at: [] 
> del_mtd_blktrans_dev+0x80/0xdc
> [   53.457271] 
> [   53.457271] but task is already holding lock:
> [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
> del_mtd_device+0x18/0x100
> [   53.471321] 
> [   53.471321] which lock already depends on the new lock.
> [   53.471321] 
> [   53.479856] 
> [   53.479856] the existing dependency chain (in reverse order) is:
> [   53.487660] 
> -> #1 (mtd_table_mutex){+.+.+.}:
> [   53.492331][] blktrans_open+0x34/0x1a4
> [   53.497879][] __blkdev_get+0xc4/0x3b0
> [   53.503364][] blkdev_get+0x108/0x320
> [   53.508743][] do_dentry_open+0x218/0x314
> [   53.514496][] path_openat+0x4c0/0xf9c
> [   53.519959][] do_filp_open+0x5c/0xc0
> [   53.525336][] do_sys_open+0xfc/0x1cc
> [   53.530716][] ret_fast_syscall+0x0/0x1c
> [   53.536375] 
> -> #0 (>lock){+.+...}:
> [   53.540587][] mutex_lock_nested+0x38/0x3cc
> [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
> [   53.552606][] blktrans_notify_remove+0x7c/0x84
> [   53.558891][] del_mtd_device+0x74/0x100
> [   53.564544][] del_mtd_partitions+0x80/0xc8
> [   53.570451][] mtd_device_unregister+0x24/0x48
> [   53.576637][] spi_drv_remove+0x1c/0x34
> [   53.582207][] __device_release_driver+0x88/0x114
> [   53.588663][] device_release_driver+0x20/0x2c
> [   53.594843][] bus_remove_device+0xd8/0x108
> [   53.600748][] device_del+0x10c/0x210
> [   53.606127][] device_unregister+0xc/0x20
> [   53.611849][] __unregister+0x10/0x20
> [   53.617211][] device_for_each_child+0x50/0x7c
> [   53.623387][] spi_unregister_master+0x58/0x8c
> [   53.629578][] release_nodes+0x15c/0x1c8
> [   53.635223][] __device_release_driver+0x90/0x114
> [   53.641689][] driver_detach+0xb4/0xb8
> [   53.647147][] bus_remove_driver+0x4c/0xa0
> [   53.652970][] SyS_delete_module+0x11c/0x1e4
> [   53.658976][] ret_fast_syscall+0x0/0x1c
> [   53.664621] 
> [   53.664621] other info that might help us debug this:
> [   53.664621] 
> [   53.672979]  Possible unsafe locking scenario:
> [   53.672979] 
> [   53.679169]CPU0CPU1
> [   53.683900]
> [   53.688633]   lock(mtd_table_mutex);
> [   53.692383]lock(>lock);
> [   53.698306]lock(mtd_table_mutex);
> [   53.704658]   lock(>lock);
> [   53.707946] 
> [   53.707946]  *** DEADLOCK ***
> [   53.707946] 
> [   53.714123] 5 locks held by modprobe/372:
> [   53.718305]  #0:  (>mutex){..}, at: [] 
> driver_detach+0x44/0xb8
> [   53.726147]  #1:  (>mutex){..}, at: [] 
> driver_detach+0x50/0xb8
> [   53.733985]  #2:  (>mutex){..}, at: [] 
> device_release_driver+0x18/0x2c
> [   53.742541]  #3:  (mtd_partitions_mutex){+.+.+.}, at: [] 
> del_mtd_partitions+0x1c/0xc8
> [   53.751656]  #4:  (mtd_table_mutex){+.+.+.}, at: [] 
> del_mtd_device+0x18/0x100
> [   53.760048] 
> [   53.760048] stack backtrace:
> [   53.764591] CPU: 0 PID: 372 Comm: modprobe Not tainted 4.3.0-rc6 #96
> [   53.771217] Hardware name: Generic AM43 (Flattened Device Tree)
> [   53.777419] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [   53.785511] [] (show_stack) from [] 
> (dump_stack+0x84/0x9c)
> [   53.793063] [] (dump_stack) from [] 
> (print_circular_bug+0x1c8/0x30c)
> [   53.801500] [] (print_circular_bug) from [] 
> (__lock_acquire+0x1a48/0x1cd8)
> [   53.810480] [] (__lock_acquire) from [] 
> (lock_acquire+0xac/0x12c)
> [   53.818649] [] (lock_acquire) from [] 
> (mutex_lock_nested+0x38/0x3cc)
> [   53.827103] [] (mutex_lock_nested) from [] 
> (del_mtd_blktrans_dev+0x80/0xdc)
> [   53.836199] [] (del_mtd_blktrans_dev) from [] 
> (blktrans_notify_remove+0x7c/0x84)
> [   53.845735] [] (blktrans_notify_remove) from [] 
> (del_mtd_device+0x74/0x100)
> [   53.854833] [] (del_mtd_device) from [] 
> (del_mtd_partitions+0x80/0xc8)
> [   53.863469] [] (del_mtd_partitions) from [] 
>

[PATCH 3/4] arm: dts: add dm816x pwm property to timers

2015-10-22 Thread Neil Armstrong 
Adds ti,timer-pwm property to timers 4 to 7 to permit usage of their
PWM output fonctionnality via the dmtimer driver.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index eee636d..51ad4a9 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -323,6 +323,7 @@
reg = <0x48044000 0x2000>;
interrupts = <92>;
ti,hwmods = "timer4";
+   ti,timer-pwm;
};

timer5: timer@48046000 {
@@ -330,6 +331,7 @@
reg = <0x48046000 0x2000>;
interrupts = <93>;
ti,hwmods = "timer5";
+   ti,timer-pwm;
};

timer6: timer@48048000 {
@@ -337,6 +339,7 @@
reg = <0x48048000 0x2000>;
interrupts = <94>;
ti,hwmods = "timer6";
+   ti,timer-pwm;
};

timer7: timer@4804a000 {
@@ -344,6 +347,7 @@
reg = <0x4804a000 0x2000>;
interrupts = <95>;
ti,hwmods = "timer7";
+   ti,timer-pwm;
};

uart1: uart@4802 {
-- 
1.9.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 0/4] arm: dts: complete dm816x device tree

2015-10-22 Thread Neil Armstrong 
In order to fix support for the dm816x platform, add missing bits in
the dm816x dtsi.

The last patch adds support for the omap4-hwspinlock.

Neil Armstrong (4):
  arm: dts: add dm816x missing #mbox-cells
  arm: dts: add dm816x missing spi DT dma handles
  arm: dts: add dm816x pwm property to timers
  arm: dts: Add omap4-hwspinlock support in dm816x

 arch/arm/boot/dts/dm816x.dtsi | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

-- 
1.9.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 1/4] arm: dts: add dm816x missing #mbox-cells

2015-10-22 Thread Neil Armstrong 
Add missing #mbox-cells for dm816x mbox DT node.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 3c99cfa..a7a34e4 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -218,6 +218,7 @@
reg = <0x480c8000 0x2000>;
interrupts = <77>;
ti,hwmods = "mailbox";
+   #mbox-cells = <1>;
ti,mbox-num-users = <4>;
ti,mbox-num-fifos = <12>;
mbox_dsp: mbox_dsp {
-- 
1.9.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 1/4] arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data

2015-10-22 Thread Neil Armstrong 
Add missing HWMOD_NO_IDLEST hwmod flag for entries no
having omap4 clkctrl values.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index b1288f5..6256052 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -144,6 +144,7 @@ static struct omap_hwmod dm81xx_l4_ls_hwmod = {
.name   = "l4_ls",
.clkdm_name = "alwon_l3s_clkdm",
.class  = _hwmod_class,
+   .flags  = HWMOD_NO_IDLEST,
 };

 /*
@@ -155,6 +156,7 @@ static struct omap_hwmod dm81xx_l4_hs_hwmod = {
.name   = "l4_hs",
.clkdm_name = "alwon_l3_med_clkdm",
.class  = _hwmod_class,
+   .flags  = HWMOD_NO_IDLEST,
 };

 /* L3 slow -> L4 ls peripheral interface running at 125MHz */
@@ -850,6 +852,7 @@ static struct omap_hwmod dm816x_emac0_hwmod = {
.name   = "emac0",
.clkdm_name = "alwon_ethernet_clkdm",
.class  = _emac_hwmod_class,
+   .flags  = HWMOD_NO_IDLEST,
 };

 static struct omap_hwmod_ocp_if dm81xx_l4_hs__emac0 = {
-- 
1.9.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 0/4] arm: omap2+: complete dm816x hwmod and clkdev

2015-10-22 Thread Neil Armstrong 
In order to fix support for the dm816x platform, add missing bits in
the 81xx hwmod data.

The clk related patch adds the missing clkdev entries to fix all source
selection in the dmtimer driver.

The last patch adds hwmod support of the spinbox module.

Neil Armstrong (4):
  arm: omap2+: add missing HWMOD_NO_IDLEST in 81xx hwmod data
  clk: ti816x: Add missing dmtimer clkdev entries
  arm: plat-omap: add DT support for ti,dm816-timer
  arm: omap2+: Add hwmod spinbox support for dm816x

 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 38 ++
 arch/arm/plat-omap/dmtimer.c   |  4 
 drivers/clk/ti/clk-816x.c  |  2 ++
 3 files changed, 44 insertions(+)

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

Re: Regression caused by 073db4a51ee43ccb827f54a4261c0583b028d5ab

2015-10-22 Thread Felipe Balbi 

Hi,

Brian Norris  writes:
> Hi Felipe,
>
> First of all, this is only a quick response. I could easily be missing
> something obvious.
>
> On Thu, Oct 22, 2015 at 02:01:02PM -0500, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> I just noticed that commit 073db4a51ee4 (mtd: fix: avoid race condition
>> when accessing mtd->usecount) caused a regression at least when removing
>> m25p80. Wonder if you guys would know of a quick fix, other than
>> reverting $commit in HEAD (yes, that makes the problem go away, but
>> regresses on what $commit tried to fix, of course).
>> 
>> More info about the regression follows, together with bisection log:
>
> Not all deadlocks alleged by lockdep are true deadlocks. Are you able to
> reproduce a real deadlock? (I know, it's not always easy to hit, so I'm
> not discounting this based on lack of evidence.)
>
> In particular, I think something like this warning was mentioned
> previously, and I looked into it a bit but didn't have the time to
> figure out for sure (and figure out how to squash the potential false
> positive). Hence, I'm responding now, even if I'm not 100% sure. More
> below.
>
>> # modprobe -r m25p80
>> [   53.419251] 
>> [   53.420838] ==
>> [   53.427300] [ INFO: possible circular locking dependency detected ]
>> [   53.433865] 4.3.0-rc6 #96 Not tainted
>> [   53.437686] ---
>> [   53.444220] modprobe/372 is trying to acquire lock:
>> [   53.449320]  (>lock){+.+...}, at: [] 
>> del_mtd_blktrans_dev+0x80/0xdc
>> [   53.457271] 
>> [   53.457271] but task is already holding lock:
>> [   53.463372]  (mtd_table_mutex){+.+.+.}, at: [] 
>> del_mtd_device+0x18/0x100
>> [   53.471321] 
>> [   53.471321] which lock already depends on the new lock.
>> [   53.471321] 
>> [   53.479856] 
>> [   53.479856] the existing dependency chain (in reverse order) is:
>> [   53.487660] 
>> -> #1 (mtd_table_mutex){+.+.+.}:
>> [   53.492331][] blktrans_open+0x34/0x1a4
>> [   53.497879][] __blkdev_get+0xc4/0x3b0
>> [   53.503364][] blkdev_get+0x108/0x320
>> [   53.508743][] do_dentry_open+0x218/0x314
>> [   53.514496][] path_openat+0x4c0/0xf9c
>> [   53.519959][] do_filp_open+0x5c/0xc0
>> [   53.525336][] do_sys_open+0xfc/0x1cc
>> [   53.530716][] ret_fast_syscall+0x0/0x1c
>> [   53.536375] 
>> -> #0 (>lock){+.+...}:
>> [   53.540587][] mutex_lock_nested+0x38/0x3cc
>> [   53.546504][] del_mtd_blktrans_dev+0x80/0xdc
>> [   53.552606][] blktrans_notify_remove+0x7c/0x84
>> [   53.558891][] del_mtd_device+0x74/0x100
>> [   53.564544][] del_mtd_partitions+0x80/0xc8
>> [   53.570451][] mtd_device_unregister+0x24/0x48
>> [   53.576637][] spi_drv_remove+0x1c/0x34
>> [   53.582207][] __device_release_driver+0x88/0x114
>> [   53.588663][] device_release_driver+0x20/0x2c
>> [   53.594843][] bus_remove_device+0xd8/0x108
>> [   53.600748][] device_del+0x10c/0x210
>> [   53.606127][] device_unregister+0xc/0x20
>> [   53.611849][] __unregister+0x10/0x20
>> [   53.617211][] device_for_each_child+0x50/0x7c
>> [   53.623387][] spi_unregister_master+0x58/0x8c
>> [   53.629578][] release_nodes+0x15c/0x1c8
>> [   53.635223][] __device_release_driver+0x90/0x114
>> [   53.641689][] driver_detach+0xb4/0xb8
>> [   53.647147][] bus_remove_driver+0x4c/0xa0
>> [   53.652970][] SyS_delete_module+0x11c/0x1e4
>> [   53.658976][] ret_fast_syscall+0x0/0x1c
>
> Actually, the more I look at this, the more I think the warning is
> probably correct. I might have been thinking of a different false
> positive.
>
> Tentatively: I think the right fix might be to reverse the ordering of
> acquire/release of the mtd_table_mutex and dev->lock throughout
> mtd_blkdevs.c. See below.
>
>> [   53.664621] 
>> [   53.664621] other info that might help us debug this:
>> [   53.664621] 
>> [   53.672979]  Possible unsafe locking scenario:
>> [   53.672979] 
>> [   53.679169]CPU0CPU1
>> [   53.683900]
>> [   53.688633]   lock(mtd_table_mutex);
>> [   53.692383]lock(>lock);
>> [   53.698306]lock(mtd_table_mutex);
>> [   53.704658]   lock(>lock);
>> [   53.707946] 
>> [   53.707946]  *** DEADLOCK ***
>> [   53.707946] 
>> [   53.714123] 5 locks held by modprobe/372:
>> [   53.718305]  #0:  (>mutex){..}, at: [] 
>> driver_detach+0x44/0xb8
>> [   53.726147]  #1:  (>mutex){..}, at: [] 
>> driver_detach+0x50/0xb8
>> [   53.733985]  #2:  (>mutex){..}, at: [] 
>> device_release_driver+0x18/0x2c
>> [   53.742541]  #3:  (mtd_partitions_mutex){+.+.+.}, at: [] 
>> del_mtd_partitions+0x1c/0xc8
>> [   53.751656]  #4:  (mtd_table_mutex){+.+.+.}, at: [] 
>>

Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants

2015-10-22 Thread Tony Lindgren 
* Andrew F. Davis  [151022 09:21]:
> Using constants for pinctrl allows better readability and removes
> redundancy with comments.

You should use the include/dt-bindings/pinctrl/omap.h macro
AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching
the same things again later on.

Regards,

Tony

> Signed-off-by: Andrew F. Davis 
> ---
>  arch/arm/boot/dts/am335x-boneblack.dts | 44 
> +-
>  1 file changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index eadbba3..a540a10 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -36,32 +36,32 @@
>  _pinmux {
>   nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
>   pinctrl-single,pins = <
> - 0x1b0 0x03  /* xdma_event_intr0, OMAP_MUX_MODE3 | 
> AM33XX_PIN_OUTPUT */
> - 0xa0 0x08   /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa4 0x08   /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa8 0x08   /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xac 0x08   /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb0 0x08   /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb4 0x08   /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb8 0x08   /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xbc 0x08   /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc0 0x08   /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc4 0x08   /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc8 0x08   /* lcd_data10.lcd_data10, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xcc 0x08   /* lcd_data11.lcd_data11, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd0 0x08   /* lcd_data12.lcd_data12, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd4 0x08   /* lcd_data13.lcd_data13, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd8 0x08   /* lcd_data14.lcd_data14, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xdc 0x08   /* lcd_data15.lcd_data15, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xe0 0x00   /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT */
> - 0xe4 0x00   /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 
> | AM33XX_PIN_OUTPUT */
> - 0xe8 0x00   /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | 
> AM33XX_PIN_OUTPUT */
> - 0xec 0x00   /* lcd_ac_bias_en.lcd_ac_bias_en, 
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> + 0x1b0 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* 
> xdma_event_intr0 */
> + 0xa0 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data0.lcd_data0 */
> + 0xa4 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data1.lcd_data1 */
> + 0xa8 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data2.lcd_data2 */
> + 0xac (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data3.lcd_data3 */
> + 0xb0 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data4.lcd_data4 */
> + 0xb4 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data5.lcd_data5 */
> + 0xb8 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data6.lcd_data6 */
> + 0xbc (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data7.lcd_data7 */
> + 0xc0 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data8.lcd_data8 */
> + 0xc4 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data9.lcd_data9 */
> + 0xc8 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data10.lcd_data10 */
> + 0xcc (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data11.lcd_data11 */
> + 0xd0 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data12.lcd_data12 */
> + 0xd4 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data13.lcd_data13 */
> + 0xd8 (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data14.lcd_data14 */
> + 0xdc (PIN_OUTPUT | MUX_MODE0)   /* 
> lcd_data15.lcd_data15 */
> +

[PATCH] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

2015-10-22 Thread Praneeth Bajjuri 
UART4 low level debug support. This helps in debugging with UART4
serial console output on DRA7 based platforms.

Extending the following fix for UART4.
commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on 
UART3")

For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
On DRA7, UART4 hwmod doesn't have this flag enabled,
failure observed when UART4 is used for low level debugging.

Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.

Signed-off-by: J.D. Schroeder 
Signed-off-by: Praneeth Bajjuri 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..a242572 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2065,7 +2065,7 @@ static struct omap_hwmod dra7xx_uart4_hwmod = {
.class  = _uart_hwmod_class,
.clkdm_name = "l4per_clkdm",
.main_clk   = "uart4_gfclk_mux",
-   .flags  = HWMOD_SWSUP_SIDLE_ACT,
+   .flags  = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART4_FLAGS,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET,
-- 
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] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

2015-10-22 Thread Nishanth Menon 
On 10/22/2015 04:01 PM, Praneeth Bajjuri wrote:
> UART4 low level debug support. This helps in debugging with UART4
> serial console output on DRA7 based platforms.
> 
> Extending the following fix for UART4.
> commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled 
> on UART3")
> 
> For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
> On DRA7, UART4 hwmod doesn't have this flag enabled,
> failure observed when UART4 is used for low level debugging.
> 
> Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.
> 
> Signed-off-by: J.D. Schroeder 
> Signed-off-by: Praneeth Bajjuri 
> ---
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247b..a242572 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -2065,7 +2065,7 @@ static struct omap_hwmod dra7xx_uart4_hwmod = {
>   .class  = _uart_hwmod_class,
>   .clkdm_name = "l4per_clkdm",
>   .main_clk   = "uart4_gfclk_mux",
> - .flags  = HWMOD_SWSUP_SIDLE_ACT,
> + .flags  = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART4_FLAGS,
>   .prcm = {
>   .omap4 = {
>   .clkctrl_offs = DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET,
> 
are there other uarts that may need this to be done?


-- 
Regards,
Nishanth Menon
--
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] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

2015-10-22 Thread Praneeth Bajjuri 
From: "J.D. Schroeder" 

UART4 low level debug support. This helps in debugging with UART4
serial console output on DRA7 based platforms.

Extending the following fix for UART4.
commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on 
UART3")

For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
On DRA7, UART4 hwmod doesn't have this flag enabled,
failure observed when UART4 is used for low level debugging.

Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.

Signed-off-by: J.D. Schroeder 
Signed-off-by: Praneeth Bajjuri 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..a242572 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2065,7 +2065,7 @@ static struct omap_hwmod dra7xx_uart4_hwmod = {
.class  = _uart_hwmod_class,
.clkdm_name = "l4per_clkdm",
.main_clk   = "uart4_gfclk_mux",
-   .flags  = HWMOD_SWSUP_SIDLE_ACT,
+   .flags  = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART4_FLAGS,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET,
-- 
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 V2] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

2015-10-22 Thread Praneeth 

Hi Nishanth,

On 10/22/2015 07:24 PM, Praneeth Bajjuri wrote:

From: "J.D. Schroeder" 

UART4 low level debug support. This helps in debugging with UART4
serial console output on DRA7 based platforms.

Extending the following fix for UART4.
commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on 
UART3")

For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
On DRA7, UART4 hwmod doesn't have this flag enabled,
failure observed when UART4 is used for low level debugging.

Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.

Replying to your question from V1

we have DRA7 based platforms with UART1/UART3/UART4 for serial console.

1,3 seems to be already fixed in mainline. Hence sending fix only for 4


Signed-off-by: J.D. Schroeder 
Signed-off-by: Praneeth Bajjuri 
---
  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..a242572 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2065,7 +2065,7 @@ static struct omap_hwmod dra7xx_uart4_hwmod = {
.class  = _uart_hwmod_class,
.clkdm_name = "l4per_clkdm",
.main_clk   = "uart4_gfclk_mux",
-   .flags  = HWMOD_SWSUP_SIDLE_ACT,
+   .flags  = HWMOD_SWSUP_SIDLE_ACT | DEBUG_OMAP4UART4_FLAGS,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L4PER_UART4_CLKCTRL_OFFSET,


--
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: MUSB peripheral DMA regression caused by driver core runtime PM change

2015-10-22 Thread Tony Lindgren 
* Tony Lindgren  [151022 11:03]:
> * Tony Lindgren  [151021 16:44]:
> > Hi all,
> > 
> > I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> > and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> > 
> > ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> > 
> > With the commit above reverted things work fine with DMA and USB gadgets.
> > 
> > This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> > CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> > 
> > Anybody got ideas what might be wrong? Some wrong runtime PM usage
> > under drivers/usb/musb?
> 
> Here's some more debug info on where things are different initializing
> the USB gadgets. I added some printks and diffed the dmesg output. The
> added calls from commit ddef08dd00f5 start with dd:

Well turns out the problem actually happens earlier. We end up calling
omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
probing.

No ideas yet how it should be fixed though.

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

[PATCH 4/4] arm: dts: Add omap4-hwspinlock support in dm816x

2015-10-22 Thread Neil Armstrong 
Add dm816x DT entries for omap4-hwspinlock support as hwmod spinbox.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 51ad4a9..f655ce1 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -227,6 +227,13 @@
};
};

+   spinbox: spinbox@480ca000 {
+   compatible = "ti,omap4-hwspinlock";
+   reg = <0x480ca000 0x2000>;
+   ti,hwmods = "spinbox";
+   #hwlock-cells = <1>;
+   };
+
mdio: mdio@4a100800 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
-- 
1.9.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 2/4] arm: dts: add dm816x missing spi DT dma handles

2015-10-22 Thread Neil Armstrong 
Add the missing SPI controller DMA handler in the dm816x DT
node, only properties for the two channels on four were present.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/dm816x.dtsi | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index a7a34e4..eee636d 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -280,8 +280,11 @@
ti,spi-num-cs = <4>;
ti,hwmods = "mcspi1";
dmas = < 16  17
-18  19>;
-   dma-names = "tx0", "rx0", "tx1", "rx1";
+18  19
+20  21
+22  23>;
+   dma-names = "tx0", "rx0", "tx1", "rx1",
+   "tx2", "rx2", "tx3", "rx3";
};

mmc1: mmc@4806 {
-- 
1.9.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 4/4] arm: omap2+: Add hwmod spinbox support for dm816x

2015-10-22 Thread Neil Armstrong 
Add dm81xx hwmod data entries for dm816x spinbox support.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/mach-omap2/omap_hwmod_81xx_data.c | 35 ++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
index 6256052..275b16c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_81xx_data.c
@@ -1036,6 +1036,40 @@ static struct omap_hwmod_ocp_if dm81xx_l4_ls__mailbox = {
.user   = OCP_USER_MPU,
 };

+static struct omap_hwmod_class_sysconfig dm81xx_spinbox_sysc = {
+   .rev_offs   = 0x000,
+   .sysc_offs  = 0x010,
+   .syss_offs  = 0x014,
+   .sysc_flags = SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+   SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE,
+   .idlemodes  = SIDLE_FORCE | SIDLE_NO | SIDLE_SMART,
+   .sysc_fields= _hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class dm81xx_spinbox_hwmod_class = {
+   .name = "spinbox",
+   .sysc = _spinbox_sysc,
+};
+
+static struct omap_hwmod dm81xx_spinbox_hwmod = {
+   .name   = "spinbox",
+   .clkdm_name = "alwon_l3s_clkdm",
+   .class  = _spinbox_hwmod_class,
+   .main_clk   = "sysclk6_ck",
+   .prcm   = {
+   .omap4 = {
+   .clkctrl_offs = DM81XX_CM_ALWON_SPINBOX_CLKCTRL,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+static struct omap_hwmod_ocp_if dm81xx_l4_ls__spinbox = {
+   .master = _l4_ls_hwmod,
+   .slave  = _spinbox_hwmod,
+   .user   = OCP_USER_MPU,
+};
+
 static struct omap_hwmod_class dm81xx_tpcc_hwmod_class = {
.name   = "tpcc",
 };
@@ -1298,6 +1332,7 @@ static struct omap_hwmod_ocp_if *dm816x_hwmod_ocp_ifs[] 
__initdata = {
_l4_ls__timer7,
_l4_ls__mcspi1,
_l4_ls__mailbox,
+   _l4_ls__spinbox,
_l4_hs__emac0,
_emac0__mdio,
_l4_hs__emac1,
-- 
1.9.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 2/4] clk: ti816x: Add missing dmtimer clkdev entries

2015-10-22 Thread Neil Armstrong 
Add missing clkdev dmtimer related entries for dm816x.
32Khz and ext sources were missing.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 drivers/clk/ti/clk-816x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clk/ti/clk-816x.c b/drivers/clk/ti/clk-816x.c
index 1dfad0c..2a5d84f 100644
--- a/drivers/clk/ti/clk-816x.c
+++ b/drivers/clk/ti/clk-816x.c
@@ -20,6 +20,8 @@ static struct ti_dt_clk dm816x_clks[] = {
DT_CLK(NULL, "sys_clkin", "sys_clkin_ck"),
DT_CLK(NULL, "timer_sys_ck", "sys_clkin_ck"),
DT_CLK(NULL, "sys_32k_ck", "sys_32k_ck"),
+   DT_CLK(NULL, "timer_32k_ck", "sysclk18_ck"),
+   DT_CLK(NULL, "timer_ext_ck", "tclkin_ck"),
DT_CLK(NULL, "mpu_ck", "mpu_ck"),
DT_CLK(NULL, "timer1_fck", "timer1_fck"),
DT_CLK(NULL, "timer2_fck", "timer2_fck"),
-- 
1.9.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 3/4] arm: plat-omap: add DT support for ti,dm816-timer

2015-10-22 Thread Neil Armstrong 
Adds ti,dm816-timer to the dmtimer OF match table.

Cc: Brian Hutchinson 
Signed-off-by: Neil Armstrong 
---
 arch/arm/plat-omap/dmtimer.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d3..28a6550 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -943,6 +943,10 @@ static const struct of_device_id omap_timer_match[] = {
.compatible = "ti,am335x-timer-1ms",
.data = _pdata,
},
+   {
+   .compatible = "ti,dm816-timer",
+   .data = _pdata,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, omap_timer_match);
-- 
1.9.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

Re: [PATCH] ARM: dts: Change I2C2 and I2C3 to 400KHz for LogicPD Torpedo DM3730 devkit

2015-10-22 Thread Tony Lindgren 
Hi,

Looks like you got git send-email configure, nice :)

* Adam Ford  [151021 04:45]:

Can you please resend both patches one more time with a proper
patch description added?

Mostly the descrition should describe why this change is needed.

I think running scripts/checkpatch.pl --strict on the patch
should warn about that too.

Other than that, the patches look good to me.

Regards,

Tony


> Signed-off-by: Adam Ford 
> ---
>  arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
> b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> index 9777ff4..c8091ff 100644
> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> @@ -104,6 +104,14 @@
>   };
>  };
>  
> + {
> + clock-frequency = <40>;
> +};
> +
> + {
> + clock-frequency = <40>;
> +};
> +
>  /*
>   * Only found on the wireless SOM. For the SOM without wireless, the pins for
>   * MMC3 can be routed with jumpers to the second MMC slot on the devkit and
> -- 
> 1.9.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

Re: [PATCH V2] ARM: DRA7: hwmod: Enable DEBUG_LL for UART4

2015-10-22 Thread Nishanth Menon 
On 10/22/2015 08:01 PM, Praneeth wrote:
> Hi Nishanth,
> 
> On 10/22/2015 07:24 PM, Praneeth Bajjuri wrote:
>> From: "J.D. Schroeder" 
>>
>> UART4 low level debug support. This helps in debugging with UART4
>> serial console output on DRA7 based platforms.
>>
>> Extending the following fix for UART4.
>> commit 1c7e36bfc3e2 ("ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL
>> enabled on UART3")
>>
>> For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART4 in menuconfig.
>> On DRA7, UART4 hwmod doesn't have this flag enabled,
>> failure observed when UART4 is used for low level debugging.
>>
>> Hence, Enable DEBUG_OMAP4UART4_FLAGS for UART4 hwmod.
> Replying to your question from V1
> 
> we have DRA7 based platforms with UART1/UART3/UART4 for serial console.
> 
> 1,3 seems to be already fixed in mainline. Hence sending fix only for 4

Tony or others can comment. IMHO, 1c7e36bfc3e2 is an excellent example.
it considered just UART3 as the missing thing. UART1 was already done.
now, we have UART4, tomorrow, some other board will have UART2, how many
patch on top of patch do we want to do for the same problem?

Phytech
http://phytec.com/site/assets/files/2109/phytec_am57x-som_pb_release.pdf
is a SOM module (page 2 - UART5,3 go to expansion connector).

And then you have
http://www.compulab.co.il/products/computer-on-modules/cl-som-am57x-ti-am5728-am5718-system-on-module/#diagram

When we see issues like these that are probably symptoms, we might as
well try and do as wide a solution as necessary.

if we stick with the rule that we will only enable DEBUG_LL only for
those boards that are actually in upstream, then obviously, this patch
should be dropped.

I do think, personally, that by introducing changes such as enabling
DEBUG_LL for all ports, we are making the "evil vendor tree" less
different from upstream and hence reduce cost of upstreaming - hopefully
this might help motivate various product folks to actually provide
upstream support for their products (N900 is still my favourite phone
which actually works in upstream kernel- thanks to a lot of passionate
community folks) - we really want to see more of those actual products
function and be maintained with upstream kernel.


-- 
Regards,
Nishanth Menon
--
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/2] ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs

2015-10-22 Thread Paul Walmsley 
On Mon, 14 Sep 2015, Suman Anna wrote:

> The legacy-style device creation logic for hwspinlock
> has been removed after the DT-support was added to the
> driver. The hwmod addr space for spinlock is therefore
> no longer needed, so remove it.
> 
> Signed-off-by: Suman Anna 

Thanks, queued.


- Paul
--
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 2/2] ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs

2015-10-22 Thread Paul Walmsley 
On Mon, 14 Sep 2015, Suman Anna wrote:

> Remove the mailbox attribute data, irq info and hwmod addr space
> data that are used for creating the legacy-style mailbox devices,
> there is no need for these as the support for legacy-mode for this
> IP is being dropped.
> 
> Signed-off-by: Suman Anna 

Thanks, queued.


- Paul
--
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 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

2015-10-22 Thread Suman Anna 
On 10/21/2015 11:42 PM, Jassi Brar wrote:
> On 22 October 2015 at 05:35, Suman Anna  wrote:
> 
>>>   Anyways I am OK too, if you guys want to fix it with a platform
>>> specific quirk. Let me know I'll pick this patch.
>>
>> I haven't gotten a chance to try #1, and I won't be able to look at it
>> atleast for another month. I suggest that you go ahead and pick this
>> patch up, as a quirk is needed in one form or the other for #2, and #1
>> is anyways a bigger change that will affect all our IPC stacks across
>> all pairs of MPU - remote processors on different SoCs.
>>
> Yeah that is the reason I offered to pick this patch as such.
> OK I'll take this patch.

Thanks a lot. We will be a lot closer to get PM working on AM335/AM437x
SoCs.

regards
Suman

--
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: am335x-boneblack: Use pinctrl constants

2015-10-22 Thread Andrew F. Davis 
Using constants for pinctrl allows better readability and removes
redundancy with comments.

Signed-off-by: Andrew F. Davis 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index eadbba3..a540a10 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -36,32 +36,32 @@
 _pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins = <
-   0x1b0 0x03  /* xdma_event_intr0, OMAP_MUX_MODE3 | 
AM33XX_PIN_OUTPUT */
-   0xa0 0x08   /* lcd_data0.lcd_data0, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa4 0x08   /* lcd_data1.lcd_data1, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xa8 0x08   /* lcd_data2.lcd_data2, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xac 0x08   /* lcd_data3.lcd_data3, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb0 0x08   /* lcd_data4.lcd_data4, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb4 0x08   /* lcd_data5.lcd_data5, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xb8 0x08   /* lcd_data6.lcd_data6, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xbc 0x08   /* lcd_data7.lcd_data7, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc0 0x08   /* lcd_data8.lcd_data8, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc4 0x08   /* lcd_data9.lcd_data9, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xc8 0x08   /* lcd_data10.lcd_data10, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xcc 0x08   /* lcd_data11.lcd_data11, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd0 0x08   /* lcd_data12.lcd_data12, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd4 0x08   /* lcd_data13.lcd_data13, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xd8 0x08   /* lcd_data14.lcd_data14, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xdc 0x08   /* lcd_data15.lcd_data15, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
-   0xe0 0x00   /* lcd_vsync.lcd_vsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe4 0x00   /* lcd_hsync.lcd_hsync, OMAP_MUX_MODE0 
| AM33XX_PIN_OUTPUT */
-   0xe8 0x00   /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0 | 
AM33XX_PIN_OUTPUT */
-   0xec 0x00   /* lcd_ac_bias_en.lcd_ac_bias_en, 
OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
+   0x1b0 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* 
xdma_event_intr0 */
+   0xa0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data0.lcd_data0 */
+   0xa4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data1.lcd_data1 */
+   0xa8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data2.lcd_data2 */
+   0xac (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data3.lcd_data3 */
+   0xb0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data4.lcd_data4 */
+   0xb4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data5.lcd_data5 */
+   0xb8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data6.lcd_data6 */
+   0xbc (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data7.lcd_data7 */
+   0xc0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data8.lcd_data8 */
+   0xc4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data9.lcd_data9 */
+   0xc8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data10.lcd_data10 */
+   0xcc (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data11.lcd_data11 */
+   0xd0 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data12.lcd_data12 */
+   0xd4 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data13.lcd_data13 */
+   0xd8 (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data14.lcd_data14 */
+   0xdc (PIN_OUTPUT | MUX_MODE0)   /* 
lcd_data15.lcd_data15 */
+   0xe0 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* 
lcd_vsync.lcd_vsync */
+   0xe4 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* 
lcd_hsync.lcd_hsync */
+   0xe8 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /* 
lcd_pclk.lcd_pclk */
+   0xec (PIN_OUTPUT_PULLDOWN | MUX_MODE0)  /*

Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy mailbox device instantiation

2015-10-22 Thread Suman Anna 
Hi Tony,

On 09/14/2015 06:37 PM, Suman Anna wrote:
> The legacy-style mailbox device creation is supported currently
> only for OMAP3, as all other SoCs are DT-boot only. Even on this
> SoC, there are no client drivers that utilize these mailbox devices.
> So, clean up the legacy-style mailbox device instantiation logic.
> The mailbox devices are already present and supported for the DT
> boot on OMAP3.
> 
> Signed-off-by: Suman Anna 
> ---
>  arch/arm/mach-omap2/devices.c | 28 
>  1 file changed, 28 deletions(-)
> 

Ping, can you pick up this patch for your cleanup branch? FYI, Paul is
queueing Patch 2.

regards
Suman



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