Re: [GIT PULL] omap device tree changes for v3.20, part 3
On Fri, Jan 30, 2015 at 03:55:35PM -0800, Tony Lindgren wrote: The following changes since commit 1f43c45df7afb706470f7d81d983dd7763a9452f: ARM: dts: dra72-evm: Add qspi device (2015-01-20 10:07:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/dt-pt3-v2 for you to fetch changes up to 726806ad9ba10f8ba8d26ba8154d98a7c9b89a12: ARM: dts: am57xx-beagle-x15: Fix USB2 mode (2015-01-30 15:48:39 -0800) Device tree related chages for omaps to fix dm816x syscon, fix various devices for gta04, and add USB nodes for am57xx and dra7. Merged, 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
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote: Why don't we make the legacy lookup more specific and actually indicate internal for the con_id? Then the external clock would fail to be found, but we can detect that case and figure out that it's not due to probe defer, but instead due to the fact that there really isn't any mapping. It looks like the code is already prepared for this anyway. We _could_, and that would solve this specific issue, but I'd suggest coccinelle is used to locate any other similar instances of this. As I'm allergic to coccinelle (or coccinelle is allergic to me since I never seem to be able to get it to do what I want...) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
On 02/06/2015 08:32 PM, Peter Zijlstra wrote: On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote: Certainly looks much simpler, but it adds quite a bit of data to the omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration. ls -al vmlinux w/o any the lockdep warning fixes: 110109168 With my series applied: 110112031 (base + 2863) With setting individual lockdep class: 110114275 (base + 5107) I certainly like the lockdep_set_class() way since it is cleaner, but it adds almost double amount of bytes to the kernel. Yeah, I've never really bothered with data too much, its a debug feature. So lock_class_key is 8 bytes, and strictly speaking you could union them over other fields, all we really need is unique addresses, we don't actually use the storage. True. our omap2plus defconfig does not have LOCKDEP enabled so it should not add anything to the data when running default kernel. I'll test the lockdep_set_class() method you suggested on Monday (not tomorrow), but still as first thing. If it is working as expected I'll send a patch with you as author. Thanks, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the driver wants to know if extclk and clk are the same so it can do
something differently in kirkwood_set_rate(). Do we need some sort of
clk_equal(struct clk *a, struct clk *b) function for drivers like this?
Well, the clocks in question are the SoC internal clock (which is more or
less fixed, but has a programmable divider) and an externally supplied
clock, and the IP has a multiplexer on its input which allows us to select
between those two sources.
If it were possible to bind both to the same clock, it wouldn't be a
useful configuration - nothing would be gained from doing so in terms of
available rates.
What the comparison is there for is to catch the case with legacy lookups
where a clkdev lookup entry with a NULL connection ID results in matching
any connection ID passed to clk_get(). If the patch changes this, then
we will have a regression - and this is something which needs fixing
_before_ we do this return unique clocks.
Ok. It seems that we might need a clk_equal() or similar API after all.
My understanding is that this driver is calling clk_get() twice with
NULL for the con_id and then extclk in attempts to get the SoC
internal clock and the externally supplied clock. If we're using legacy
lookups then both clk_get() calls may map to the same clk_lookup entry
and before Tomeu's patch that returns unique clocks the driver could
detect this case and know that there isn't an external clock. Looking at
arch/arm/mach-dove/common.c it seems that there is only one lookup per
device and it has a wildcard NULL for con_id so both clk_get() calls
here are going to find the same lookup and get a unique struct clk pointer.
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and figure out that it's not due to
probe defer, but instead due to the fact that there really isn't any
mapping. It looks like the code is already prepared for this anyway.
8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] ARM: dove: Remove wildcard from mvebu-audio device clk lookup
This i2s driver is using the wildcard nature of clkdev lookups to
figure out if there's an external clock or not. It does this by
calling clk_get() twice with NULL for the con_id first and then
external for the con_id the second time around and then
compares the two pointers. With DT the wildcard feature of
clk_get() is gone and so the driver has to handle an error from
the second clk_get() call as meaning no external clock
specified. Let's use that logic even with clk lookups to
simplify the code and remove the struct clk pointer comparisons
which may not work in the future when clk_get() returns unique
pointers.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
arch/arm/mach-dove/common.c | 4 ++--
sound/soc/kirkwood/kirkwood-i2s.c | 13 -
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0d1a89298ece..f290fc944cc1 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -124,8 +124,8 @@ static void __init dove_clk_init(void)
orion_clkdev_add(NULL, sdhci-dove.1, sdio1);
orion_clkdev_add(NULL, orion_nand, nand);
orion_clkdev_add(NULL, cafe1000-ccic.0, camera);
- orion_clkdev_add(NULL, mvebu-audio.0, i2s0);
- orion_clkdev_add(NULL, mvebu-audio.1, i2s1);
+ orion_clkdev_add(internal, mvebu-audio.0, i2s0);
+ orion_clkdev_add(internal, mvebu-audio.1, i2s1);
orion_clkdev_add(NULL, mv_crypto, crypto);
orion_clkdev_add(NULL, dove-ac97, ac97);
orion_clkdev_add(NULL, dove-pdma, pdma);
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c
b/sound/soc/kirkwood/kirkwood-i2s.c
index def7d8260c4e..0bfeb712a997 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -564,7 +564,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device
*pdev)
return -EINVAL;
}
- priv-clk = devm_clk_get(pdev-dev, np ? internal : NULL);
+ priv-clk = devm_clk_get(pdev-dev, internal);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, no clock\n);
return PTR_ERR(priv-clk);
@@ -579,14 +579,9 @@ static int kirkwood_i2s_dev_probe(struct platform_device
*pdev)
if (PTR_ERR(priv-extclk) == -EPROBE_DEFER)
return -EPROBE_DEFER;
} else {
- if (priv-extclk == priv-clk) {
- devm_clk_put(pdev-dev, priv-extclk);
- priv-extclk = ERR_PTR(-EINVAL);
-
[PATCH] thermal: ti-soc-thermal: fix compilation warnings when !CONFIG_PM_SLEEP
When CONFIG_PM_SLEEP=n, the following compilation warnings appear:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
‘ti_bandgap_suspend’ defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
‘ti_bandgap_resume’ defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
A few years ago, suspend/resume-related code was protected by CONFIG_PM.
But that was changed and now it's protected by CONFIG_PM_SLEEP. Fix the
warnings by converting the preprocessor test in the TI bandgap thermal
sensor driver from testing CONFIG_PM to testing CONFIG_PM_SLEEP.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
Non-critical. Targeted for either v3.20-rc1 or v3.21-rc1.
Basic test reports for a series that includes this patch (and a few other
unrelated warning cleanups) is available here:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Compare to:
http://www.pwsan.com/omap/testlogs/test_v3.19-rc7/20150204213018/
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce0e63a..62a5d449c388 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
2.1.4
[PATCH] ARM: omap1_defconfig: drop obsolete Kconfig symbols
scripts/checkkconfigsymbols.py indicates that omap1_defconfig references the following obsolete Kconfig symbols: CONFIG_BT_L2CAP CONFIG_BT_SCO CONFIG_DEBUG_ERRORS CONFIG_EXPERIMENTAL CONFIG_FB_OMAP_BOOTLOADER_INIT CONFIG_LEDS_CPU CONFIG_MACH_OMAP_HTCWIZARD CONFIG_MTD_CHAR CONFIG_MTD_DEBUG CONFIG_MTD_DEBUG_VERBOSE CONFIG_MTD_PARTITIONS CONFIG_NET_ETHERNET CONFIG_RCU_CPU_STALL_DETECTOR CONFIG_SCSI_MULTI_LUN CONFIG_USB_DEVICE_CLASS CONFIG_VIDEO_OUTPUT_CONTROL Drop them from omap1_defconfig. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Paul Bolle pebo...@tiscali.nl Cc: Valentin Rothberg valentinrothb...@gmail.com Cc: Stefan Hengelein stefan.hengel...@fau.de Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-omap@vger.kernel.org --- Non-critical. Targeted for v3.20-rc1 or v3.21-rc1. I'm unable to boot test it since I don't have any OMAP1 devices currently active in the testbed, but it least compiles and deals with the Kconfig checker warnings: http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/ arch/arm/configs/omap1_defconfig | 16 1 file changed, 16 deletions(-) diff --git a/arch/arm/configs/omap1_defconfig b/arch/arm/configs/omap1_defconfig index a7dce674f1be..0c8a78734536 100644 --- a/arch/arm/configs/omap1_defconfig +++ b/arch/arm/configs/omap1_defconfig @@ -1,4 +1,3 @@ -CONFIG_EXPERIMENTAL=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y @@ -34,7 +33,6 @@ CONFIG_ARCH_OMAP16XX=y CONFIG_MACH_OMAP_INNOVATOR=y CONFIG_MACH_OMAP_H2=y CONFIG_MACH_OMAP_H3=y -CONFIG_MACH_OMAP_HTCWIZARD=y CONFIG_MACH_HERALD=y CONFIG_MACH_OMAP_OSK=y CONFIG_MACH_OMAP_PERSEUS2=y @@ -55,7 +53,6 @@ CONFIG_HIGH_RES_TIMERS=y CONFIG_PREEMPT=y CONFIG_AEABI=y CONFIG_LEDS=y -CONFIG_LEDS_CPU=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE=root=1f03 rootfstype=jffs2 @@ -80,8 +77,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_IPV6=y CONFIG_NETFILTER=y CONFIG_BT=y -CONFIG_BT_L2CAP=y -CONFIG_BT_SCO=y CONFIG_BT_RFCOMM=y CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=y @@ -92,11 +87,7 @@ CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y # CONFIG_PROC_EVENTS is not set CONFIG_MTD=y -CONFIG_MTD_DEBUG=y -CONFIG_MTD_DEBUG_VERBOSE=3 -CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y @@ -113,11 +104,9 @@ CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_CHR_DEV_SG=y -CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_TUN=y CONFIG_PHYLIB=y -CONFIG_NET_ETHERNET=y CONFIG_SMC91X=y CONFIG_USB_CATC=y CONFIG_USB_KAWETH=y @@ -158,7 +147,6 @@ CONFIG_SPI_OMAP_UWIRE=y CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y CONFIG_OMAP_WATCHDOG=y -CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y @@ -168,7 +156,6 @@ CONFIG_FB_OMAP_LCDC_EXTERNAL=y CONFIG_FB_OMAP_LCDC_HWA742=y CONFIG_FB_OMAP_MANUAL_UPDATE=y CONFIG_FB_OMAP_LCD_MIPID=y -CONFIG_FB_OMAP_BOOTLOADER_INIT=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_FRAMEBUFFER_CONSOLE=y @@ -194,7 +181,6 @@ CONFIG_SND_OMAP_SOC=y # CONFIG_USB_HID is not set CONFIG_USB=y CONFIG_USB_PHY=y -# CONFIG_USB_DEVICE_CLASS is not set CONFIG_USB_MON=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_STORAGE=y @@ -261,9 +247,7 @@ CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set CONFIG_DEBUG_USER=y -CONFIG_DEBUG_ERRORS=y CONFIG_SECURITY=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_PCBC=y -- 2.1.4 -- 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: OMAP1: PM: fix some build warnings on 1510-only Kconfigs
Building an OMAP1510-only Kconfig generates the following warnings:
arch/arm/mach-omap1/pm.c: In function ‘omap1_pm_idle’:
arch/arm/mach-omap1/pm.c:123:2: warning: #warning Enable 32kHz OS timer in
order to allow sleep states in idle [-Wcpp]
#warning Enable 32kHz OS timer in order to allow sleep states in idle
^
arch/arm/mach-omap1/pm.c: At top level:
arch/arm/mach-omap1/pm.c:76:23: warning: ‘enable_dyn_sleep’ defined but not
used [-Wunused-variable]
static unsigned short enable_dyn_sleep = 0;
^
These are not so easy to fix in an obviously correct fashion, since I
don't have these devices up and running in my testbed. So, use
arch/arm/plat-omap/Kconfig and the existing pm.c source as a guide,
and posit that deep power saving states are only supported on OMAP16xx
chips with kernels built with both CONFIG_OMAP_DM_TIMER=y and
CONFIG_OMAP_32K_TIMER=y.
While here, clean up a few printk()s and unnecessary #ifdefs.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jon Hunter jonath...@nvidia.com
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Tuukka Tikkanen tuukka.tikka...@linaro.org
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
Hi folks, if anyone out there is still experimenting with OMAP1 PM, or has
a copy of the OMAP1510 TRMs, could you please check this patch? I'm
unable to test it since I don't have any OMAP1 devices currently active
in the testbed. It at least compiles and deals with the build warnings:
http://www.pwsan.com/omap/testlogs/fix-omap-warnings-v3.21/20150206154619/
Non-critical; targeted for v3.20-rc1 or v3.21-rc1.
arch/arm/mach-omap1/pm.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 34b4c0044961..d46d8a222fbb 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -71,13 +71,7 @@ static unsigned int
mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
-#ifndef CONFIG_OMAP_32K_TIMER
-
-static unsigned short enable_dyn_sleep = 0;
-
-#else
-
-static unsigned short enable_dyn_sleep = 1;
+static unsigned short enable_dyn_sleep;
static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
@@ -90,8 +84,9 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
{
unsigned short value;
if (sscanf(buf, %hu, value) != 1 ||
- (value != 0 value != 1)) {
- printk(KERN_ERR idle_sleep_store: Invalid value\n);
+ (value != 0 value != 1) ||
+ (value != 0 !IS_ENABLED(CONFIG_OMAP_32K_TIMER))) {
+ pr_err(idle_sleep_store: Invalid value\n);
return -EINVAL;
}
enable_dyn_sleep = value;
@@ -101,7 +96,6 @@ static ssize_t idle_store(struct kobject *kobj, struct
kobj_attribute *attr,
static struct kobj_attribute sleep_while_idle_attr =
__ATTR(sleep_while_idle, 0644, idle_show, idle_store);
-#endif
static void (*omap_sram_suspend)(unsigned long r0, unsigned long r1) = NULL;
@@ -120,12 +114,11 @@ void omap1_pm_idle(void)
local_fiq_disable();
#if defined(CONFIG_OMAP_MPU_TIMER) !defined(CONFIG_OMAP_DM_TIMER)
-#warning Enable 32kHz OS timer in order to allow sleep states in idle
use_idlect1 = use_idlect1 ~(1 9);
-#else
+#endif
+
if (enable_dyn_sleep)
do_sleep = 1;
-#endif
#ifdef CONFIG_OMAP_DM_TIMER
use_idlect1 = omap_dm_timer_modify_idlect_mask(use_idlect1);
@@ -635,15 +628,24 @@ static const struct platform_suspend_ops omap_pm_ops = {
static int __init omap_pm_init(void)
{
-
-#ifdef CONFIG_OMAP_32K_TIMER
- int error;
-#endif
+ int error = 0;
if (!cpu_class_is_omap1())
return -ENODEV;
- printk(Power Management for TI OMAP.\n);
+ pr_info(Power Management for TI OMAP.\n);
+
+ if (!IS_ENABLED(CONFIG_OMAP_32K_TIMER))
+ pr_info(OMAP1 PM: sleep states in idle disabled due to no
32KiHz timer\n);
+
+ if (!IS_ENABLED(CONFIG_OMAP_DM_TIMER))
+ pr_info(OMAP1 PM: sleep states in idle disabled due to no
DMTIMER support\n);
+
+ if (IS_ENABLED(CONFIG_OMAP_32K_TIMER)
+ IS_ENABLED(CONFIG_OMAP_DM_TIMER) cpu_is_omap16xx()) {
+ pr_info(OMAP1 PM: sleep states in idle enabled\n);
+ enable_dyn_sleep = 1;
+ }
/*
* We copy the assembler sleep/wakeup routines to SRAM.
@@ -693,17 +695,15 @@ static int __init omap_pm_init(void)
omap_pm_init_debugfs();
#endif
-#ifdef CONFIG_OMAP_32K_TIMER
error = sysfs_create_file(power_kobj,
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 02/06/15 11:37, Russell King - ARM Linux wrote: On Fri, Feb 06, 2015 at 11:30:18AM -0800, Stephen Boyd wrote: Why don't we make the legacy lookup more specific and actually indicate internal for the con_id? Then the external clock would fail to be found, but we can detect that case and figure out that it's not due to probe defer, but instead due to the fact that there really isn't any mapping. It looks like the code is already prepared for this anyway. We _could_, and that would solve this specific issue, but I'd suggest coccinelle is used to locate any other similar instances of this. As I'm allergic to coccinelle (or coccinelle is allergic to me since I never seem to be able to get it to do what I want...) Great. I'd like to avoid adding clk_equal() until we actually need it, and I hope we don't ever need it. We've already got coccinelle in the works to find similar issues and it seems you and I have the same allergies because I can't get it to work for me right now. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/2] usb: dwc3: ep0: preparation for implementing chained TRB
No functional change. Modified few things so that there are no
code duplication while implementing chained TRB.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/ep0.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 2ef3c8d..24b7925 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -779,7 +779,10 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
struct usb_request *ur;
struct dwc3_trb *trb;
struct dwc3_ep *ep0;
- u32 transferred;
+ unsignedtransfer_size = 0;
+ unsignedmaxp;
+ void*buf;
+ u32 transferred = 0;
u32 status;
u32 length;
u8 epnum;
@@ -808,16 +811,17 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
}
ur = r-request;
+ buf = ur-buf;
length = trb-size DWC3_TRB_SIZE_MASK;
- if (dwc-ep0_bounced) {
- unsigned transfer_size = ur-length;
- unsigned maxp = ep0-endpoint.maxpacket;
+ maxp = ep0-endpoint.maxpacket;
- transfer_size += (maxp - (transfer_size % maxp));
- transferred = min_t(u32, ur-length,
- transfer_size - length);
+ if (dwc-ep0_bounced) {
+ transfer_size = roundup((ur-length - transfer_size),
+ maxp);
+ transferred = min_t(u32, ur-length - transferred,
+ transfer_size - length);
memcpy(ur-buf, dwc-ep0_bounce, transferred);
} else {
transferred = ur-length - length;
@@ -927,7 +931,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
DWC3_TRBCTL_CONTROL_DATA);
} else if (!IS_ALIGNED(req-request.length, dep-endpoint.maxpacket)
(dep-number == 0)) {
- u32 transfer_size;
+ u32 transfer_size = 0;
u32 maxpacket;
ret = usb_gadget_map_request(dwc-gadget, req-request,
@@ -940,7 +944,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
WARN_ON(req-request.length DWC3_EP0_BOUNCE_SIZE);
maxpacket = dep-endpoint.maxpacket;
- transfer_size = roundup(req-request.length, maxpacket);
+ transfer_size = roundup((req-request.length - transfer_size),
+ maxpacket);
dwc-ep0_bounced = true;
--
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
[RFC PATCH 2/2] usb: dwc3: Add chained TRB support for ep0
dwc3 can do only max packet aligned transfers. So in case request length
is not max packet aligned and is bigger than DWC3_EP0_BOUNCE_SIZE
two chained TRBs is required to handle the transfer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
*) Did eumeration testing with g_zero in kernel
*) Similar patch was added in u-boot. With DFU, was able to create a scenario
where the request length is not max packet aligned and is bigger than
DWC3_EP0_BOUNCE_SIZE (512 bytes). In that case, 2 chained TRBs will be used.
drivers/usb/dwc3/ep0.c| 65 +
drivers/usb/dwc3/gadget.c |2 +-
2 files changed, 49 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 24b7925..3b728b8 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state
state)
}
static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t buf_dma,
- u32 len, u32 type)
+ u32 len, u32 type, unsigned chain)
{
struct dwc3_gadget_ep_cmd_params params;
struct dwc3_trb *trb;
@@ -70,7 +70,10 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
return 0;
}
- trb = dwc-ep0_trb;
+ trb = dwc-ep0_trb[dep-free_slot];
+
+ if (chain)
+ dep-free_slot++;
trb-bpl = lower_32_bits(buf_dma);
trb-bph = upper_32_bits(buf_dma);
@@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
trb-ctrl = type;
trb-ctrl |= (DWC3_TRB_CTRL_HWO
- | DWC3_TRB_CTRL_LST
- | DWC3_TRB_CTRL_IOC
| DWC3_TRB_CTRL_ISP_IMI);
+ if (chain)
+ trb-ctrl |= DWC3_TRB_CTRL_CHN;
+ else
+ trb-ctrl |= (DWC3_TRB_CTRL_IOC
+ | DWC3_TRB_CTRL_LST);
+
+ if (chain)
+ return 0;
+
memset(params, 0, sizeof(params));
params.param0 = upper_32_bits(dwc-ep0_trb_addr);
params.param1 = lower_32_bits(dwc-ep0_trb_addr);
@@ -302,7 +312,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
int ret;
ret = dwc3_ep0_start_trans(dwc, 0, dwc-ctrl_req_addr, 8,
- DWC3_TRBCTL_CONTROL_SETUP);
+ DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret 0);
}
@@ -817,6 +827,22 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
maxp = ep0-endpoint.maxpacket;
+ /* Handle the first TRB before handling the bounce buffer if the request
+* length is greater than the bounce buffer size
+*/
+ if (!IS_ALIGNED(ur-length, maxp)
+ ur-length DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = (ur-length / maxp) * maxp;
+ transferred = transfer_size - length;
+ buf = (u8 *)buf + transferred;
+ ur-actual += transferred;
+
+ trb++;
+ length = trb-size DWC3_TRB_SIZE_MASK;
+
+ ep0-free_slot = 0;
+ }
+
if (dwc-ep0_bounced) {
transfer_size = roundup((ur-length - transfer_size),
maxp);
@@ -844,7 +870,7 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
ret = dwc3_ep0_start_trans(dwc, epnum,
dwc-ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
WARN_ON(ret 0);
}
}
@@ -928,7 +954,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
if (req-request.length == 0) {
ret = dwc3_ep0_start_trans(dwc, dep-number,
dwc-ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
} else if (!IS_ALIGNED(req-request.length, dep-endpoint.maxpacket)
(dep-number == 0)) {
u32 transfer_size = 0;
@@ -941,22 +967,26 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
return;
}
- WARN_ON(req-request.length DWC3_EP0_BOUNCE_SIZE);
-
maxpacket = dep-endpoint.maxpacket;
+
+ if (req-request.length DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = (req-request.length / maxpacket) *
+ maxpacket;
+ ret = dwc3_ep0_start_trans(dwc, dep-number,
+ req-request.dma,
+ transfer_size,
+
Re: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On Fri, 6 Feb 2015, Quentin Lambert wrote: On 06/02/2015 03:15, Stephen Boyd wrote: Thanks for the coccinelle patch. Thinking more about it, I don't think we care if the pointer is dereferenced because that would require a definition of struct clk and that is most likely not the case outside of the clock framework. Did you scan the entire kernel? No I haven't. I'm running it now but it seems to be taking a while. Yes, that's why, as a first step, I chose to limit the scan to the arm directory. Are you sure to be using all of the options provided: // Options: --recursive-includes --relax-include-path // Options: --include-headers-for-types And are you using 1.0.0-rc23 or 1.0.0-rc24? Those should save parsed header files so that they don't have to be parsed over and over. If you are using rc24, then you can use the -j option for parallelism. But then you should also use an option like --chunksize 10 (I don't know what number would be good), because the default is chunksize 1, and in that case the saved parsed header files are not reused, because the fies are all processed individually. In general, it is only the files within a chunk that will share parsed header files. julia -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
On Fri, Feb 06, 2015 at 02:48:34PM +0200, Peter Ujfalusi wrote:
Hi,
In case when hwmods are used in nested way the lockdep validator will print
out
a warning message about possible deadlock situation:
[4.514882] =
[4.520530] [ INFO: possible recursive locking detected ]
[4.526176] 3.14.30-00289-ge44872fdca8f-dirty #198 Not tainted
[4.532285] -
[4.537936] kworker/u4:1/18 is trying to acquire lock:
[4.543317] ((oh-_lock)-rlock){..}, at: [c002d2dc]
omap_hwmod_enable+0x2c/0x58
[4.552109]
[4.552109] but task is already holding lock:
[4.558216] ((oh-_lock)-rlock){..}, at: [c002d2dc]
omap_hwmod_enable+0x2c/0x58
[4.566999]
[4.566999] other info that might help us debug this:
[4.573831] Possible unsafe locking scenario:
[4.573831]
[4.580025]CPU0
[4.582584]
[4.585142] lock((oh-_lock)-rlock);
[4.589544] lock((oh-_lock)-rlock);
[4.593945]
[4.593945] *** DEADLOCK ***
[4.593945]
[4.600146] May be due to missing lock nesting notation
What lockdep did not realizes is that the two oh is not the same hwmod object
and we have taken different locks.
One example of nested hwmod usage is on DRA7xx platforms, where McASP can be
configured to use ATL clock as it's functional clock. In this case the
pm_runtime_get/put_sync call will enable the mcasp hwmod and as part of this
operation it will enable the needed clocks. Since ATL clock is needed, we will
have another pm_runtime operation from the ATL clock enable callback which
will take the atl hwmod's lock. This will be seen by lockdep as possible
deadlock situation.
In order to notify lockdep about this, we need to switch using _nested
version of locking function and assign different subclass to those hwmods
which
could be used in nested way.
IFF struct omap_hwmod is always statically allocated; as I think the
__init on _register() mandates, you can use the below annotation.
---
arch/arm/mach-omap2/omap_hwmod.c | 1 +
arch/arm/mach-omap2/omap_hwmod.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 9025d2dc..222d654ad6fd 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2698,6 +2698,7 @@ static int __init _register(struct omap_hwmod *oh)
INIT_LIST_HEAD(oh-master_ports);
INIT_LIST_HEAD(oh-slave_ports);
spin_lock_init(oh-_lock);
+ lockdep_set_class(oh-_lock, oh-hwmod_key);
oh-_state = _HWMOD_STATE_REGISTERED;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 5b42fafcaf55..754bdfb3f811 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -689,6 +689,8 @@ struct omap_hwmod {
u8 _state;
u8 _postsetup_state;
struct omap_hwmod *parent_hwmod;
+
+ struct lock_class_key hwmod_key;
};
struct omap_hwmod *omap_hwmod_lookup(const char *name);
--
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: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 06/02/2015 03:15, Stephen Boyd wrote: Thanks for the coccinelle patch. Thinking more about it, I don't think we care if the pointer is dereferenced because that would require a definition of struct clk and that is most likely not the case outside of the clock framework. Did you scan the entire kernel? No I haven't. I'm running it now but it seems to be taking a while. Yes, that's why, as a first step, I chose to limit the scan to the arm directory. -- 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] thermal: ti-soc-thermal: bandgap: Fix build warning if !CONFIG_PM_SLEEP
From: Grygorii Strashko grygorii.stras...@linaro.org
Fix following build warning if CONFIG_PM_SLEEP is not set:
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning:
'ti_bandgap_suspend' defined but not used [-Wunused-function]
static int ti_bandgap_suspend(struct device *dev)
^
drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning:
'ti_bandgap_resume' defined but not used [-Wunused-function]
static int ti_bandgap_resume(struct device *dev)
^
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
---
drivers/thermal/ti-soc-thermal/ti-bandgap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 74c0e34..5d46660 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -1402,7 +1402,7 @@ int ti_bandgap_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int ti_bandgap_save_ctxt(struct ti_bandgap *bgp)
{
int i;
--
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 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
On 02/06/2015 04:13 PM, Peter Zijlstra wrote:
On Fri, Feb 06, 2015 at 02:48:34PM +0200, Peter Ujfalusi wrote:
Hi,
In case when hwmods are used in nested way the lockdep validator will print
out
a warning message about possible deadlock situation:
[4.514882] =
[4.520530] [ INFO: possible recursive locking detected ]
[4.526176] 3.14.30-00289-ge44872fdca8f-dirty #198 Not tainted
[4.532285] -
[4.537936] kworker/u4:1/18 is trying to acquire lock:
[4.543317] ((oh-_lock)-rlock){..}, at: [c002d2dc]
omap_hwmod_enable+0x2c/0x58
[4.552109]
[4.552109] but task is already holding lock:
[4.558216] ((oh-_lock)-rlock){..}, at: [c002d2dc]
omap_hwmod_enable+0x2c/0x58
[4.566999]
[4.566999] other info that might help us debug this:
[4.573831] Possible unsafe locking scenario:
[4.573831]
[4.580025]CPU0
[4.582584]
[4.585142] lock((oh-_lock)-rlock);
[4.589544] lock((oh-_lock)-rlock);
[4.593945]
[4.593945] *** DEADLOCK ***
[4.593945]
[4.600146] May be due to missing lock nesting notation
What lockdep did not realizes is that the two oh is not the same hwmod object
and we have taken different locks.
One example of nested hwmod usage is on DRA7xx platforms, where McASP can be
configured to use ATL clock as it's functional clock. In this case the
pm_runtime_get/put_sync call will enable the mcasp hwmod and as part of this
operation it will enable the needed clocks. Since ATL clock is needed, we
will
have another pm_runtime operation from the ATL clock enable callback which
will take the atl hwmod's lock. This will be seen by lockdep as possible
deadlock situation.
In order to notify lockdep about this, we need to switch using _nested
version of locking function and assign different subclass to those hwmods
which
could be used in nested way.
IFF struct omap_hwmod is always statically allocated; as I think the
__init on _register() mandates, you can use the below annotation.
---
arch/arm/mach-omap2/omap_hwmod.c | 1 +
arch/arm/mach-omap2/omap_hwmod.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 9025d2dc..222d654ad6fd 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2698,6 +2698,7 @@ static int __init _register(struct omap_hwmod *oh)
INIT_LIST_HEAD(oh-master_ports);
INIT_LIST_HEAD(oh-slave_ports);
spin_lock_init(oh-_lock);
+ lockdep_set_class(oh-_lock, oh-hwmod_key);
oh-_state = _HWMOD_STATE_REGISTERED;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h
b/arch/arm/mach-omap2/omap_hwmod.h
index 5b42fafcaf55..754bdfb3f811 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -689,6 +689,8 @@ struct omap_hwmod {
u8 _state;
u8 _postsetup_state;
struct omap_hwmod *parent_hwmod;
+
+ struct lock_class_key hwmod_key;
};
struct omap_hwmod *omap_hwmod_lookup(const char *name);
Certainly looks much simpler, but it adds quite a bit of data to the
omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration.
ls -al vmlinux
w/o any the lockdep warning fixes:
110109168
With my series applied:
110112031 (base + 2863)
With setting individual lockdep class:
110114275 (base + 5107)
I certainly like the lockdep_set_class() way since it is cleaner, but it adds
almost double amount of bytes to the kernel.
I'll test the patch on my board tomorrow as first thing.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Cocci] [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On 02/06/15 01:12, Julia Lawall wrote: On Fri, 6 Feb 2015, Quentin Lambert wrote: On 06/02/2015 03:15, Stephen Boyd wrote: Thanks for the coccinelle patch. Thinking more about it, I don't think we care if the pointer is dereferenced because that would require a definition of struct clk and that is most likely not the case outside of the clock framework. Did you scan the entire kernel? No I haven't. I'm running it now but it seems to be taking a while. Yes, that's why, as a first step, I chose to limit the scan to the arm directory. Are you sure to be using all of the options provided: // Options: --recursive-includes --relax-include-path // Options: --include-headers-for-types And are you using 1.0.0-rc23 or 1.0.0-rc24? Those should save parsed header files so that they don't have to be parsed over and over. If you are using rc24, then you can use the -j option for parallelism. But then you should also use an option like --chunksize 10 (I don't know what number would be good), because the default is chunksize 1, and in that case the saved parsed header files are not reused, because the fies are all processed individually. In general, it is only the files within a chunk that will share parsed header files. Thanks for the info. $ spatch --version spatch version 1.0.0-rc22 with Python support and with PCRE support so I guess I need to update. I tried throwing it into scripts/coccinelle/misc and then did make O=../obj/ coccicheck COCCI=../kernel/scripts/coccinelle/misc/structclk.cocci at the toplevel but it didn't find anything. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: musb: Fix getting a generic phy for musb_dsps
* George Cherian george.cher...@ti.com [150206 05:05]:
Hi Tony,
You also need to add similar things in dsps_musb_reset();
Otherwise you might not recover from a BABBLE condition.
Thank I totally missed that, updated patch below.
Do you have some testcase that easily triggers BABBLE
on MUSB?
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 4 Feb 2015 06:28:49 -0800
Subject: [PATCH] usb: musb: Fix getting a generic phy for musb_dsps
We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -457,12 +457,27 @@ static int dsps_musb_init(struct musb *musb)
if (IS_ERR(musb-xceiv))
return PTR_ERR(musb-xceiv);
+ musb-phy = devm_phy_get(dev-parent, usb2-phy);
+
/* Returns zero if e.g. not clocked */
rev = dsps_readl(reg_base, wrp-revision);
if (!rev)
return -ENODEV;
usb_phy_init(musb-xceiv);
+ if (IS_ERR(musb-phy)) {
+ musb-phy = NULL;
+ } else {
+ ret = phy_init(musb-phy);
+ if (ret 0)
+ return ret;
+ ret = phy_power_on(musb-phy);
+ if (ret) {
+ phy_exit(musb-phy);
+ return ret;
+ }
+ }
+
setup_timer(glue-timer, otg_timer, (unsigned long) musb);
/* Reset the musb */
@@ -502,6 +517,8 @@ static int dsps_musb_exit(struct musb *musb)
del_timer_sync(glue-timer);
usb_phy_shutdown(musb-xceiv);
+ phy_power_off(musb-phy);
+ phy_exit(musb-phy);
debugfs_remove_recursive(glue-dbgfs_root);
return 0;
@@ -610,7 +627,7 @@ static int dsps_musb_reset(struct musb *musb)
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
const struct dsps_musb_wrapper *wrp = glue-wrp;
- int session_restart = 0;
+ int session_restart = 0, error;
if (glue-sw_babble_enabled)
session_restart = sw_babble_control(musb);
@@ -624,8 +641,14 @@ static int dsps_musb_reset(struct musb *musb)
dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
usleep_range(100, 200);
usb_phy_shutdown(musb-xceiv);
+ error = phy_power_off(musb-phy);
+ if (error)
+ dev_err(dev, phy shutdown failed: %i\n, error);
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ error = phy_power_on(musb-phy);
+ if (error)
+ dev_err(dev, phy powerup failed: %i\n, error);
session_restart = 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 2/2] usb: musb: Fix getting a generic phy for musb_dsps
Hi Tony,
You also need to add similar things in dsps_musb_reset();
Otherwise you might not recover from a BABBLE condition.
On 02/05/2015 10:05 PM, Tony Lindgren wrote:
We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/usb/musb/musb_dsps.c | 17 +
1 file changed, 17 insertions(+)
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -457,12 +457,25 @@ static int dsps_musb_init(struct musb *musb)
if (IS_ERR(musb-xceiv))
return PTR_ERR(musb-xceiv);
+ musb-phy = devm_phy_get(dev-parent, usb2-phy);
+
/* Returns zero if e.g. not clocked */
rev = dsps_readl(reg_base, wrp-revision);
if (!rev)
return -ENODEV;
usb_phy_init(musb-xceiv);
+ if (IS_ERR(musb-phy)) {
+ musb-phy = NULL;
+ } else {
+ ret = phy_init(musb-phy);
+ if (ret 0)
+ return ret;
+ ret = phy_power_on(musb-phy);
+ if (ret)
+ return ret;
+ }
+
setup_timer(glue-timer, otg_timer, (unsigned long) musb);
/* Reset the musb */
@@ -502,6 +515,10 @@ static int dsps_musb_exit(struct musb *musb)
del_timer_sync(glue-timer);
usb_phy_shutdown(musb-xceiv);
+ if (musb-phy) {
+ phy_power_off(musb-phy);
+ phy_exit(musb-phy);
+ }
debugfs_remove_recursive(glue-dbgfs_root);
return 0;
-George
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: DRA7: hwmod_data: Change locked_class for atl hwmod
The ATL hwmod can be used in nested way when it is selected to be the
functional clock for McASP. For this lockdep validator will trigger false
positive warning.
By assigning separate class to atl locking will sort this out.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..87f259e8c574 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -185,6 +185,7 @@ static struct omap_hwmod dra7xx_atl_hwmod = {
.class = dra7xx_atl_hwmod_class,
.clkdm_name = atl_clkdm,
.main_clk = atl_gfclk_mux,
+ .lockdep_class = HWMOD_LOCKDEP_SUBCLASS_CLASS1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_ATL_ATL_CLKCTRL_OFFSET,
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
Hi,
In case when hwmods are used in nested way the lockdep validator will print out
a warning message about possible deadlock situation:
[4.514882] =
[4.520530] [ INFO: possible recursive locking detected ]
[4.526176] 3.14.30-00289-ge44872fdca8f-dirty #198 Not tainted
[4.532285] -
[4.537936] kworker/u4:1/18 is trying to acquire lock:
[4.543317] ((oh-_lock)-rlock){..}, at: [c002d2dc]
omap_hwmod_enable+0x2c/0x58
[4.552109]
[4.552109] but task is already holding lock:
[4.558216] ((oh-_lock)-rlock){..}, at: [c002d2dc]
omap_hwmod_enable+0x2c/0x58
[4.566999]
[4.566999] other info that might help us debug this:
[4.573831] Possible unsafe locking scenario:
[4.573831]
[4.580025]CPU0
[4.582584]
[4.585142] lock((oh-_lock)-rlock);
[4.589544] lock((oh-_lock)-rlock);
[4.593945]
[4.593945] *** DEADLOCK ***
[4.593945]
[4.600146] May be due to missing lock nesting notation
What lockdep did not realizes is that the two oh is not the same hwmod object
and we have taken different locks.
One example of nested hwmod usage is on DRA7xx platforms, where McASP can be
configured to use ATL clock as it's functional clock. In this case the
pm_runtime_get/put_sync call will enable the mcasp hwmod and as part of this
operation it will enable the needed clocks. Since ATL clock is needed, we will
have another pm_runtime operation from the ATL clock enable callback which
will take the atl hwmod's lock. This will be seen by lockdep as possible
deadlock situation.
In order to notify lockdep about this, we need to switch using _nested
version of locking function and assign different subclass to those hwmods which
could be used in nested way.
Regards,
Peter
---
Peter Ujfalusi (2):
ARM: omap2+: omap_hwmod: Use _nested version of spinlock for oh-_lock
ARM: DRA7: hwmod_data: Change locked_class for atl hwmod
arch/arm/mach-omap2/omap_hwmod.c | 16
arch/arm/mach-omap2/omap_hwmod.h | 5 +
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
3 files changed, 14 insertions(+), 8 deletions(-)
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: omap2+: omap_hwmod: Use _nested version of spinlock for oh-_lock
Add lockdep_class member to struct omap_hwmod and use this number to
specify the subclass of the given hwmod's lock.
When defining the hwmods the lockdep_level can be initialized to indicate
that this lock might be used in a nested fashion.
DRA7x's ATL hwmod is one example for this since McASP can select ATL clock
as functional clock, which will trigger nested oh-_lock usage. This will
trigger false warning from lockdep validator since it is dealing with
classes and for it all hwmod clocks are the same class.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 16
arch/arm/mach-omap2/omap_hwmod.h | 5 +
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 92afb723dcfc..b5afde560054 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3334,7 +3334,7 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
r = _enable(oh);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3355,7 +3355,7 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
_idle(oh);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3377,7 +3377,7 @@ int omap_hwmod_shutdown(struct omap_hwmod *oh)
if (!oh)
return -EINVAL;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
_shutdown(oh);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3667,7 +3667,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
if (oh-class-sysc
(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
@@ -3700,7 +3700,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
if (oh-class-sysc
(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
@@ -3735,7 +3735,7 @@ int omap_hwmod_assert_hardreset(struct omap_hwmod *oh,
const char *name)
if (!oh)
return -EINVAL;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
ret = _assert_hardreset(oh, name);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3762,7 +3762,7 @@ int omap_hwmod_deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (!oh)
return -EINVAL;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
ret = _deassert_hardreset(oh, name);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -3836,7 +3836,7 @@ int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh,
u8 state)
state != _HWMOD_STATE_IDLE)
return -EINVAL;
- spin_lock_irqsave(oh-_lock, flags);
+ spin_lock_irqsave_nested(oh-_lock, flags, oh-lockdep_class);
if (oh-_state != _HWMOD_STATE_REGISTERED) {
ret = -EINVAL;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 9d4bec6ee742..260d3e9c9f6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -606,6 +606,9 @@ struct omap_hwmod_link {
struct list_headnode;
};
+#define HWMOD_LOCKDEP_SUBCLASS_NORMAL 0
+#define HWMOD_LOCKDEP_SUBCLASS_CLASS1 1 /* might be used as nested */
+
/**
* struct omap_hwmod - integration data for OMAP hardware modules (IP blocks)
* @name: name of the hwmod
@@ -632,6 +635,7 @@ struct omap_hwmod_link {
* @_postsetup_state: internal-use state to leave the hwmod in after _setup()
* @flags: hwmod flags (documented below)
* @_lock: spinlock serializing operations on this hwmod
+ * @lockdep_class: subclass to use with spin_lock_irqsave_nested()
* @node: list node for hwmod list (internal use)
* @parent_hwmod: (temporary) a pointer to the hierarchical parent of this
hwmod
*
@@ -674,6 +678,7 @@ struct omap_hwmod {
u32 _sysc_cache;
void __iomem*_mpu_rt_va;
spinlock_t _lock;
+ unsigned intlockdep_class;
struct list_headnode;
struct omap_hwmod_ocp_if*_mpu_port;
unsigned int(*xlate_irq)(unsigned int);
--
2.2.2
--
To unsubscribe from this list: send the line
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
On 02/05/15 16:42, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 02:14:01PM -0800, Stephen Boyd wrote:
Actually we can bury the __clk_create_clk() inside
__of_clk_get_from_provider(). We should also move __clk_get() into there
because right now we have a hole where whoever calls
of_clk_get_from_provider() never calls __clk_get() on the clk, leading
to possible badness. v2 coming soon.
There's some other issues here too...
sound/soc/kirkwood/kirkwood-i2s.c:
priv-clk = devm_clk_get(pdev-dev, np ? internal : NULL);
...
priv-extclk = devm_clk_get(pdev-dev, extclk);
if (IS_ERR(priv-extclk)) {
...
} else {
if (priv-extclk == priv-clk) {
devm_clk_put(pdev-dev, priv-extclk);
priv-extclk = ERR_PTR(-EINVAL);
} else {
dev_info(pdev-dev, found external clock\n);
clk_prepare_enable(priv-extclk);
soc_dai = kirkwood_i2s_dai_extclk;
}
It should be fine provided your trick is only done for DT clocks,
but not for legacy - with legacy, a NULL in the clkdev tables will
match both these requests, hence the need to compare the clk_get()
return value to tell whether we get the same clock.
Are we still talking about of_clk_get_from_provider()? Or are we talking
about comparing struct clk pointers?
Comparing struct clk pointers, and the implications of the patch changing
the clk_get() et.al. to be unique struct clk pointers.
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the driver wants to know if extclk and clk are the same so it can do
something differently in kirkwood_set_rate(). Do we need some sort of
clk_equal(struct clk *a, struct clk *b) function for drivers like this?
Well, the clocks in question are the SoC internal clock (which is more or
less fixed, but has a programmable divider) and an externally supplied
clock, and the IP has a multiplexer on its input which allows us to select
between those two sources.
If it were possible to bind both to the same clock, it wouldn't be a
useful configuration - nothing would be gained from doing so in terms of
available rates.
What the comparison is there for is to catch the case with legacy lookups
where a clkdev lookup entry with a NULL connection ID results in matching
any connection ID passed to clk_get(). If the patch changes this, then
we will have a regression - and this is something which needs fixing
_before_ we do this return unique clocks.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] usb: dwc3: Add chained TRB support for ep0
Hi,
On Fri, Feb 06, 2015 at 05:25:35PM +0530, Kishon Vijay Abraham I wrote:
dwc3 can do only max packet aligned transfers. So in case request length
is not max packet aligned and is bigger than DWC3_EP0_BOUNCE_SIZE
two chained TRBs is required to handle the transfer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
*) Did eumeration testing with g_zero in kernel
*) Similar patch was added in u-boot. With DFU, was able to create a scenario
where the request length is not max packet aligned and is bigger than
DWC3_EP0_BOUNCE_SIZE (512 bytes). In that case, 2 chained TRBs will be used.
I really need a test case for this. If you have to patch g_zero to have
a configuration descriptor so large that it's over 512, so be it, but I
really need to have a test case exposing the problem.
I also need you to run full USB30CV (for USB2 and USB3 device), together
with Link Layer Tests (on USB3-only, clearly) using USB30CV and LeCroy's
compliance suite (there's a slight difference from USB30CV and LeCroy's
compliance, we must work with both because both are accepted test
vectors per USB-IF).
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 24b7925..3b728b8 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum
dwc3_ep0_state state)
}
static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t
buf_dma,
- u32 len, u32 type)
+ u32 len, u32 type, unsigned chain)
{
struct dwc3_gadget_ep_cmd_params params;
struct dwc3_trb *trb;
@@ -70,7 +70,10 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8
epnum, dma_addr_t buf_dma,
return 0;
}
- trb = dwc-ep0_trb;
+ trb = dwc-ep0_trb[dep-free_slot];
+
+ if (chain)
+ dep-free_slot++;
trb-bpl = lower_32_bits(buf_dma);
trb-bph = upper_32_bits(buf_dma);
@@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8
epnum, dma_addr_t buf_dma,
trb-ctrl = type;
trb-ctrl |= (DWC3_TRB_CTRL_HWO
- | DWC3_TRB_CTRL_LST
- | DWC3_TRB_CTRL_IOC
| DWC3_TRB_CTRL_ISP_IMI);
+ if (chain)
+ trb-ctrl |= DWC3_TRB_CTRL_CHN;
+ else
+ trb-ctrl |= (DWC3_TRB_CTRL_IOC
+ | DWC3_TRB_CTRL_LST);
+
+ if (chain)
+ return 0;
+
memset(params, 0, sizeof(params));
params.param0 = upper_32_bits(dwc-ep0_trb_addr);
params.param1 = lower_32_bits(dwc-ep0_trb_addr);
@@ -302,7 +312,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
int ret;
ret = dwc3_ep0_start_trans(dwc, 0, dwc-ctrl_req_addr, 8,
- DWC3_TRBCTL_CONTROL_SETUP);
+ DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret 0);
}
@@ -817,6 +827,22 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
maxp = ep0-endpoint.maxpacket;
+ /* Handle the first TRB before handling the bounce buffer if the request
+ * length is greater than the bounce buffer size
+ */
+ if (!IS_ALIGNED(ur-length, maxp)
+ ur-length DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = (ur-length / maxp) * maxp;
you can use ALIGN() for this which is more efficient. Note however that
this is not safe, see below.
+ transferred = transfer_size - length;
+ buf = (u8 *)buf + transferred;
+ ur-actual += transferred;
this is dangerous. The extra size is because you *must* align OUT to
wMaxPacketSize, so you cannot allow more than the original req-length
to be copied into buf. That bounce buffer, is really supposed to be a
throw-away buffer and should never have data in it. You should really
add a big fat WARN() if transferred req-length.
The thing is that if host sends more data than we were expecting, this
could be someone trying to use our driver as an exploit vector, trying
to send more data than it should. We must be robust against that.
+
+ trb++;
+ length = trb-size DWC3_TRB_SIZE_MASK;
+
+ ep0-free_slot = 0;
+ }
+
if (dwc-ep0_bounced) {
transfer_size = roundup((ur-length - transfer_size),
maxp);
@@ -844,7 +870,7 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
ret = dwc3_ep0_start_trans(dwc, epnum,
dwc-ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
WARN_ON(ret 0);
}
}
@@ -928,7 +954,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
if (req-request.length == 0) {
ret =
Re: [PATCH 2/2] usb: musb: Fix getting a generic phy for musb_dsps
Tony,
On Fri, Feb 6, 2015 at 11:23 AM, Tony Lindgren t...@atomide.com wrote:
* George Cherian george.cher...@ti.com [150206 05:05]:
Hi Tony,
You also need to add similar things in dsps_musb_reset();
Otherwise you might not recover from a BABBLE condition.
Thank I totally missed that, updated patch below.
Do you have some testcase that easily triggers BABBLE
on MUSB?
I normally just shorten DP or DM to VBUS to trigger babble. No device
is connected to the port, if I remembered correctly.
Regards,
-Bin.
Regards,
Tony
8 --
From: Tony Lindgren t...@atomide.com
Date: Wed, 4 Feb 2015 06:28:49 -0800
Subject: [PATCH] usb: musb: Fix getting a generic phy for musb_dsps
We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.
Cc: Brian Hutchinson b.hutch...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -457,12 +457,27 @@ static int dsps_musb_init(struct musb *musb)
if (IS_ERR(musb-xceiv))
return PTR_ERR(musb-xceiv);
+ musb-phy = devm_phy_get(dev-parent, usb2-phy);
+
/* Returns zero if e.g. not clocked */
rev = dsps_readl(reg_base, wrp-revision);
if (!rev)
return -ENODEV;
usb_phy_init(musb-xceiv);
+ if (IS_ERR(musb-phy)) {
+ musb-phy = NULL;
+ } else {
+ ret = phy_init(musb-phy);
+ if (ret 0)
+ return ret;
+ ret = phy_power_on(musb-phy);
+ if (ret) {
+ phy_exit(musb-phy);
+ return ret;
+ }
+ }
+
setup_timer(glue-timer, otg_timer, (unsigned long) musb);
/* Reset the musb */
@@ -502,6 +517,8 @@ static int dsps_musb_exit(struct musb *musb)
del_timer_sync(glue-timer);
usb_phy_shutdown(musb-xceiv);
+ phy_power_off(musb-phy);
+ phy_exit(musb-phy);
debugfs_remove_recursive(glue-dbgfs_root);
return 0;
@@ -610,7 +627,7 @@ static int dsps_musb_reset(struct musb *musb)
struct device *dev = musb-controller;
struct dsps_glue *glue = dev_get_drvdata(dev-parent);
const struct dsps_musb_wrapper *wrp = glue-wrp;
- int session_restart = 0;
+ int session_restart = 0, error;
if (glue-sw_babble_enabled)
session_restart = sw_babble_control(musb);
@@ -624,8 +641,14 @@ static int dsps_musb_reset(struct musb *musb)
dsps_writel(musb-ctrl_base, wrp-control, (1 wrp-reset));
usleep_range(100, 200);
usb_phy_shutdown(musb-xceiv);
+ error = phy_power_off(musb-phy);
+ if (error)
+ dev_err(dev, phy shutdown failed: %i\n, error);
usleep_range(100, 200);
usb_phy_init(musb-xceiv);
+ error = phy_power_on(musb-phy);
+ if (error)
+ dev_err(dev, phy powerup failed: %i\n, error);
session_restart = 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: omap2+: omap_hwmod: Fix false lockdep warning
On Fri, Feb 06, 2015 at 06:05:32PM +0200, Peter Ujfalusi wrote: Certainly looks much simpler, but it adds quite a bit of data to the omap_hwmod struct, and we have a _lot_ of them for omap2plus configuration. ls -al vmlinux w/o any the lockdep warning fixes: 110109168 With my series applied: 110112031 (base + 2863) With setting individual lockdep class: 110114275 (base + 5107) I certainly like the lockdep_set_class() way since it is cleaner, but it adds almost double amount of bytes to the kernel. Yeah, I've never really bothered with data too much, its a debug feature. So lock_class_key is 8 bytes, and strictly speaking you could union them over other fields, all we really need is unique addresses, we don't actually use the storage. -- 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
