Re: [PATCHv5 2/2] arm: Get rid of meminfo
On 6/24/2014 1:49 AM, Uwe Kleine-König wrote: Hi Laura, On Mon, Jun 23, 2014 at 01:47:55PM -0700, Laura Abbott wrote: Thanks for the report. Thanks for your reply to address it :-) Are you already aware of the mail with Message-Id: caga+x85h510fngtxjhgyfqybra2fggg2nycgj8rmjj6te7g...@mail.gmail.com ? Seems to be another fall-out but I think you were not on Cc. On 6/23/2014 2:17 AM, Uwe Kleine-König wrote: This patch is in 3.16-rc1 as 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76 now. Unfortunately it makes my efm32 machine unbootable. With earlyprintk enabled I get the following output: [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.15.0-rc1-00028-g1c2f87c22566-dirty (ukleinek@perseus) (gcc version 4.7.2 (OSELAS.Toolchain-2012.12.1) ) #280 PREEMPT Mon Jun 23 11:05:34 CEST 2014 [0.00] CPU: ARMv7-M [412fc231] revision 1 (ARMv7M), cr= [0.00] CPU: unknown data cache, unknown instruction cache [0.00] Machine model: Energy Micro Giant Gecko Development Kit [0.00] debug: ignoring loglevel setting. [0.00] bootconsole [earlycon0] enabled [0.00] On node 0 totalpages: 1024 [0.00] free_area_init_node: node 0, pgdat 880208f4, node_mem_map [0.00] Normal zone: 3840 pages exceeds freesize 1024 This looks off. The number of pages for the memmap exceeds the available free size. Working backwards, I think the wrong bounds are being calculated in find_limits in arch/arm/mm/init.c . max_low is now calculated via the current limit but nommu never sets a limit unlike the mmu case. Can you try the following patch and see if it fixes the issue? If this doesn't work, can you share working bootup logs so I can do a bit more compare and contrast? Thanks, Laura ---8 From 9b19241d577caf91928e26e55413047d1be90feb Mon Sep 17 00:00:00 2001 From: Laura Abbott lau...@codeaurora.org Date: Mon, 23 Jun 2014 13:26:56 -0700 Subject: [PATCH] arm: Set memblock limit for nommu Commit 1c2f87c (ARM: 8025/1: Get rid of meminfo) changed find_limits to use memblock_get_current_limit for calculating the max_low pfn. nommu targets never actually set a limit on memblock though which means memblock_get_current_limit will just return the default value. Set the memblock_limit to be the end of DDR to make sure s/DDR/RAM/ ? bounds are calculated correctly. This patch makes my machine boot. Full boot log appended below. (Side note: I place my dtb in the SRAM at 0x1000 but don't add this to the available memory because it's only 128 KiB in size and so too small to be worth to track. Not sure this is allowed?!) Thanks Uwe I put this in the patch tracker as 8086/1 Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: qup: Add DMA capabilities
On Thu, Jun 26, 2014 at 04:06:21PM -0500, Andy Gross wrote:
+ if (xfer-rx_buf) {
+ rx_dma = dma_map_single(controller-dev, xfer-rx_buf,
+ xfer-len, DMA_FROM_DEVICE);
It would be better to use the core DMA mapping code rather than open
coding. This code won't work for vmalloc()ed addresses, or physically
non-contiguous addresses unless there's an IOMMU fixing things up.
signature.asc
Description: Digital signature
Re: [PATCH] spi: qup: Add DMA capabilities
On Fri, Jun 27, 2014 at 11:50:57AM +0100, Mark Brown wrote:
On Thu, Jun 26, 2014 at 04:06:21PM -0500, Andy Gross wrote:
+ if (xfer-rx_buf) {
+ rx_dma = dma_map_single(controller-dev, xfer-rx_buf,
+ xfer-len, DMA_FROM_DEVICE);
It would be better to use the core DMA mapping code rather than open
coding. This code won't work for vmalloc()ed addresses, or physically
non-contiguous addresses unless there's an IOMMU fixing things up.
Ah, ok. So I just need a to setup the scatter gather page list and then do a
dma_map_sg. I'll resend once I have this in place.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm 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 3/3] usb: phy: msm: Do not do runtime pm if the phy is not idle
Hi, On Wed, Jun 18, 2014 at 06:01:08PM +0100, Srinivas Kandagatla wrote: Use case is when the phy is configured in host mode and a usb device is attached to board before bootup. On bootup, with the existing code and runtime pm enabled, the driver would decrement the pm usage count without checking the current state of the phy. This pm usage count decrement would trigger the runtime pm which than would abort the usb enumeration which was in progress. In my case a usb stick gets detected and then immediatly the driver goes to low power mode which is not correct. log: [1.631412] msm_hsusb_host 1252.usb: EHCI Host Controller [1.636556] msm_hsusb_host 1252.usb: new USB bus registered, assigned bus number 1 [1.642563] msm_hsusb_host 1252.usb: irq 220, io mem 0x1252 [1.658197] msm_hsusb_host 1252.usb: USB 2.0 started, EHCI 1.00 [1.659473] hub 1-0:1.0: USB hub found [1.663415] hub 1-0:1.0: 1 port detected ... [1.973352] usb 1-1: new high-speed USB device number 2 using msm_hsusb_host [2.107707] usb-storage 1-1:1.0: USB Mass Storage device detected [2.108993] scsi0 : usb-storage 1-1:1.0 [2.678341] msm_otg 1252.phy: USB in low power mode [3.168977] usb 1-1: USB disconnect, device number 2 This issue was detected on IFC6410 board. This patch fixes the intial runtime pm trigger by checking the phy state and decrementing the pm use count only when the phy state is IDLE. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- drivers/usb/phy/phy-msm-usb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c index 3bb559d..78cc870 100644 --- a/drivers/usb/phy/phy-msm-usb.c +++ b/drivers/usb/phy/phy-msm-usb.c @@ -1229,7 +1229,9 @@ static void msm_otg_sm_work(struct work_struct *w) motg-chg_state = USB_CHG_STATE_UNDEFINED; motg-chg_type = USB_INVALID_CHARGER; } - pm_runtime_put_sync(otg-phy-dev); + + if (otg-phy-state == OTG_STATE_B_IDLE) + pm_runtime_put_sync(otg-phy-dev); instead, you might as well just use autosuspend. -- balbi signature.asc Description: Digital signature
Re: [PATCH] spi: qup: Add DMA capabilities
On Fri, Jun 27, 2014 at 10:54:22AM -0500, Andy Gross wrote:
On Fri, Jun 27, 2014 at 11:50:57AM +0100, Mark Brown wrote:
On Thu, Jun 26, 2014 at 04:06:21PM -0500, Andy Gross wrote:
+ if (xfer-rx_buf) {
+ rx_dma = dma_map_single(controller-dev, xfer-rx_buf,
+ xfer-len, DMA_FROM_DEVICE);
It would be better to use the core DMA mapping code rather than open
coding. This code won't work for vmalloc()ed addresses, or physically
non-contiguous addresses unless there's an IOMMU fixing things up.
Ah, ok. So I just need a to setup the scatter gather page list and then do a
dma_map_sg. I'll resend once I have this in place.
Note that DMA from vmalloc'd memory is non-coherent on some platforms,
even if you use the DMA API.
The only thing that the DMA API guarantees is that the kernel mapping
will be made coherent for DMA purposes. No other mapping has this
guarantee.
Consider a VIVT cache (like the older ARMs). For this cache, you need
to find every alias of a physical page and flush it. The DMA API doesn't
have that information - it can only deal with the kernel's lowmem mapping.
We have introduced a couple of helpers recently to solve the problem of
vmalloc() (since a number of filesystems now do this trick) but the
vmalloc() user has to deal with the problem:
flush_kernel_vmap_range()
invalidate_kernel_vmap_range()
See the bottom of Documentation/cachetlb.txt for details.
The long and the short of it is that it's better if vmalloc()'d memory
is avoided where possible. It's also loads better if subsystems pass
physical references to memory for IO purposes where possible like our
block layer does (iow, struct page + offset, length) rather than
using randomly mapped virtual addresses, where the driver may not
know where the memory has come from.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: qup: Add DMA capabilities
On Fri, Jun 27, 2014 at 05:24:11PM +0100, Russell King - ARM Linux wrote: snip It would be better to use the core DMA mapping code rather than open coding. This code won't work for vmalloc()ed addresses, or physically non-contiguous addresses unless there's an IOMMU fixing things up. Ah, ok. So I just need a to setup the scatter gather page list and then do a dma_map_sg. I'll resend once I have this in place. Note that DMA from vmalloc'd memory is non-coherent on some platforms, even if you use the DMA API. Thankfully, that isn't the case on this platform. As as the QUP controller is only on Qualcomm chipsets, we don't have to worry about it being used on other platforms. -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
