Re: [PATCH v5 2/9] mfd: omap-usb-host: Get clocks based on hardware revision
On 01/10/2014 04:26 PM, Lee Jones wrote:
On Fri, 10 Jan 2014, Arnd Bergmann wrote:
On Friday 10 January 2014, Lee Jones wrote:
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-EINVAL);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-EINVAL);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-EINVAL);
I don't think this is the correct error code.
-EINVAL means 'invalid parameter'.
You probably want -ENODEV or -ENOSYS ('function not implemented'
probably isn't ideal either tbh, but you get the idea). Perhaps you
can set them as NULL and check for IS_ERR_OR_NULL() instead?
I think ENODEV is ok here, I'd much prefer this over IS_ERR_OR_NULL().
Sounds good to me.
OK. Will fix.
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/9] mfd: omap-usb-host: Update DT clock binding information
On 01/10/2014 12:11 PM, Lee Jones wrote: On Thu, 09 Jan 2014, Roger Quadros wrote: The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. Use clock names as per function for reference clocks. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ drivers/mfd/omap-usb-host.c| 6 +++--- 2 files changed, 26 insertions(+), 3 deletions(-) Please don't mix up binding changes with code ones. Separate patch please. OK. cheers, -roger -- 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] spi: omap2-mcspi: Fix mcspi FIFO usage
The following commit add Fifo support for omap mcspi.
commit d33f473dcd8e69321f001ba330d648f475b504c9
Author: Illia Smyrnov illia.smyr...@ti.com
Date: Mon Jun 17 16:31:06 2013 +0300
spi: omap2-mcspi: Add FIFO buffer support
Currently, enabling of FIFO is done based on rx_buf or tx_buf checks
and only one of the RX or TX fifo is enabled. There can be transfers
in which both RX/TX fifo is desired. Hence, fixing code for the
same to allow setting both TX/RX fifo when needed.
Application:
While doing a loopback testing on beaglebone white(DMA
with FIFO enabled), where both RX and TX buf buffers are passed,
./spidev_test hangs.
The $subject patch fixes that hang and data can be loopbacked.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index ed4af47..86402a7 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -299,7 +299,9 @@ static void omap2_mcspi_set_fifo(const struct spi_device
*spi,
if (t-rx_buf != NULL) {
chconf |= OMAP2_MCSPI_CHCONF_FFER;
xferlevel |= (fifo_depth - 1) 8;
- } else {
+ }
+
+ if (t-tx_buf != NULL) {
chconf |= OMAP2_MCSPI_CHCONF_FFET;
xferlevel |= fifo_depth - 1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Deadlock in do_page_fault() on ARM (old kernel)
On Wed 15-01-14 20:13:04, Alan Ott wrote: [...] 2. __copy_to_user_memcpy() takes a read lock (down_read()) on This looks like a bug. copy_to_user_* shouldn't take mmap_sem at all Check the might_fault annotation used in generic code. Arm version of copy_to_user* doesn't seem to use the annotation and I do not see a good reason for that. 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=8878a539ff19a43cf3729e7562cd528f490246ae This one seems obviously related, but has no effect on my system: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=435a7ef52db7d86e67a009b36cac1457f8972391 [3] http://thread.gmane.org/gmane.linux.kernel/280900 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
And another one using that evil mail-followup-to header: Mail-Followup-To: Pali Rohár pali.ro...@gmail.com, Anton Vorontsov an...@enomsg.org, Michael Trimarchi mich...@amarulasolutions.com, David Woodhouse dw...@infradead.org, Tony Lindgren t...@atomide.com, Russell King li...@arm.linux.org.uk, linux-ker...@vger.kernel.org, Linux OMAP Mailing List linux-omap@vger.kernel.org, freemangor...@abv.bg, aaro.koski...@iki.fi, pa...@ucw.cz which results in all the above being moved into the To: header by unsuspecting recipients who reply to your message. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- 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: AM335x USB DMA seems broken on ISOC URBs
On 01/18/2014 04:12 PM, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. [...] Let me know if you find anything - I hope to find some time to do similar tests on AM33xx based hardware. I tried using an USB headset connected to a AM33xx based board, using kernel v3.13. The good news is that aplay gives me sound, so there's nothing generally wrong with isochronous streams on musb_dsps/cppi41. I can also do some simple 'arecord | aplay' loopback, and I can hear the microphone signal, but the stream breaks down after a couple of seconds, showing the following error: [ 433.671757] ALSA sound/core/pcm_lib.c:1945 capture write error (DMA or IRQ trouble?) Also, when tearing down the aplay stream, the cppi41 driver spits a number of the warnings below. Sebastian, do you have any pending patches that might be worth testing? Thanks, Daniel [ 340.255651] [ cut here ] [ 340.262828] WARNING: CPU: 0 PID: 112 at drivers/dma/cppi41.c:605 cppi41_dma_control+0x2a8/0x2d4() [ 340.272086] Modules linked in: [ 340.287140] CPU: 0 PID: 112 Comm: aplay Tainted: GW 3.13.0-00051-gff62d1c #1661 [ 340.295798] [c00137b8] (unwind_backtrace+0x0/0xf4) from [c001158c] (show_stack+0x10/0x14) [ 340.304712] [c001158c] (show_stack+0x10/0x14) from [c0037154] (warn_slowpath_common+0x6c/0x84) [ 340.314070] [c0037154] (warn_slowpath_common+0x6c/0x84) from [c0037208] (warn_slowpath_null+0x1c/0x24) [ 340.324153] [c0037208] (warn_slowpath_null+0x1c/0x24) from [c02b50d8] (cppi41_dma_control+0x2a8/0x2d4) [ 340.334255] [c02b50d8] (cppi41_dma_control+0x2a8/0x2d4) from [c0375f0c] (cppi41_dma_channel_abort+0xcc/0) [ 340.344976] [c0375f0c] (cppi41_dma_channel_abort+0xcc/0x140) from [c037187c] (musb_cleanup_urb.isra.16+0) [ 340.356147] [c037187c] (musb_cleanup_urb.isra.16+0x58/0x11c) from [c0371b80] (musb_urb_dequeue+0xe8/0x12) [ 340.366595] [c0371b80] (musb_urb_dequeue+0xe8/0x128) from [c035aa74] (unlink1+0x2c/0x110) [ 340.375497] [c035aa74] (unlink1+0x2c/0x110) from [c035b2e0] (usb_hcd_unlink_urb+0x50/0xc4) [ 340.384496] [c035b2e0] (usb_hcd_unlink_urb+0x50/0xc4) from [c03db53c] (deactivate_urbs+0xd8/0xf4) [ 340.394126] [c03db53c] (deactivate_urbs+0xd8/0xf4) from [c03dc614] (snd_usb_endpoint_stop+0x30/0x70) [ 340.404032] [c03dc614] (snd_usb_endpoint_stop+0x30/0x70) from [c03e3d40] (stop_endpoints+0x70/0x88) [ 340.413843] [c03e3d40] (stop_endpoints+0x70/0x88) from [c03e3ea0] (snd_usb_substream_playback_trigger+0x) [ 340.424836] [c03e3ea0] (snd_usb_substream_playback_trigger+0x9c/0xb8) from [c03cdb40] (snd_pcm_do_stop+0) [ 340.435917] [c03cdb40] (snd_pcm_do_stop+0x54/0x58) from [c03cd768] (snd_pcm_action_single+0x38/0x78) [ 340.445816] [c03cd768] (snd_pcm_action_single+0x38/0x78) from [c03cd970] (snd_pcm_drop+0x6c/0xc4) [ 340.455443] [c03cd970] (snd_pcm_drop+0x6c/0xc4) from [c03cf22c] (snd_pcm_common_ioctl1+0xc90/0x109c) [ 340.465344] [c03cf22c] (snd_pcm_common_ioctl1+0xc90/0x109c) from [c03cf7f0] (snd_pcm_playback_ioctl1+0x1) [ 340.476434] [c03cf7f0] (snd_pcm_playback_ioctl1+0x1b8/0x4b0) from [c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0) [ 340.486607] [c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0) from [c00e7cc4] (SyS_ioctl+0x70/0x80) [ 340.495331] [c00e7cc4] (SyS_ioctl+0x70/0x80) from [c000e340] (ret_fast_syscall+0x0/0x48) [ 340.504136] ---[ end trace 521a83c0d2567bbb ]--- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode
On Mon, Jan 20, 2014 at 10:21:29AM +, Russell King - ARM Linux wrote: And another one using that evil mail-followup-to header: Mail-Followup-To: Pali Rohár pali.ro...@gmail.com, Anton Vorontsov an...@enomsg.org, Michael Trimarchi mich...@amarulasolutions.com, David Woodhouse dw...@infradead.org, Tony Lindgren t...@atomide.com, Russell King li...@arm.linux.org.uk, linux-ker...@vger.kernel.org, Linux OMAP Mailing List linux-omap@vger.kernel.org, freemangor...@abv.bg, aaro.koski...@iki.fi, pa...@ucw.cz which results in all the above being moved into the To: header by unsuspecting recipients who reply to your message. Thanks for the hint. Should be fixed now. -- Sebastian signature.asc Description: Digital signature
Re: AM335x USB DMA seems broken on ISOC URBs
On Mon, Jan 20, 2014 at 12:15:40PM +0100, Daniel Mack wrote: On 01/18/2014 04:12 PM, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. [...] Let me know if you find anything - I hope to find some time to do similar tests on AM33xx based hardware. I tried using an USB headset connected to a AM33xx based board, using kernel v3.13. The good news is that aplay gives me sound, so there's nothing generally wrong with isochronous streams on musb_dsps/cppi41. Hm.. interesting. I wonder what's the difference between those URBs and the video URBs involved in stk1160 operation. Maybe the size of each buffer transfered? Can anybody bring some light on this? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next PATCH 1/1] drivers: net: cpsw: enable promiscuous mode support
Enable promiscuous mode support for CPSW.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 101 -
drivers/net/ethernet/ti/cpsw_ale.c | 16 ++
drivers/net/ethernet/ti/cpsw_ale.h | 2 +
3 files changed, 94 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index e8bb77d..21bbdcb 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -541,14 +541,89 @@ static inline int cpsw_get_slave_port(struct cpsw_priv
*priv, u32 slave_num)
return slave_num;
}
+static void cpsw_set_promiscious(struct net_device *ndev, bool enable)
+{
+ struct cpsw_priv *priv = netdev_priv(ndev);
+ struct cpsw_ale *ale = priv-ale;
+
+ if (priv-data.dual_emac) {
+ /* Enabling promiscuous mode for one interface will be
+* common for both the interface as the interface shares
+* the same hardware resource.
+*/
+ if (!enable ((priv-slaves[0].ndev-flags IFF_PROMISC) ||
+ (priv-slaves[1].ndev-flags IFF_PROMISC))) {
+ enable = true;
+ dev_err(ndev-dev, promiscuity not disabled as the
other interface is still in promiscuity mode\n);
+ }
+
+ if (enable) {
+ /* Enable Bypass */
+ cpsw_ale_control_set(ale, 0, ALE_BYPASS, 1);
+
+ dev_dbg(ndev-dev, promiscuity enabled\n);
+ } else {
+ /* Disable Bypass */
+ cpsw_ale_control_set(ale, 0, ALE_BYPASS, 0);
+ dev_dbg(ndev-dev, promiscuity disabled\n);
+ }
+ } else {
+ int i;
+
+ if (enable) {
+ unsigned long timeout = jiffies + HZ;
+
+ /* Disable Learn for all ports */
+ for (i = 0; i = priv-data.slaves; i++) {
+ cpsw_ale_control_set(ale, i,
+ALE_PORT_NOLEARN, 1);
+ cpsw_ale_control_set(ale, i,
+ALE_PORT_NO_SA_UPDATE, 1);
+ }
+
+ /* Clear All Untouched entries */
+ cpsw_ale_control_set(ale, 0, ALE_AGEOUT, 1);
+ do {
+ cpu_relax();
+ if (cpsw_ale_control_get(ale, 0, ALE_AGEOUT))
+ break;
+ } while (time_after(timeout, jiffies));
+ cpsw_ale_control_set(ale, 0, ALE_AGEOUT, 1);
+
+ /* Clear all mcast from ALE */
+ cpsw_ale_flush_multicast(ale, ALE_ALL_PORTS
+priv-host_port);
+
+ /* Flood All Unicast Packets to Host port */
+ cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 1);
+ dev_dbg(ndev-dev, promiscuity enabled\n);
+ } else {
+ /* Flood All Unicast Packets to Host port */
+ cpsw_ale_control_set(ale, 0, ALE_P0_UNI_FLOOD, 0);
+
+ /* Enable Learn for all ports */
+ for (i = 0; i = priv-data.slaves; i++) {
+ cpsw_ale_control_set(ale, i,
+ALE_PORT_NOLEARN, 0);
+ cpsw_ale_control_set(ale, i,
+ALE_PORT_NO_SA_UPDATE, 0);
+ }
+ dev_dbg(ndev-dev, promiscuity disabled\n);
+ }
+ }
+}
+
static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
{
struct cpsw_priv *priv = netdev_priv(ndev);
if (ndev-flags IFF_PROMISC) {
/* Enable promiscuous mode */
- dev_err(priv-dev, Ignoring Promiscuous mode\n);
+ cpsw_set_promiscious(ndev, true);
return;
+ } else {
+ /* Disable promiscuous mode */
+ cpsw_set_promiscious(ndev, false);
}
/* Clear all mcast from ALE */
@@ -1257,29 +1332,6 @@ fail:
return NETDEV_TX_BUSY;
}
-static void cpsw_ndo_change_rx_flags(struct net_device *ndev, int flags)
-{
- /*
-* The switch cannot operate in promiscuous mode without substantial
-* headache. For promiscuous mode to work, we would need to put the
-* ALE in bypass mode and route all traffic to the host port.
-* Subsequently, the host will need to operate as a bridge, learn,
-* and flood as needed. For now, we simply complain here and
-* do nothing
[PATCH v6 03/10] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index eaafd2e..d6fab3e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
goto err_mem;
}
- omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
--
1.8.3.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 v6 09/10] ARM: dts: omap5-uevm: Provide USB PHY clock
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = usb-nop-xceiv;
reset-gpios = gpio3 16 GPIO_ACTIVE_LOW; /* gpio3_80
HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = auxclk1;
- * clock-names = main_clk;
- */
+ clocks = auxclk1_ck;
+ clock-names = main_clk;
clock-frequency = 1920;
};
--
1.8.3.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 v6 04/10] mfd: omap-usb-host: Update DT clock binding information
The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..4721b2d 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,29 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1 +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + For OMAP3 + * usbhost_120m_fck - 120MHz Functional clock. + + For OMAP4+ + * refclk_60m_int - 60MHz internal reference clock for UTMI clock mux + * refclk_60m_ext_p1 - 60MHz external ref. clock for Port 1's UTMI clock mux. + * refclk_60m_ext_p2 - 60MHz external ref. clock for Port 2's UTMI clock mux + * utmi_p1_gfclk - Port 1 UTMI clock mux. + * utmi_p2_gfclk - Port 2 UTMI clock mux. + * usb_host_hs_utmi_p1_clk - Port 1 UTMI clock gate. + * usb_host_hs_utmi_p2_clk - Port 2 UTMI clock gate. + * usb_host_hs_utmi_p3_clk - Port 3 UTMI clock gate. + * usb_host_hs_hsic480m_p1_clk - Port 1 480MHz HSIC clock gate. + * usb_host_hs_hsic480m_p2_clk - Port 2 480MHz HSIC clock gate. + * usb_host_hs_hsic480m_p3_clk - Port 3 480MHz HSIC clock gate. + * usb_host_hs_hsic60m_p1_clk - Port 1 60MHz HSIC clock gate. + * usb_host_hs_hsic60m_p2_clk - Port 2 60MHz HSIC clock gate. + * usb_host_hs_hsic60m_p3_clk - Port 3 60MHz HSIC clock gate. + Required properties if child node exists: - #address-cells: Must be 1 -- 1.8.3.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 v6 10/10] ARM: OMAP2+: Remove legacy_init_ehci_clk()
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 39f020c..6a4e2d1 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -26,20 +26,6 @@ struct pdata_init {
void (*fn)(void);
};
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias(main_clk, NULL, clkname, NULL);
- if (ret)
- pr_err(%s:Failed to add main_clk alias to %s :%d\n,
- __func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -105,7 +91,6 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk(auxclk3_ck);
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
@@ -113,7 +98,6 @@ static void __init omap4_panda_legacy_init(void)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
- legacy_init_ehci_clk(auxclk1_ck);
}
#endif
--
1.8.3.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 v6 08/10] ARM: dts: omap4-panda: Provide USB PHY clock
The USB PHY gets its clock from AUXCLK3. Provide this information. Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..50b72966 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -83,12 +83,8 @@ compatible = usb-nop-xceiv; reset-gpios = gpio2 30 GPIO_ACTIVE_LOW; /* gpio_62 */ vcc-supply = hsusb1_power; - /** -* FIXME: -* put the right clock phandle here when available -* clocks = auxclk3; -* clock-names = main_clk; -*/ + clocks = auxclk3_ck; + clock-names = main_clk; clock-frequency = 1920; }; -- 1.8.3.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 v6 07/10] ARM: dts: omap5: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 2f12a47..0f82ecf 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -765,6 +765,12 @@
#address-cells = 1;
#size-cells = 1;
ranges;
+ clocks = l3init_60m_fclk,
+xclk60mhsp1_ck,
+xclk60mhsp2_ck;
+ clock-names = refclk_60m_int,
+ refclk_60m_ext_p1,
+ refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
compatible = ti,ohci-omap3, usb-ohci;
--
1.8.3.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 v6 05/10] mfd: omap-usb-tll: Update DT clock binding information
The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe697..c58d704 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain usb_tll_hs
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ * usb_tll_hs_usb_ch0_clk - USB TLL channel 0 clock
+ * usb_tll_hs_usb_ch1_clk - USB TLL channel 1 clock
+ * usb_tll_hs_usb_ch2_clk - USB TLL channel 2 clock
+
Example:
usbhstll: usbhstll@4a062000 {
--
1.8.3.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 v6 02/10] mfd: omap-usb-host: Get clocks based on hardware revision
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 92 +++--
1 file changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1c9bca2..eaafd2e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap-ehci_logic_fck = omap-init_60m_fclk = ERR_PTR(-ENODEV);
+ omap-utmi_p1_gfclk = omap-utmi_p2_gfclk = ERR_PTR(-ENODEV);
+ omap-xclk60mhsp1_ck = omap-xclk60mhsp2_ck = ERR_PTR(-ENODEV);
+
for (i = 0; i omap-nports; i++) {
- if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i))
- need_logic_fck |= true;
+ omap-utmi_clk[i] = ERR_PTR(-ENODEV);
+ omap-hsic480m_clk[i] = ERR_PTR(-ENODEV);
+ omap-hsic60m_clk[i] = ERR_PTR(-ENODEV);
}
- omap-ehci_logic_fck = ERR_PTR(-EINVAL);
- if (need_logic_fck) {
- omap-ehci_logic_fck = devm_clk_get(dev, ehci_logic_fck);
- if (IS_ERR(omap-ehci_logic_fck)) {
- ret = PTR_ERR(omap-ehci_logic_fck);
- dev_dbg(dev, ehci_logic_fck failed:%d\n, ret);
+ /* for OMAP3 i.e. USBHS REV1 */
+ if (omap-usbhs_rev == OMAP_USBHS_REV1) {
+ need_logic_fck = false;
+ for (i = 0; i omap-nports; i++) {
+ if (is_ehci_phy_mode(pdata-port_mode[i]) ||
+ is_ehci_tll_mode(pdata-port_mode[i]) ||
+ is_ehci_hsic_mode(pdata-port_mode[i]))
+
+ need_logic_fck |= true;
+ }
+
+ if (need_logic_fck) {
+ omap-ehci_logic_fck = clk_get(dev, usbhost_120m_fck);
+ if (IS_ERR(omap-ehci_logic_fck)) {
+ ret = PTR_ERR(omap-ehci_logic_fck);
+ dev_err(dev, usbhost_120m_fck failed:%d\n,
+ ret);
+ goto err_mem;
+ }
}
+ goto initialize;
}
+ /* for OMAP4+ i.e. USBHS REV2+ */
omap-utmi_p1_gfclk = devm_clk_get(dev, utmi_p1_gfclk);
if (IS_ERR(omap-utmi_p1_gfclk)) {
ret = PTR_ERR(omap-utmi_p1_gfclk);
@@ -728,54 +747,71 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* them
*/
omap-utmi_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-utmi_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-utmi_clk[i]));
+ if (IS_ERR(omap-utmi_clk[i])) {
+ ret = PTR_ERR(omap-utmi_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic480m_p%d_clk, i + 1);
omap-hsic480m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-hsic480m_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-hsic480m_clk[i]));
+ if (IS_ERR(omap-hsic480m_clk[i])) {
+ ret = PTR_ERR(omap-hsic480m_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic60m_p%d_clk, i + 1);
omap-hsic60m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap-hsic60m_clk[i]))
- dev_dbg(dev, Failed to get clock : %s : %ld\n,
- clkname, PTR_ERR(omap-hsic60m_clk[i]));
+ if (IS_ERR(omap-hsic60m_clk[i])) {
+ ret = PTR_ERR(omap-hsic60m_clk[i]);
+ dev_err(dev, Failed to get clock : %s : %d\n,
+ clkname, ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata-port_mode[0]))
[PATCH v6 01/10] mfd: omap-usb-host: Use resource managed clk_get()
Use devm_clk_get() instead of clk_get().
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/omap-usb-host.c | 81 +
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 142650f..1c9bca2 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -674,46 +674,46 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap-ehci_logic_fck = ERR_PTR(-EINVAL);
if (need_logic_fck) {
- omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
+ omap-ehci_logic_fck = devm_clk_get(dev, ehci_logic_fck);
if (IS_ERR(omap-ehci_logic_fck)) {
ret = PTR_ERR(omap-ehci_logic_fck);
dev_dbg(dev, ehci_logic_fck failed:%d\n, ret);
}
}
- omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
+ omap-utmi_p1_gfclk = devm_clk_get(dev, utmi_p1_gfclk);
if (IS_ERR(omap-utmi_p1_gfclk)) {
ret = PTR_ERR(omap-utmi_p1_gfclk);
dev_err(dev, utmi_p1_gfclk failed error:%d\n, ret);
- goto err_p1_gfclk;
+ goto err_mem;
}
- omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
+ omap-utmi_p2_gfclk = devm_clk_get(dev, utmi_p2_gfclk);
if (IS_ERR(omap-utmi_p2_gfclk)) {
ret = PTR_ERR(omap-utmi_p2_gfclk);
dev_err(dev, utmi_p2_gfclk failed error:%d\n, ret);
- goto err_p2_gfclk;
+ goto err_mem;
}
- omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
- goto err_xclk60mhsp1;
+ goto err_mem;
}
- omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
- goto err_xclk60mhsp2;
+ goto err_mem;
}
- omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
dev_err(dev, init_60m_fclk failed error:%d\n, ret);
- goto err_init60m;
+ goto err_mem;
}
for (i = 0; i omap-nports; i++) {
@@ -727,21 +727,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* platforms have all clocks and we can function without
* them
*/
- omap-utmi_clk[i] = clk_get(dev, clkname);
+ omap-utmi_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-utmi_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-utmi_clk[i]));
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic480m_p%d_clk, i + 1);
- omap-hsic480m_clk[i] = clk_get(dev, clkname);
+ omap-hsic480m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-hsic480m_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-hsic480m_clk[i]));
snprintf(clkname, sizeof(clkname),
usb_host_hs_hsic60m_p%d_clk, i + 1);
- omap-hsic60m_clk[i] = clk_get(dev, clkname);
+ omap-hsic60m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap-hsic60m_clk[i]))
dev_dbg(dev, Failed to get clock : %s : %ld\n,
clkname, PTR_ERR(omap-hsic60m_clk[i]));
@@ -784,7 +784,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, Failed to create DT children: %d\n, ret);
- goto err_alloc;
+ goto err_mem;
}
} else {
@@ -792,40 +792,12 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, omap_usbhs_alloc_children failed: %d\n,
ret);
- goto err_alloc;
+ goto err_mem;
}
}
return 0;
-err_alloc:
- for (i = 0; i omap-nports; i++) {
-
[PATCH v6 06/10] ARM: dts: omap4: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..39a05ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -697,6 +697,12 @@
#address-cells = 1;
#size-cells = 1;
ranges;
+ clocks = init_60m_fclk,
+xclk60mhsp1_ck,
+xclk60mhsp2_ck;
+ clock-names = refclk_60m_int,
+ refclk_60m_ext_p1,
+ refclk_60m_ext_p2;
usbhsohci: ohci@4a064800 {
compatible = ti,ohci-omap3, usb-ohci;
--
1.8.3.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 v6 00/10] USB Host support for OMAP5 uEVM (for 3.14)
Hi Benoit Tony, This patchset brings up USB Host ports and Ethernet port on the OMAP5 uEVM board. It depends on the TI Clock DT conversion patches [1] and is based on 3.13 [1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/293147 Tested on: - OMAP5 uEVM - Pandaboard ES Rev. B1 - Beagleboard-XM Rev C2 - Beagleboard Rev C4. cheers, -roger Changelog: v6: - Initialized clocks to -ENODEV and split patch 3. v5: - Expose all clocks in the DT binding document for mfd:omap-usb-host and mfd:omap-usb-tll v4: - Updated DT binding document for clock binding v3: - Rebased on top of 3.13-rc7 cheers, -roger Roger Quadros (10): mfd: omap-usb-host: Use resource managed clk_get() mfd: omap-usb-host: Get clocks based on hardware revision mfd: omap-usb-host: Use clock names as per function for reference clocks mfd: omap-usb-host: Update DT clock binding information mfd: omap-usb-tll: Update DT clock binding information ARM: dts: omap4: Update omap-usb-host node ARM: dts: omap5: Update omap-usb-host node ARM: dts: omap4-panda: Provide USB PHY clock ARM: dts: omap5-uevm: Provide USB PHY clock ARM: OMAP2+: Remove legacy_init_ehci_clk() .../devicetree/bindings/mfd/omap-usb-host.txt | 23 +++ .../devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++ arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +- arch/arm/boot/dts/omap4.dtsi | 6 + arch/arm/boot/dts/omap5-uevm.dts | 8 +- arch/arm/boot/dts/omap5.dtsi | 6 + arch/arm/mach-omap2/pdata-quirks.c | 16 -- drivers/mfd/omap-usb-host.c| 171 ++--- 8 files changed, 128 insertions(+), 120 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] N900 DTS additions for 3.14
On Sat, Jan 11, 2014 at 10:16:57PM +0100, Sebastian Reichel wrote: Here are a couple of additions for the Nokia N900 Device Tree Source file. All related drivers changes are queued for 3.14 (except for the tpa6130a2, which got merged into 3.13). I may have some more additions if the driver changes for the accelerometer, the touchscreen or the wireless lan chip will be queued up. ping? Also it seems, that for_3.14/dts branch on bcousson/linux-omap-dt.git merged some branches, which Tony no longer intends to be merged for 3.14. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: Add basic devices for AM3517-craneboard
Benoit, On 12/18/2013 11:16 AM, Benoit Cousson wrote: On 18/12/2013 18:02, Nishanth Menon wrote: On 12/18/2013 10:57 AM, Benoit Cousson wrote: On 17/12/2013 20:45, Nishanth Menon wrote: On 12/09/2013 03:55 PM, Nishanth Menon wrote: Craneboard is a hardware development platform based on the Sitara AM3517 ARM Cortex - A8 microprocessor device - see [1] for more details. Add basic devices for craneboard as replacement for the board file scheduled for removal as part of device tree conversion [1] http://craneboard.org Signed-off-by: Nishanth Menon n...@ti.com --- gentle ping.. had'nt seen a response on this patch. Could we queue this up for v3.14-rc1? Yep, it looks good to me. Thanks benoit. But if you don't mind I'll start pushing my branch after Xmas :-). As long as Tony is ok with it, I have no issues either - will be great to have dt only boot in .14-rc1 though. Good point, it is already -rc4. OK, I'll just queued it and pushed it to for_3.14/dts. I dont see this in next-20140120 yet - wondering if Tony or you have plans for one of .14 rcs OR if this is queued for .15. -- 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: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 07:20 PM, Nishanth Menon wrote: [...] I am running a defconfig set check on next-20140117 and will do one with next-20140118 once that is ready for comparison results baseline next-20140120 modified as follows: multi_v7_defconfig - added CONFIG_SOC_DRA7XX omap2plus_defconfig - added CONFIG_SOC_AM43XX few patches for legacy boot platforms added in. next-20140120-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2vfJ5w6Na 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21IdtacuB 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2zrGqzI8r 4: am37x-evm: Boot PASS: http://slexy.org/raw/s21RLq4EzM 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21msOh70k 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2MyM1kbTJ 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2KmkjEQU5 8: crane: No Image built - Missing platform support?: * Pending merge from Benoit's tree 9: dra7: Boot PASS: http://slexy.org/raw/s20GK8ZSrL 10:ldp: Boot FAIL: http://slexy.org/raw/s20I1vJEY6 * Known issue on my setup :( - debug pending. 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s2SVGtHlwx 12:sdp2430: Boot PASS: http://slexy.org/raw/s214WyGCco 13:sdp3430: Boot PASS: http://slexy.org/raw/s21fPHXoOB 14:sdp4430: Boot PASS: http://slexy.org/raw/s20v0UJubl 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s2jPgymund TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 next-20140120-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2DcNIdR1p 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2NWkEQIct 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21rOVU9L3 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2xRLmJ9EW 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21487l9Tw 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s2198moPea 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s20wdS9zgf 8: crane: No Image built - Missing platform support?: * pending merge from Benoit's tree 9: dra7: Boot PASS: http://slexy.org/raw/s21Vr0foZS 10:ldp: Boot PASS: http://slexy.org/raw/s21PKycvVx 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20M5bdzFq * kevin already reported this for CPU_IDLE enable 12:sdp2430: v6 platform - wont boot 13:sdp3430: Boot PASS: http://slexy.org/raw/s2pmLQItJb 14:sdp4430: Boot PASS: http://slexy.org/raw/s21FYwSVZz 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21O7xuAJp TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3 next-20140120-multi_v7_defconfig + CONFIG_ARM_LPAE=y 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s21YHQrdtf 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s20buoWhQw 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s2VfH3LYFf 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20Q4s7tjA 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s2tMG0ABLi 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s20INrphLO 7: BeagleBone-Black: Boot FAIL: http://slexy.org/raw/s2ZKx9lyGc 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s21EV3vV4E 10:ldp: Boot FAIL: http://slexy.org/raw/s21aQ1vXWH 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20JMBxQUc 12:sdp2430: v6 platform - wont boot 13:sdp3430: Boot FAIL: http://slexy.org/raw/s20Itj0uX4 14:sdp4430: Boot FAIL: http://slexy.org/raw/s2BEPG9pjN 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s20bOKUZev TOTAL = 15 boards, Booted Boards = 2, No Boot boards = 13 in comparison with previous next tag: multi_v7_defconfig - added CONFIG_SOC_DRA7XX omap2plus_defconfig - added CONFIG_SOC_AM43XX few patches for legacy boot platforms added in. next-20140117-omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2x6c41m1Q 2: am335x-sk: Boot PASS: http://slexy.org/raw/s24IkMtLwV 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20ahoA1JR 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2hzZbe5fq 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s20875oeoW 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s20luzJWbj 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2Z1YQqX1A 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s2137kLALM 10:ldp: Boot FAIL: http://slexy.org/raw/s21S66NNnp 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s20XyDcifE 12:sdp2430: Boot PASS: http://slexy.org/raw/s234d7bWzB 13:sdp3430: Boot PASS: http://slexy.org/raw/s250xvaBxy 14:sdp4430: Boot PASS: http://slexy.org/raw/s2g3As3XlA 15: OMAP5432uEVM: Boot FAIL: http://slexy.org/raw/s21hOhWY4E TOTAL = 15 boards, Booted Boards = 10, No Boot boards = 5 next-20140117-multi_v7_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2M6DZp8D2 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21WdeG7QL 3: am3517-evm: Boot PASS: http://slexy.org/raw/s2PanhpCqK 4: am37x-evm: Boot PASS: http://slexy.org/raw
Re: [PATCHv13 27/40] ARM: dts: omap3 clock data
Hi,
I just found some time to update my SSI driver adding DT clock
support. It works, but I wonder if the alias of the ssi clocks
can be changed to something like the following:
/* omap3430es1-clocks.dtsi */
ssi_ick: ssi_ick_3430es1 {};
ssi_ssr_fck: ssi_ssr_fck_3430es1 {};
ssi_sst_fck: ssi_sst_fck_3430es1 {};
/* omap36xx-omap3430es2plus-clocks.dtsi */
ssi_ick: ssi_ick_3430es2 {};
ssi_ssr_fck: ssi_ssr_fck_3430es2 {};
ssi_sst_fck: ssi_sst_fck_3430es2 {};
With this change I can reference the ssi clocks in omap3.dtsi
instead of creating files for omap3430es1 and omap3430es2+.
-- Sebastian
signature.asc
Description: Digital signature
Re: Deadlock in do_page_fault() on ARM (old kernel)
On Mon 20-01-14 11:15:09, Michal Hocko wrote: On Wed 15-01-14 20:13:04, Alan Ott wrote: [...] 2. __copy_to_user_memcpy() takes a read lock (down_read()) on This looks like a bug. copy_to_user_* shouldn't take mmap_sem at all Check the might_fault annotation used in generic code. Arm version of copy_to_user* doesn't seem to use the annotation and I do not see a good reason for that. OK, so I have looked at the implementation of __copy_to_user_memcpy and it drops the semaphore before it does __put_user to fault memory in. It then reacquires the lock to make sure that the pte doesn't vanish during memcpy. It holds pte lock to ensure that. The mmap_sem reacquire happens with pte lock held though and this smells like a deadlock situation because the page fault takes mmap_sem first and only then takes ptl. I am not sure this is exactly what happens in your case though because you seem to have tasks blocked on the mmap_sem already. 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=8878a539ff19a43cf3729e7562cd528f490246ae This one seems obviously related, but has no effect on my system: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=435a7ef52db7d86e67a009b36cac1457f8972391 [3] http://thread.gmane.org/gmane.linux.kernel/280900 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Michal Hocko SUSE Labs -- 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: OMAP4+: move errata initialization to omap4_pm_init_early
Move all OMAP4 PM errata initializations to centralized location in
omap4_pm_init_early. This allows for users to utilize the erratas
in various submodules as needed.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Reported by Tony here: https://patchwork.kernel.org/patch/3084521/
Reproduced with .config: http://slexy.org/view/s2EEdvTGXV on next-20140120 tag
(based on omap2plus_defconfig)
Applies on v3.13 tag and on next-20140120
Tested to boot on next-20140120 along with
https://patchwork.kernel.org/patch/3084521/
on PandaBoard-ES with multi_v7_defconfig: http://slexy.org/view/s27n0BWrPf
arch/arm/mach-omap2/common.h |6 ++
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap-smp.c |6 +-
arch/arm/mach-omap2/pm44xx.c | 15 +++
4 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 3adaa1d..a6aae30 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -62,11 +62,17 @@ static inline int omap3_pm_init(void)
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
int omap4_pm_init(void);
+int omap4_pm_init_early(void);
#else
static inline int omap4_pm_init(void)
{
return 0;
}
+
+static inline int omap4_pm_init_early(void)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 47381fd..d408b15 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -641,6 +641,7 @@ void __init omap4430_init_early(void)
omap_cm_base_init();
omap4xxx_check_revision();
omap4xxx_check_features();
+ omap4_pm_init_early();
omap44xx_prm_init();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 75e95d4..17550aa 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -39,8 +39,6 @@
#define OMAP5_CORE_COUNT 0x2
-u16 pm44xx_errata;
-
/* SCU base address */
static void __iomem *scu_base;
@@ -217,10 +215,8 @@ static void __init omap4_smp_prepare_cpus(unsigned int
max_cpus)
if (scu_base)
scu_enable(scu_base);
- if (cpu_is_omap446x()) {
+ if (cpu_is_omap446x())
startup_addr = omap4460_secondary_startup;
- pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
- }
/*
* Write the address of secondary startup routine into the
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 82f06989..eefb30c 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -24,6 +24,8 @@
#include powerdomain.h
#include pm.h
+u16 pm44xx_errata;
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -199,6 +201,19 @@ static inline int omap4_init_static_deps(void)
}
/**
+ * omap4_pm_init_early - Does early initialization necessary for OMAP4+ devices
+ *
+ * Initializes basic stuff for power management functionality.
+ */
+int __init omap4_pm_init_early(void)
+{
+ if (cpu_is_omap446x())
+ pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+
+ return 0;
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4+ devices
*
* Initializes all powerdomain and clockdomain target states
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3-gta04: Add EOC irq gpio line handling.
Ping? Benoit can you please merge this trivial update. Thanks.
On Sat, Dec 21, 2013 at 4:12 PM, Marek Belisko ma...@goldelico.com wrote:
BMP085 EOC (End Of Conversion) irq line is connected to
gpio113 on gta04. Set irq properties to have driver using irq
instead polling for EOC.
Signed-off-by: Marek Belisko ma...@goldelico.com
---
arch/arm/boot/dts/omap3-gta04.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index b9b55c9..7a8e37d 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -92,6 +92,8 @@
bmp085@77 {
compatible = bosch,bmp085;
reg = 0x77;
+ interrupt-parent = gpio4;
+ interrupts = 17 IRQ_TYPE_EDGE_RISING;
};
/* leds */
--
1.8.4.2
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x USB DMA seems broken on ISOC URBs
Hi Daniel, On Sat, Jan 18, 2014 at 04:12:24PM +0100, Daniel Mack wrote: On 01/17/2014 05:27 PM, Ezequiel Garcia wrote: On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: [..] Did you try this with a different type of peripheral hardware, a USB audio device for example? [..] Finally I found some time to setup the board and do some new tests using an UVC webcam (which might behave better given it should transfer smaller buffers). The result is not encouraging! Device is detected regularly, but then I get some ugly messages on the first command: # yavta /dev/video0 -l [ 21.279722] BUG: spinlock cpu recursion on CPU#0, kworker/0:2/46 [ 21.286041] lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0 [ 21.293800] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69 [ 21.302571] Workqueue: events musb_host_finish_resume [ 21.307899] [c000faa1] (unwind_backtrace) from [c000e8db] (show_stack+0xb/0xc) [ 21.315844] [c000e8db] (show_stack) from [c003f981] (do_raw_spin_lock+0xc5/0xe8) [ 21.323969] [c003f981] (do_raw_spin_lock) from [c030c949] (_raw_spin_lock_irqsave+0xd/0x10) [ 21.333094] [c030c949] (_raw_spin_lock_irqsave) from [c021927b] (musb_host_finish_resume+0xf/0x60) [ 21.342860] [c021927b] (musb_host_finish_resume) from [c0031709] (process_one_work+0xad/0x224) [ 21.352258] [c0031709] (process_one_work) from [c0031b19] (worker_thread+0xc9/0x270) [ 21.360750] [c0031b19] (worker_thread) from [c00355c7] (kthread+0x7b/0x94) [ 21.368325] [c00355c7] (kthread) from [c000cb7d] (ret_from_fork+0x11/0x34) [ 27.352780] BUG: spinlock lockup suspected on CPU#0, kworker/0:2/46 [ 27.359350] lock: 0xdf01e010, .magic: dead4ead, .owner: yavta/78, .owner_cpu: 0 [ 27.367104] CPU: 0 PID: 46 Comm: kworker/0:2 Not tainted 3.13.0-rc8-next-20140120-dirty #69 [ 27.375860] Workqueue: events musb_host_finish_resume [ 27.381162] [c000faa1] (unwind_backtrace) from [c000e8db] (show_stack+0xb/0xc) [ 27.389103] [c000e8db] (show_stack) from [c003f971] (do_raw_spin_lock+0xb5/0xe8) [ 27.397224] [c003f971] (do_raw_spin_lock) from [c030c949] (_raw_spin_lock_irqsave+0xd/0x10) [ 27.406348] [c030c949] (_raw_spin_lock_irqsave) from [c021927b] (musb_host_finish_resume+0xf/0x60) [ 27.416109] [c021927b] (musb_host_finish_resume) from [c0031709] (process_one_work+0xad/0x224) [ 27.425506] [c0031709] (process_one_work) from [c0031b19] (worker_thread+0xc9/0x270) [ 27.433991] [c0031b19] (worker_thread) from [c00355c7] (kthread+0x7b/0x94) [ 27.441566] [c00355c7] (kthread) from [c000cb7d] (ret_from_fork+0x11/0x34) Any ideas from the maintainers? PS: As expected TI's PSP v3.2 driver works just fine :P -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers. Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation. Signed-off-by: Nishanth Menon n...@ti.com --- This explains the logs I see: OMAP3430 LDP (ES2.2): uImage only boot: http://slexy.org/raw/s2YrbMAi7c uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0 With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |2 ++ drivers/mmc/host/omap_hsmmc.c |3 +++ 2 files changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -26,6 +26,8 @@ specifier is required. dma-names: List of DMA request names. These strings correspond 1:1 with the DMA specifiers listed in dmas. The string naming is to be rx and tx for RX and TX DMA requests, respectively. +ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken +multiblock reads Examples: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 014bfe5..f2d5940 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev) if (of_find_property(np, ti,dual-volt, NULL)) pdata-controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT; + if (of_find_property(np, ti,erratum-2.1.1.128, NULL)) + pdata-controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ; + /* This driver only supports 1 slot */ pdata-nr_slots = 1; pdata-slots[0].switch_pin = cd_gpio; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3-ldp: fix mmc configuration
MMC1 is the only MMC interface available on the platform. Further,
since the platform is based on older revision of SoC which is not
capable of doing multi-block writes, mark it so and add pinmux
to ensure that all relevant pins are configured for non-MMC boot
mode.
Signed-off-by: Nishanth Menon n...@ti.com
---
ti,erratum-2.1.1.128 introduced in https://patchwork.kernel.org/patch/3514851/
hence depends on the same.
arch/arm/boot/dts/omap3-ldp.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index ddce0d8..bc0cc66 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -176,6 +176,17 @@
mmc1 {
vmmc-supply = vmmc1;
bus-width = 4;
+ ti,erratum-2.1.1.128;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+};
+
+mmc2 {
+ status=disabled;
+};
+
+mmc3 {
+ status=disabled;
};
omap3_pmx_core {
@@ -209,6 +220,17 @@
0x174 (PIN_OUTPUT | MUX_MODE0) /*
hsusb0_stp.hsusb0_stp */
;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ OMAP3_CORE1_IOPAD(0x2144, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_clk.mmc1_clk */
+ OMAP3_CORE1_IOPAD(0x2146, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_cmd.mmc1_cmd */
+ OMAP3_CORE1_IOPAD(0x2148, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat0.mmc1_dat0 */
+ OMAP3_CORE1_IOPAD(0x214A, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat1.mmc1_dat1 */
+ OMAP3_CORE1_IOPAD(0x214C, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat2.mmc1_dat2 */
+ OMAP3_CORE1_IOPAD(0x214e, PIN_INPUT_PULLUP | MUX_MODE0)
/* mmc1_dat3.mmc1_dat3 */
+ ;
+ };
};
usb_otg_hs {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote: When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers. Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation. sure there's no way of reading the revision register to figure this one out without having to add a new DT attribute ? -- balbi signature.asc Description: Digital signature
Re: Deadlock in do_page_fault() on ARM (old kernel)
On 01/17/2014 08:20 PM, Russell King - ARM Linux wrote: On Fri, Jan 17, 2014 at 07:57:16PM -0500, Alan Ott wrote: On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote: My suspicion therefore is that some other thread must have died while holding the mmap_sem, so there's probably a kernel oops earlier... that's my best guess at the moment without seeing the full backtrace. There's no oops that I'm able to see. Each of the tasks which lockdep reports as holding mmap_sem are blocking for it. If some other task had taken it and then crashed, I assume lockdep would list the crashed task as also holding the resource in the printout. My point is this: - the five (or six) threads which are trying to take the mmap_sem in read-mode in the fault handler are all blocked on it - they haven't taken the lock, which will only happen because there's a pending writer. - of these in your original post, there are two which faulted from __copy_to_user_std(). __copy_to_user_std() doesn't take the mmap_sem - this is the non-uaccess-with-memcpy path. - the pending writers are the two threads in sys_mmap_pgoff(), both of which are blocked waiting to gain the write lock. - there are no *other* threads holding the mmap_sem lock. Yes, all true. I don't remember why I started looking at the memcpy() case. So... there's a question here how we got into this state - and frankly I don't know. What I do see from your latest dump is that there's two unknown modules there - something called rcu2m and another called buttoms, and there are two threads inside ioctls there. Both have faulted from the function at 0xc0d2a394 (which won't appear in the backtrace, but is most likely __copy_to_user_std.) Yes, there are a handful of out-of-tree modules. So, in the absence of you saying anything about there being any preceding oopses, my conclusion now is that one of those modules is taking the mmap_sem itself, and is the culpret inducing this deadlock. Yes, I came to that as well. I had checked for the presence of mmap_sem in the sources of the out-of-tree modules and didn't see it. However, upon closer inspection, my grep-fu failed me as there were some backward symlinks I didn't account for. TI's cmemk module _is_ taking out mmap_sem. I wish I had seen this days ago. That's my new investigation path. Note that your dump ([2]) in your reply was just the hung task detector printing out the stacktrace for a few tasks, not the full all-threads stack dump which I was expecting. Yes, in a misguided attempt to keep the SNR high, I didn't include the full dump, but only what I thought was the interesting part. I did another capture and the full dump is at [1] . So I'm pulling out these conclusions from the very little information you're supplying. I appreciate it. Thank you for taking the time to reply. Alan. [1] http://www.signal11.us/~alan/stack_dump_all_tasks_with_frame_pointers.txt -- 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 27/40] ARM: dts: omap3 clock data
On 01/20/2014 08:00 PM, Sebastian Reichel wrote:
Hi,
I just found some time to update my SSI driver adding DT clock
support. It works, but I wonder if the alias of the ssi clocks
can be changed to something like the following:
/* omap3430es1-clocks.dtsi */
ssi_ick: ssi_ick_3430es1 {};
ssi_ssr_fck: ssi_ssr_fck_3430es1 {};
ssi_sst_fck: ssi_sst_fck_3430es1 {};
/* omap36xx-omap3430es2plus-clocks.dtsi */
ssi_ick: ssi_ick_3430es2 {};
ssi_ssr_fck: ssi_ssr_fck_3430es2 {};
ssi_sst_fck: ssi_sst_fck_3430es2 {};
With this change I can reference the ssi clocks in omap3.dtsi
instead of creating files for omap3430es1 and omap3430es2+.
Yea looks like a valid change to me. Feel free to send a patch for it.
-Tero
--
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
