Deadlock in do_page_fault() on ARM (old kernel)
Hello,
I have a deadlock that I'm trying to understand. The symptom is multiple
tasks trying to acquire a read lock (down_read()) on mm->mmap_sem in
do_page_fault(). I'll be right up front and say that this is a fairly
old kernel (2.6.37 TI PSP kernel) on a fairly old processor DaVinci 6446.
At the time of the deadlock, sysrq's show-all-tasks shows the following
for three of the tasks which are deadlocked (there are more, but I just
picked the interesting ones; the full output is at [1]):
uiD c0ea8208 0 1405 1293 0x
[] (schedule+0x33c/0x3c4) from []
(__down_read+0xbc/0xd4)
[] (__down_read+0xbc/0xd4) from []
(do_page_fault+0x94/0x248)
[] (do_page_fault+0x94/0x248) from []
(do_DataAbort+0x34/0x94)
[] (do_DataAbort+0x34/0x94) from []
(__dabt_svc+0x4c/0x60)
Exception stack(0xc048dce8 to 0xc048dd30)
dce0: 400e9a94 c048ddb0 ffec c048c000
c048dda4
dd00: 400e9a94 ff92 c048c000 0001 0014
c048dd34
dd20: c0d1f68c 0013
[] (__dabt_svc+0x4c/0x60) from []
(__copy_to_user_std+0xcc/0x3a8)
uiD c0ea8208 0 1406 1293 0x
[] (schedule+0x33c/0x3c4) from []
(__down_read+0xbc/0xd4)
[] (__down_read+0xbc/0xd4) from []
(do_page_fault+0x94/0x248)
[] (do_page_fault+0x94/0x248) from []
(do_DataAbort+0x34/0x94)
[] (do_DataAbort+0x34/0x94) from []
(ret_from_exception+0x0/0x10)
Exception stack(0xc048ffb0 to 0xc048fff8)
ffa0: 0060 000a 00a8
0010d000
ffc0: 00c23d80 00c23de8 405af06c 405af03c 405af074 0050
01ff
ffe0: 405ae000 40185748 404f5c4c 404f393c 8010
uiD c0ea8208 0 1411 1293 0x
[] (schedule+0x33c/0x3c4) from []
(__down_read+0xbc/0xd4)
[] (__down_read+0xbc/0xd4) from []
(do_page_fault+0x94/0x248)
[] (do_page_fault+0x94/0x248) from []
(do_DataAbort+0x34/0x94)
[] (do_DataAbort+0x34/0x94) from []
(ret_from_exception+0x0/0x10)
Exception stack(0xc053bfb0 to 0xc053bff8)
bfa0: 0001 00ba3610
bfc0: 00ba3610 00bb6020 00ba3610 40074000 00b91024 415e4930
0583
bfe0: 00b611a0 415e38e0 4005f3e4 0fc0 6010
[snip]
Showing all locks held in the system:
1 lock held by getty/1294:
#0: (&tty->atomic_read_lock){+.+...}, at: []
n_tty_read+0x21c/0x670
1 lock held by ui/1405:
#0: (&mm->mmap_sem){++}, at: [] do_page_fault+0x94/0x248
1 lock held by ui/1406:
#0: (&mm->mmap_sem){++}, at: [] do_page_fault+0x94/0x248
1 lock held by ui/1408:
#0: (&mm->mmap_sem){++}, at: [] do_page_fault+0x94/0x248
1 lock held by ui/1409:
#0: (&mm->mmap_sem){++}, at: [] do_page_fault+0x94/0x248
1 lock held by ui/1411:
#0: (&mm->mmap_sem){++}, at: [] do_page_fault+0x94/0x248
1 lock held by ui/1416:
#0: (&mm->mmap_sem){++}, at: [] sys_mmap_pgoff+0x70/0xc0
1 lock held by ui/1418:
#0: (&mm->mmap_sem){++}, at: [] do_page_fault+0x94/0x248
1 lock held by ui/1420:
#0: (&mm->mmap_sem){++}, at: [] sys_mmap_pgoff+0x70/0xc0
1 lock held by ui/1434:
#0: (&tty->atomic_read_lock){+.+...}, at: []
n_tty_read+0x21c/0x670
Note that above, do_page_fault() takes out a read lock (down_read()) and
sys_mmap_pgoff() takes out a write lock (down_write()).
I've searched for this kind of problem and found two patches which seem
to be related to this issue[2]. I have applied both with no better results.
So my questions are:
1. Why don't I see a full backtrace beyond the exception stack? It's the
same when dump_stack() is called manually.
2. __copy_to_user_memcpy() takes a read lock (down_read()) on
mm->mmap_sem. While that lock is held, __copy_to_user_memcpy() can
generate a page fault, causing do_page_fault() to get called, which will
also try to get a read lock (down_read()) on mm->mmap_sem. Multiple read
locks can be taken on an rw_semaphore, but deadlock will occur if
another thread tries to get a write lock (down_write()) in between. For
example:
Task 1: Task 2:
down_read(sem)
down_write(sem)<-- Goes to sleep
down_read(sem) <-- Goes to sleep
There is a thread from 2005[3] which seems to discuss the same concept
of recursive rw_semaphores, but for futexes.
Other comments:
1. My analysis of this probably wrong. Otherwise it seems many others
would have the same problem, and they don't seem to. I'm hoping this
email will help to correct my understanding.
2. I looked through the git logs for recent (since 2.6.37 time frame)
and nothing else jumped out at me as being an obvious fix for this
situation.
Thanks for any insight you can give,
Alan.
[1] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt
[2] Some websites/bugtrackers mention this commit with a similar issue,
but I'm not entirely sure how it's related:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8878a
Re: [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
Felipe, > On 01/14/2014 08:04 AM, Felipe Balbi wrote: Hi again, On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote: diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c index 9f56fb2..194886e 100644 --- a/drivers/hwspinlock/omap_hwspinlock.c +++ b/drivers/hwspinlock/omap_hwspinlock.c @@ -101,10 +101,23 @@ static int omap_hwspinlock_probe(struct platform_device *pdev) if (!io_base) return -ENOMEM; +/* + * make sure the module is enabled and clocked before reading + * the module SYSSTATUS register + */ +pm_runtime_enable(&pdev->dev); +pm_runtime_get_sync(&pdev->dev); another thing, you need to check return of pm_runtime_get_sync() OK, let me check this and your other comment, and the fix is probably a separate patch. I realized the changes relevant to your comments were introduced in this patch, so just refreshed the patch with fixes instead of doing a separate patch. I didn't do a v5 just for these change, and will do so if there are more comments on the DT adaptation. 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
[UPDATED PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.
Signed-off-by: Suman Anna
---
drivers/hwspinlock/omap_hwspinlock.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
if (!io_base)
return -ENOMEM;
+ /*
+* make sure the module is enabled and clocked before reading
+* the module SYSSTATUS register
+*/
+ pm_runtime_enable(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(&pdev->dev);
+ goto iounmap_base;
+ }
+
/* Determine number of locks */
i = readl(io_base + SYSSTATUS_OFFSET);
i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET;
+ /*
+* runtime PM will make sure the clock of this module is
+* enabled again iff at least one lock is requested
+*/
+ ret = pm_runtime_put_sync(&pdev->dev);
+ if (ret < 0)
+ goto iounmap_base;
+
/* one of the four lsb's must be set, and nothing else */
if (hweight_long(i & 0xf) != 1 || i > 8) {
ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
- /*
-* runtime PM will make sure the clock of this module is
-* enabled iff at least one lock is requested
-*/
- pm_runtime_enable(&pdev->dev);
-
ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
base_id, num_locks);
if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device
*pdev)
return 0;
reg_fail:
- pm_runtime_disable(&pdev->dev);
kfree(bank);
iounmap_base:
+ pm_runtime_disable(&pdev->dev);
iounmap(io_base);
return ret;
}
--
1.8.4.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
Re: musb host mode suspend mode
Hi
I forget to post the solution for old kernel 3.0.31. The code to
support the suspend/resume in host mode when some
peripheral is connected (no wake lock should be taken for android device)
+static int omap2430_resume_noirq(struct device *dev)
+{
+ struct omap2430_glue*glue = dev_get_drvdata(dev);
+ struct musb *musb = glue_to_musb(glue);
+ struct platform_device *pdev = to_platform_device(dev);
+
+ if (pm_runtime_suspended(dev))
+ return 0;
+
+ if (pdev)
+ omap_device_enable(pdev);
+
+ omap2430_low_level_init(musb);
+ musb_writel(musb->mregs, OTG_INTERFSEL,
+ musb->context.otg_interfsel);
+
+ otg_set_suspend(musb->xceiv, 0);
+
+ return 0;
+}
+
+
+static int omap2430_suspend_noirq(struct device *dev)
+{
+ struct omap2430_glue*glue = dev_get_drvdata(dev);
+ struct musb *musb = glue_to_musb(glue);
+ struct platform_device *pdev = to_platform_device(dev);
+
+ if (pm_runtime_suspended(dev))
+ return 0;
+
+ musb->context.otg_interfsel = musb_readl(musb->mregs,
+ OTG_INTERFSEL);
+
+ omap2430_low_level_exit(musb);
+ otg_set_suspend(musb->xceiv, 1);
+ if (pdev)
+ omap_device_idle(pdev);
+
+ return 0;
+}
+
+struct dev_pm_ops omap2430_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap2430_runtime_suspend, omap2430_runtime_resume,
+ NULL)
+ .suspend_noirq = omap2430_suspend_noirq,
+ .resume_noirq = omap2430_resume_noirq,
};
Michael
On Wed, Dec 11, 2013 at 5:14 PM, Michael Trimarchi
wrote:
> Hi
>
> On Sat, Dec 7, 2013 at 6:22 PM, Michael Trimarchi
> wrote:
>> Hi
>>
>> On Wed, Nov 27, 2013 at 4:26 PM, Michael Trimarchi
>> wrote:
>>> Hi Felipe,
>>>
>>> I'm trying to understand how dpll_usb and vbus should work in suspend mode.
>>> What I have in my kernel 3.0.31 from ti is that if I suspend the device
>>> with id
>>> pin ground and no device connected I have:
>>>
>>> - vbus 5v
>>> - dpll_usb locked problem so l3domain can not suspend
>>>
>>> If I have the id pin floating (device mode) and no device connected I
>>> can suspend
>>> without problem. I'm not care about remote wakeup and I would like to
>>> understand
>>> what is the reason of having no complete suspend in host mode. Can you give
>>> some insight?
>>
>> I get a bit further and if I do something like that so basically force
>> device mode I can suspend.
>>
>> + if (val) {
>> + twl->force_device = false;
>> + twl6030_writeb(twl, TWL_MODULE_USB, 0x14, USB_ID_CTRL_SET);
>> + twl6030_usb_irq(twl->irq2, twl);
>> + twl6030_usbotg_irq(twl->irq1, twl);
>> + } else {
>> + twl->force_device = true;
>> + twl6030_writeb(twl, TWL_MODULE_USB, 0x14, USB_ID_CTRL_CLR);
>> + twl6030_usb_irq(twl->irq2, twl);
>> + twl6030_usbotg_irq(twl->irq1, twl);
>> + }
>>
>> So my problem is let the device connect host mode (remote wakeup
>> disable) and let the system suspend in the correct way.
>>
>
> I think that I have almost fixed the problem of suspend resume of the
> otg host mode in this old
> version of the kernel. But I would like to share my short summary:
>
> - I have implemented the suspend/resume hooks of the omap2430 and manually
> call the omap_device_idle and omap_device_disable because in old
> version of the kernel
> this hooks are not implemented in the omap_device structure
>
> - I understand the reason in not having the runtime_suspend the otg in
> host mode but I'm not sure:
> * the runtime_get_sync is taken on the ID_GND event so as soon it's
> host connected the use_count
> go to 1 but I did't find where it is released
>
> - I still have a
>
> <4>[ 41.856445] WARNING: at
> /home/michael/work/amarula/wincor/paypad/kernel/arch/arm/mach-omap2/omap_l3_noc.c:135
> l3_interrupt_handler+0x254/0x344()
> <4>[ 41.856475] CUSTOM SRESP error with SOURCE:L4CFG
> <4>[ 41.856506] Modules linked in: pvrsrvkm_sgx540_120 gps_drv
> wl12xx mac80211 cfg80211 compat
> <4>[ 41.856567] Backtrace:
> <4>[ 41.856597] [] (dump_backtrace+0x0/0x10c) from
> [] (dump_stack+0x18/0x1c)
> <4>[ 41.856628] r7:0009 r6:0087 r5:c010652c r4:c783dc80
> <4>[ 41.856689] [] (dump_stack+0x0/0x1c) from []
> (warn_slowpath_common+0x54/0x6c)
> <4>[ 41.856750] [] (warn_slowpath_common+0x0/0x6c) from
> [] (warn_slowpath_fmt+0x38/0x40)
> <4>[ 41.856781] r9: r8:f8000400 r7:00080003 r6:c08ce948 r5:0448
> <4>[ 41.856811] r4:f800
> <4>[ 41.856842] [] (warn_slowpath_fmt+0x0/0x40) from
> [] (l3_interrupt_handler+0x254/0x344)
> <4>[ 41.856872] r3:c07ee514 r2:c07ee4b0
> <4>[ 41.856933] [] (l3_interrupt_handler+0x0/0x344) from
> [] (handle_irq_event_percpu+0x6c/0x290)
> <4>[ 41.
[PATCH] ARM: OMAP2+: add missing ARCH_HAS_OPP
OMAP5, DRA7, AM43xx all have OPPs. So select the same to allow SoC only configuration boot to work with OPP. Reported-by: Nikhil Devshatwar Signed-off-by: Nishanth Menon --- For DRA7, depends on: https://patchwork.kernel.org/patch/3465411/ arch/arm/mach-omap2/Kconfig |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 35c23e5..66a9c4a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -50,6 +50,7 @@ config SOC_OMAP5 bool "TI OMAP5" depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS + select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select CPU_V7 @@ -63,6 +64,7 @@ config SOC_AM33XX bool "TI AM33XX" depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS + select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select CPU_V7 select MULTI_IRQ_HANDLER @@ -72,6 +74,7 @@ config SOC_AM43XX depends on ARCH_MULTI_V7 select CPU_V7 select ARCH_OMAP2PLUS + select ARCH_HAS_OPP select MULTI_IRQ_HANDLER select ARM_GIC select MACH_OMAP_GENERIC @@ -80,6 +83,7 @@ config SOC_DRA7XX bool "TI DRA7XX" depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS + select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select CPU_V7 -- 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
OMAP baseline test results for v3.13-rc8
Here are some basic OMAP test results for Linux v3.13-rc8. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc8/20140113013852/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Boot to userspace: skip ( 2/ 2): 5912osk, 4460varsomom Pass (10/10): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517 PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.13-rc7 (d6e0a2dd12f4067a5bcefb8bbd8ddbeff800afbc)): text data bsstotal kernel +4500 +45 omap1_defconfig +49 -80 +41 omap1_defconfig_1510innovator_only +7700 +77 omap1_defconfig_5912osk_only +500 +5 omap2plus_defconfig +2500 +25 omap2plus_defconfig_2430sdp_only +500 +5 omap2plus_defconfig_cpupm 0000 omap2plus_defconfig_n800_multi_omap2xxx 0000 omap2plus_defconfig_n800_only_a +500 +5 omap2plus_defconfig_no_pm +6900 +69 omap2plus_defconfig_omap2_4_only +500 +5 omap2plus_defconfig_omap3_4_only +800 -88 -8 rmk_omap3430_ldp_allnoconfig +6500 +65 rmk_omap3430_ldp_oldconfig -160 -24 -40 rmk_omap4430_sdp_allnoconfig +12500 +125 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.13-rc7 (d6e0a2dd12f4067a5bcefb8bbd8ddbeff800afbc)) avail rsrvd high freed board kconfig (no differences) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.13-rc7
Here are some basic OMAP test results for Linux v3.13-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc7/20140107113336/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Boot to userspace: skip ( 2/ 2): 5912osk, 4460varsomom Pass (10/10): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517 PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.13-rc6 (802eee95bde72fd0cd0f3a5b2098375a487d1eda)): text data bsstotal kernel +12800 +128 omap1_defconfig +12800 +128 omap1_defconfig_1510innovator_only +9600 +96 omap1_defconfig_5912osk_only +34800 +348 omap2plus_defconfig +124 +80 +132 omap2plus_defconfig_2430sdp_only +47600 +476 omap2plus_defconfig_cpupm -400 -4 omap2plus_defconfig_n800_multi_omap2xxx -3600 -36 omap2plus_defconfig_n800_only_a +22800 +228 omap2plus_defconfig_no_pm +28400 +284 omap2plus_defconfig_omap2_4_only +348 +80 +356 omap2plus_defconfig_omap3_4_only -32 +8 +8 -16 rmk_omap3430_ldp_allnoconfig +24 +80 +32 rmk_omap3430_ldp_oldconfig +24 +8 -48 -16 rmk_omap4430_sdp_allnoconfig +16400+6296+1268 +23964 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.13-rc6 (802eee95bde72fd0cd0f3a5b2098375a487d1eda)) avail rsrvd high freed board kconfig (no differences) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.13-rc6
Here are some basic OMAP test results for Linux v3.13-rc6. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc6/20131229233555/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Boot to userspace: skip ( 2/ 2): 5912osk, 4460varsomom Pass (10/10): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517 PM: chip retention via suspend: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.13-rc5 (413541dd66d51f791a0b169d9b9014e4f56be13c)): text data bsstotal kernel +14000 +140 omap1_defconfig +14000 +140 omap1_defconfig_1510innovator_only +14000 +140 omap1_defconfig_5912osk_only +35200 +352 omap2plus_defconfig +27600 +276 omap2plus_defconfig_2430sdp_only +49600 +496 omap2plus_defconfig_cpupm +17200 +172 omap2plus_defconfig_n800_multi_omap2xxx +14000 +140 omap2plus_defconfig_n800_only_a +444800+4448 omap2plus_defconfig_no_pm +332 +80 +340 omap2plus_defconfig_omap2_4_only +28800 +288 omap2plus_defconfig_omap3_4_only +256 +32 -32 +256 rmk_omap3430_ldp_allnoconfig +160 +640 +224 rmk_omap3430_ldp_oldconfig +14000 +140 rmk_omap4430_sdp_allnoconfig +25600 +256 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.13-rc5 (413541dd66d51f791a0b169d9b9014e4f56be13c)) avail rsrvd high freed board kconfig -1007736k -39816k -269312k -384k 4460varsomom omap2plus_defconfig The winter holidays seemed to be a good time for testbed disruptions here. The 2430SDP lost its ability to communicate over Ethernet, so that's been switched to serial booting. And the 4460 VAR-SOM-OM decided it was going to modulate its serial console TXD line with a 60 Hz ersatz triangle wave, strong enough to confuse the serial port it was hooked up to, so that board is offline until I can track down what the problem is. -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Mike Turquette [140115 11:25]: > Quoting Tony Lindgren (2014-01-15 09:13:23) > > * Mike Turquette [140114 19:52]: > > > > > > > > These 40 patches apply very cleanly on top of clk-next with 2 > > > > exceptions: > > > > > > > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" > > > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based > > > > on 3.13-rc1). > > > > > > > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I > > > > resolved correctly but would like verification. > > > > > > > > I'd prefer to simply merge these patches into clk-next, which is the > > > > most straightforward route. Any ideas on how to handle the missing > > > > AM35xx dtsi data? It can always go as a separate fix after this stuff > > > > gets merged which, ironically, is how that file was created in the first > > > > place. > > > > You could do something like this to take advantage of fast forward and > > not have to do a merge back from mainline: > > > > $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi > > $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired > > -rc > > $ git am am3517-clk-patch > > $ git checkout clk-next > > $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc > > That makes sense, but is there anything bad about doing that for a > branch you intend to send as a pull request? I don't see how any of the > commits get re-written or anything... I just wonder if there is some > subtlety that I am not accounting for that makes this approach bad for > sending to Linus. No there should not be any issues. That's the preferred way to keep development branches updated and pullable in long term without any need to rebase. Note that there will be only a merge commit if there is a conflict, otherwise the fast forward will be transparent. So the trick to avoiding rebasing and back merges is to apply patches against what they need in a local branch, then after testing merge that local branch into the development branch. Then for the upsteam pull request, you just need to make it against the -rc you merged in. AFAIK what Linus does not like is doing a back merge to a development branch from mainline, probably as it adds a pointless commit. Or rebasing a branch as that way it won't stay pullable. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] iommu/omap: Convert to devicetree
Hi On 01/02/2014 02:01 AM, Sebastian Reichel wrote: > Hi, > > On Thu, Jan 02, 2014 at 01:13:42AM +0100, Laurent Pinchart wrote: >>> + .of_match_table = omap_iommu_of_match, >> >> If CONFIG_OF isn't defined (pretty unlikely I agree, but a possibility you >> seem to be prepared for nonetheless given the above #if), this will fail to >> compile. > > FYI: This is avoided in other drivers by using > of_match_ptr(omap_iommu_of_match), which is replaced with NULL by > the preprocessor if CONFIG_OF is not defined. > Thank you for the hint. Florian -- 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/7] iommu/omap: Do bus_set_iommu() only if probe() succeeds
Hi Suman, So back to this... On 12/24/2013 12:35 AM, Anna, Suman wrote: > Hi Florian, > [...] >> >> If omap_iommu_probe() fails, the init will have called bus_set_iommu() >> anyways. Thus, when a driver request the iommu by calling >> iommu_domain_alloc(), it will succeed (but iommu_attach_device() will >> fail if I remember). > > Yeah, thats the behavior I expected anyway. > >> Leaving a driver with a dangling reference to >> a phantom iommu is not good IMHO. It will lead to strange behaviours >> one day or another. >> >> As for the multiple iommu case, as I do not think it is currently >> possible, as bus_type (in this case &platform_bus_type) has only >> one struct iommu_ops. bus_set_iommu() will return EBUSY on the >> second call. Am I missing something? > > What I meant was the problem you cited will still exist, say if ISP MMU > probe failed, but the IVA MMU probe succeeded. The bus_set_iommu() can > only be called once anyway, so moving it from init to probe would not > help much. > Ok I see your point. Similar IPs share the same ops, but with different omap_iommu_arch_data, even if currently we only have one registered IOMMU for OMAP3. So I will drop this patch. Regards, Florian -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Mike Turquette [140114 19:52]: > > > > These 40 patches apply very cleanly on top of clk-next with 2 > > exceptions: > > > > 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" > > because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based > > on 3.13-rc1). > > > > 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I > > resolved correctly but would like verification. > > > > I'd prefer to simply merge these patches into clk-next, which is the > > most straightforward route. Any ideas on how to handle the missing > > AM35xx dtsi data? It can always go as a separate fix after this stuff > > gets merged which, ironically, is how that file was created in the first > > place. You could do something like this to take advantage of fast forward and not have to do a merge back from mainline: $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc $ git am am3517-clk-patch $ git checkout clk-next $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc 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: [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On 01/15/2014 03:48 PM, Anssi Hannula wrote: 15.01.2014 13:27, Jyri Sarha kirjoitti: On 12/31/2013 03:25 PM, Mark Brown wrote: On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote: support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. The 8 least significant bits are ignored. Where does this constraint come from? From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N register statically to a value that works only with 4 byte samples. According to my tests it is possible to support 3 and 2 byte samples too by changing the CTS_N register value, but I am not sure if the configuration can be changed on the fly. My data sheet of the nxp chip is very vague about the register definitions, but I suppose the register configures some clock divider on the chip. HDMI supports only upto 24bit audio and the data sheet states that any extraneous least significant bits are ignored. That sounds strange, CTS/N values only depend on audio sample rate and TMDS/video clock, not on the audio format or the size of samples (HDMI spec sec 7.2 - Audio Sample Clock Capture and Regeneration). Sure there isn't anything more going on (like the used HDMI sink being more tolerant to wrong CTS/N with 4-byte samples, or more likely something else I can't immediately think of)? On theoretical level I am not really sure about anything, because have not been able to get my hands on proper NXP TDA19988 documentation. However, while playing around with my Beaglebone-Black I have have found out in practice that by changing CTS_N register's (page 0x11 reg 0x0c) K_SEL bits (bit 2 to 0)[1] I can get 2, 3 and 4 byte samples to work consistently by setting: K_SEL = 1 for SNDRV_PCM_FORMAT_S16_LE K_SEL = 2 for SNDRV_PCM_FORMAT_S24_3LE K_SEL = 3 for SNDRV_PCM_FORMAT_S32_LE Because I do not really know what is going on, I did not want to suggest any changes to the driver and just use the format that works with the current driver version. The HDMI sinks I have been using are a Toshiba 22B2LF1G and Thomson 42E90NF32 televisions. About those I just know that they both behave the same way. Best regards, Jyri [1] The closest data sheet that has any description about the chip registers I have found is this: http://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/TDA9983B.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On Wed, 15 Jan 2014 13:27:21 +0200 Jyri Sarha wrote: > From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N > register statically to a value that works only with 4 byte samples. > According to my tests it is possible to support 3 and 2 byte samples too > by changing the CTS_N register value, but I am not sure if the > configuration can be changed on the fly. My data sheet of the nxp chip > is very vague about the register definitions, but I suppose the register > configures some clock divider on the chip. HDMI supports only upto 24bit > audio and the data sheet states that any extraneous least significant > bits are ignored. In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is not set). Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits formats are working well with I2S input at any rate. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/15/2014 07:41 AM, Tero Kristo wrote: > On 01/15/2014 05:50 AM, Mike Turquette wrote: >> Quoting Mike Turquette (2014-01-14 19:16:32) >>> Quoting Felipe Balbi (2014-01-14 18:04:21) Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: >> Felipe, care to run your randconfig magic for this? > > This branch builds just fine so far, I still have omap5 multiplaform and > uniplatform builds, but since that was working before i'm assuming it > won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi >>> >>> Felipe, >>> >>> That's great to hear. Thanks for testing. >>> >>> Tero & Tony, >>> >>> These 40 patches apply very cleanly on top of clk-next with 2 >>> exceptions: >>> >>> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" >>> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based >>> on 3.13-rc1). >>> >>> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I >>> resolved correctly but would like verification. >>> >>> I'd prefer to simply merge these patches into clk-next, which is the >>> most straightforward route. Any ideas on how to handle the missing >>> AM35xx dtsi data? It can always go as a separate fix after this stuff >>> gets merged which, ironically, is how that file was created in the first >>> place. >> >> I've pushed my branch. Tero can you take a look and let me know if you >> see any problems? >> >> git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap > > Hey Mike, > > Can't see any issues there, also gave it a quick boot test with the > boards I have access to and seems to work fine. > Here are the logs with commit 12d0a30a45e3a85463a6cb2a9e886192e3123892 ( i need an additional patch for legacy platform testing). 1: am335x-evm: http://slexy.org/raw/s215zNjZFv 2: am335x-sk: http://slexy.org/raw/s20uTrPG7V 3: am3517-evm: http://slexy.org/raw/s21XPhGMCt (we should be based on .13-rc4 to get am3517 baseline patches -> So due to the dropped am3517 patch, we stop booting here). 4: am37x-evm: http://slexy.org/raw/s20W2nuCQa 5: am43xx-epos: http://slexy.org/raw/s2I2qc961B (no boot yet) 6:beag-xm: http://slexy.org/raw/s210lX2EvT 7: bone-black: http://slexy.org/raw/s2NgHa78JC (still have the fixed-regulator bug in rc1 so, wont boot to shell at rc1) 8: am3517-crane: http://slexy.org/raw/s2r1Bt4Hk2 (need benoit' for-next to boot) 9: dra7: http://slexy.org/raw/s21UWF0yYd (same fixed regulator issue) 10:ldp: http://slexy.org/raw/s2oWL6qt2t (dts for this is pending merge in Tony's next) 11:panda-es: http://slexy.org/raw/s20NEXs51M 12:sdp2430: http://slexy.org/raw/s21kyDYjfk (dts for this pending in Tony's next) 13:sdp3430: http://slexy.org/raw/s2EYHpcAW0 14:sdp4430: http://slexy.org/raw/s2QPK7cBUP 15: uevm: http://slexy.org/raw/s21mMF6kN3 (same regulator stuff kicks again) am3517-evm is concerning for 14-rc1 boot, am43xx-epos looks concerning too(not sure if there are follow on fixes in later rcs that allow it to boot) - considering that both did work on tests that I did based on next[1], only thing i am concerned in am3517 patch dropped in clk-next-omap. - will be good to get this merged on clk-next and see what we can get results on linux-next tag. [1] http://marc.info/?l=devicetree&m=138930255330882&w=2 -- 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 v10 5/7] ARM: dts: add pbias dt node
On Monday 13 January 2014 09:06 PM, Balaji T K wrote:
Add pbias regulator node as a child of system control
module - syscon.
Signed-off-by: Balaji T K
Acked-by: Tony Lindgren
Hi Benoit,
Gentle Ping, Let me know if you have any comments.
---
arch/arm/boot/dts/dra7.dtsi | 17 +
arch/arm/boot/dts/omap2430.dtsi | 17 +
arch/arm/boot/dts/omap3.dtsi| 17 +
arch/arm/boot/dts/omap4.dtsi| 17 +
arch/arm/boot/dts/omap5.dtsi| 17 +
5 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d0df4c4..876c9b8 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -110,6 +110,22 @@
ti,hwmods = "counter_32k";
};
+ dra7_ctrl_general: tisyscon@4a002e00 {
+ compatible = "syscon", "simple-bus";
+ reg = <0x4a002e00 0x7c>;
+ };
+
+ pbias_regulator: pbias_regulator {
+ compatible = "ti,pbias-omap";
+ reg = <0 0x4>;
+ syscon = <&dra7_ctrl_general>;
+ pbias_mmc_reg: pbias_mmc_omap5 {
+ regulator-name = "pbias_mmc_omap5";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ };
+ };
+
dra7_pmx_core: pinmux@4a003400 {
compatible = "pinctrl-single";
reg = <0x4a003400 0x0464>;
@@ -485,6 +501,7 @@
dmas = <&sdma 61>, <&sdma 62>;
dma-names = "tx", "rx";
status = "disabled";
+ pbias-supply = <&pbias_mmc_reg>;
};
mmc2: mmc@480b4000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index d624345..af71eb0 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -29,6 +29,22 @@
pinctrl-single,function-mask = <0x3f>;
};
+ omap2_scm_general: tisyscon@49002270 {
+ compatible = "syscon", "simple-bus";
+ reg = <0x49002270 0x240>;
+ };
+
+ pbias_regulator: pbias_regulator {
+ compatible = "ti,pbias-omap";
+ reg = <0x230 0x4>;
+ syscon = <&omap2_scm_general>;
+ pbias_mmc_reg: pbias_mmc_omap2430 {
+ regulator-name = "pbias_mmc_omap2430";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ };
+ };
+
gpio1: gpio@4900c000 {
compatible = "ti,omap2-gpio";
reg = <0x4900c000 0x200>;
@@ -183,6 +199,7 @@
ti,dual-volt;
dmas = <&sdma 61>, <&sdma 62>;
dma-names = "tx", "rx";
+ pbias-supply = <&pbias_mmc_reg>;
};
mmc2: mmc@480b4000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99..b7828da 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -137,6 +137,22 @@
pinctrl-single,function-mask = <0xff1f>;
};
+ omap3_scm_general: tisyscon@48002270 {
+ compatible = "syscon", "simple-bus";
+ reg = <0x48002270 0x2f0>;
+ };
+
+ pbias_regulator: pbias_regulator {
+ compatible = "ti,pbias-omap";
+ reg = <0x2b0 0x4>;
+ syscon = <&omap3_scm_general>;
+ pbias_mmc_reg: pbias_mmc_omap2430 {
+ regulator-name = "pbias_mmc_omap2430";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <300>;
+ };
+ };
+
gpio1: gpio@4831 {
compatible = "ti,omap3-gpio";
reg = <0x4831 0x200>;
@@ -351,6 +367,7 @@
ti,dual-volt;
dmas = <&sdma 61>, <&sdma 62>;
dma-names = "tx", "rx";
+ pbias-supply = <&pbias_mmc_reg>;
};
mmc2: mmc@480b4000 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e0585..9e19363 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -134,6 +134,22
Re: [PATCH 2/5] phy: add support for indexed lookup
Hi Heikki, On Tuesday 14 January 2014 07:53 PM, Heikki Krogerus wrote: > Hi Kishon, > > And happy new year.. Happy new year :-) > > On Tue, Jan 07, 2014 at 07:10:36PM +0530, Kishon Vijay Abraham I wrote: > /** > - * phy_get() - lookup and obtain a reference to a phy. > + * phy_get_index() - obtain a phy based on index NAK. It still takes a 'char' argument and the name is misleading. Btw are you replacing phy_get() or adding a new API in addition to phy_get()? >>> >>> Additional API. The phy_get() would in practice act as a wrapper after >> >> In this patch it looks like you've replaced phy_get(). >>> this. It could actually be just a #define macro in the include file. >>> The function naming I just copied straight from gpiolib.c. I did not >>> have the imagination for anything fancier. >>> >>> I would like to be able to use some function like phy_get_index() and >>> be able to deliver it both the name and the index. With DT you guys >>> will always be able to use the name (and the string will always >>> supersede the index if we do it like this), but with ACPI, and possibly >>> the platform lookup tables, the index can be used... >> >> I think in that case, we should drop the 'string' from phy_get_index since we >> have the other API to handle that? I don't know about ACPI, but is it not >> possible to use strings with ACPI? > > No unfortunately. We just have what the ACPI tables provide. The PHYs > would be "child" device entries under the controller and we can only > get handle to them based on the index. > > I think I'll skip this patch from this set. Let's wait until we have > an actual ACPI DSDT describing some PHYs. yeah.. sure. Cheers Kishon -- 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 4/5] arm: omap3: twl: use the new lookup method with usb phy
Hi, On Tuesday 14 January 2014 08:08 PM, Heikki Krogerus wrote: > On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote: >>> In any case, having two device names to deal with does not add any >>> more risk. These associations should always be made in the place where >>> the phy device is created so you will always know it's device name. >> >> huh.. we should also know the 'controller' device name while defining these >> associations and in some cases the controller device and phy device are >> created >> in entirely different places. > > If you don't want to use the controller device name to do the > matching, we can use the con_id string as well. I believe the lookup > method I use in this set just needs a small change. The point I'm trying to make is that we won't 'always' know the device names in advance. Btw how are you planning to differentiate between multiple controllers of the same type with con_id? Maybe I'm missing the actual intention of this patch. Do you face problem if the PHY's have to know about it's consumers in ACPI? > > Is that OK with you? > > >>> Normally the platform code creates these associations in the same >>> place it creates the platform devices, so you definitely know what the >>> device names will be. >>> >>> In this case it's actually created in drivers/mfd/twl-core.c, so I do >>> need to update this and move the lookup table there. We can still >>> deliver the user name as platform data, though I believe it's always >>> "musb". Maybe we could actually skip that and just hard code the name? >> >> I would rather leave the way it is modelled now. > > Do you mean, leave it in the platform code? Why? We would reduce the > platform code by moving it to the mfd driver. Or did I misunderstood > something? In this case, the lookup table will be used only for non-dt boot so don't see much use in moving to mfd driver. I meant if the new method is not solving any problem then I would prefer the way it is modelled now where the PHY's know about it's consumers. Btw where does device gets created in ACPI boot? Cheers Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
15.01.2014 13:27, Jyri Sarha kirjoitti: > On 12/31/2013 03:25 PM, Mark Brown wrote: >> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote: >>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. >>> The 8 least significant bits are ignored. >> >> Where does this constraint come from? >> > > From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N > register statically to a value that works only with 4 byte samples. > According to my tests it is possible to support 3 and 2 byte samples too > by changing the CTS_N register value, but I am not sure if the > configuration can be changed on the fly. My data sheet of the nxp chip > is very vague about the register definitions, but I suppose the register > configures some clock divider on the chip. HDMI supports only upto 24bit > audio and the data sheet states that any extraneous least significant > bits are ignored. That sounds strange, CTS/N values only depend on audio sample rate and TMDS/video clock, not on the audio format or the size of samples (HDMI spec sec 7.2 - Audio Sample Clock Capture and Regeneration). Sure there isn't anything more going on (like the used HDMI sink being more tolerant to wrong CTS/N with 4-byte samples, or more likely something else I can't immediately think of)? BTW, radeon driver has some code that calculates static CTS/N values since the hw autogeneration is not reliable there: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/r600_hdmi.c Not that it directly helps now, but just for the record... -- Anssi Hannula -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/15/2014 05:50 AM, Mike Turquette wrote: Quoting Mike Turquette (2014-01-14 19:16:32) Quoting Felipe Balbi (2014-01-14 18:04:21) Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: Felipe, care to run your randconfig magic for this? This branch builds just fine so far, I still have omap5 multiplaform and uniplatform builds, but since that was working before i'm assuming it won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi Felipe, That's great to hear. Thanks for testing. Tero & Tony, These 40 patches apply very cleanly on top of clk-next with 2 exceptions: 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data" because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based on 3.13-rc1). 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I resolved correctly but would like verification. I'd prefer to simply merge these patches into clk-next, which is the most straightforward route. Any ideas on how to handle the missing AM35xx dtsi data? It can always go as a separate fix after this stuff gets merged which, ironically, is how that file was created in the first place. I've pushed my branch. Tero can you take a look and let me know if you see any problems? git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap Hey Mike, Can't see any issues there, also gave it a quick boot test with the boards I have access to and seems to work fine. -Tero Thanks! Mike Regards, Mike cheers -- balbi -- 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/3] ARM: dts: am43x/am335x-evm: add SD card hotplug support
On Friday 27 December 2013 09:59 PM, Balaji T K wrote: Balaji T K (3): ARM: dts: am335x-evm: add SD card hotplug support ARM: dts: am335x-evmsk: add SD card hotplug support ARM: dts: am43x-epos-evm: add SD card hotplug support arch/arm/boot/dts/am335x-evm.dts |9 + arch/arm/boot/dts/am335x-evmsk.dts |9 + arch/arm/boot/dts/am4372.dtsi|1 + arch/arm/boot/dts/am43x-epos-evm.dts |9 + 4 files changed, 28 insertions(+), 0 deletions(-) Hi Benoit, Gentle ping! -- 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 RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
On 12/31/2013 03:25 PM, Mark Brown wrote:
On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
Add machine driver support for BeagleBone-Black and other boards with
tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
port in I2S mode. The 44100 Hz sample-rate and it's multiples can not
be supported on Beaglebone-Black because of limited clock-rate
Can the drivers infer this from the clocks?
It does. The commit message is referring to a BBB HW specific feature.
Guess I should remove that note from the commit message, since it does
not concern the code itself.
support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
The 8 least significant bits are ignored.
Where does this constraint come from?
From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
register statically to a value that works only with 4 byte samples.
According to my tests it is possible to support 3 and 2 byte samples too
by changing the CTS_N register value, but I am not sure if the
configuration can be changed on the fly. My data sheet of the nxp chip
is very vague about the register definitions, but I suppose the register
configures some clock divider on the chip. HDMI supports only upto 24bit
audio and the data sheet states that any extraneous least significant
bits are ignored.
+ struct snd_soc_card_drvdata_davinci *drvdata =
+ (struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card);
Again with the casting.
I'll fix that.
+ runtime->hw.rate_min = drvdata->rate_constraint->list[0];
+ runtime->hw.rate_max = drvdata->rate_constraint->list[
+ drvdata->rate_constraint->count - 1];
+ runtime->hw.rates = SNDRV_PCM_RATE_KNOT;
+
+ snd_pcm_hw_constraint_list(runtime, 0, SNDRV_PCM_HW_PARAM_RATE,
+ drvdata->rate_constraint);
+ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_CHANNELS,
+2, 2);
Why not just set all this statically when registering the DAI?
Because there is no relevant DAI to where to put these limitations. I
did not want to add yet another dummy codec driver, but decided to use
the already existing ASoC HDMI codec. By default the driver support all
audio params supported by HDMI. The limitations are coming from NXP
chip, the NXP driver, and because the chip is used in i2s mode. In other
words the limitation is coming from machine setup, not from the DAIs.
+static unsigned int evm_get_bclk(struct snd_pcm_hw_params *params)
+{
+ int sample_size = snd_pcm_format_width(params_format(params));
+ int rate = params_rate(params);
+ int channels = params_channels(params);
+
+ return sample_size * channels * rate;
+}
snd_soc_params_to_frame_size().
Rather snd_soc_params_to_bclk(), but thanks. I'll use that.
+static int evm_tda998x_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
+ struct snd_soc_codec *codec = rtd->codec;
+ struct snd_soc_card *soc_card = codec->card;
+ struct platform_device *pdev = to_platform_device(soc_card->dev);
+ unsigned int bclk_freq = evm_get_bclk(params);
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->sysclk;
+ int ret;
+
+ ret = snd_soc_dai_set_clkdiv(cpu_dai, 1, sysclk / bclk_freq);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "can't set CPU DAI clock divider %d\n",
+ ret);
+ return ret;
+ }
This looks like something the DAI driver ought to be able to work out
for itself based on the clock rate and sample format.
I guess that could be done.
Peter, what do you say if I set BCLK divider automatically if mcasp
set_sysclk() has been called with SND_SOC_CLOCK_IN?
+static unsigned int tda998x_hdmi_rates[] = {
+ 32000,
+ 44100,
+ 48000,
+ 88200,
+ 96000,
+};
The changelog said that 44.1kHz and its multiples couldn't be supported
- is that just the multiples?
As I mentioned earlier, that is a BBB HW limitation only, the code
bellow is able to decide what rates are available based on the sysclk rate.
+static struct snd_pcm_hw_constraint_list *evm_tda998x_rate_constraint(
+ struct snd_soc_card *soc_card)
+{
+ struct platform_device *pdev = to_platform_device(soc_card->dev);
+ unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->sysclk;
+ struct snd_pcm_hw_constraint_list *ret;
+ unsigned int *rates;
+ int i = 0, j = 0;
+
+ ret = devm_kzalloc(soc_card->dev, sizeof(*ret) +
+ sizeof(tda998x
Re: [PATCH RFC v2 REPOST 2/8] ASoC: davinci-evm: Add named clock reference to DT bindings
On 12/31/2013 03:16 PM, Mark Brown wrote:
On Fri, Dec 20, 2013 at 12:38:27PM +0200, Jyri Sarha wrote:
+static int evm_startup(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_card *soc_card = rtd->codec->card;
+ struct clk *mclk = ((struct snd_soc_card_drvdata_davinci *)
+ snd_soc_card_get_drvdata(soc_card))->mclk;
Why do you need to cast away void? Ths indicates something is going
wrong here though I can't see what.
I'll fix that.
+ mclk = of_clk_get_by_name(np, "ti,codec-clock");
+ if (PTR_ERR(mclk) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (IS_ERR(mclk)) {
+ dev_dbg(&pdev->dev, "Codec clock not found.\n");
+ mclk = NULL;
+ }
The driver will unconditionally enable and disable the clock which I'd
not expect to work well if we got an error, I'd expect either NULL checks
on use or a fixed clock to be registered from code in the case where
we're using the old binding.
In the drivers/clk/clk.c the clk == NULL is always checked before using
the pointer. However, adding NULL checks would save couple of
lock-unlock cycles. I'll add them.
I'd also expect to see devm_clk_get() used here, with the standard
clock-names based lookup from DT.
I'll fix that.
Best regards,
Jyri
--
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
