omap3430 fails to boot
I've not looked into the reason why yet, so this is a heads-up. I notice this morning that the LDP3430 failed to boot last night, whereas it worked the previous night. However, SDP4430 looks fine. Nothing obvious in the diffstat between the two... but then the patch between the two kernels is almost 1.5MB. The arch/arm changes are quite small though: arch/arm/Kconfig |1 + arch/arm/boot/dts/Makefile |4 +- arch/arm/boot/dts/xenvm-4.2.dts| 13 + arch/arm/include/asm/xen/hypercall.h |1 + arch/arm/mach-msm/last_radio_log.c |2 +- arch/arm/mach-omap2/board-4430sdp.c|2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/timer.c|4 + arch/arm/mach-vexpress/v2m.c |1 - arch/arm/mach-virt/virt.c |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
arch/arm/mach-omap2/id.c - IS_ERR_OR_NULL()
So, I eliminated all but a very few of these from arch/arm, and I notice
today that there's a new couple of instances introduced by:
commit 6770b211432564c562c856d612b43bbd42e4ab5e
Author: Ruslan Bilovol ruslan.bilo...@ti.com
Date: Thu Feb 14 13:55:24 2013 +0200
ARM: OMAP2+: Export SoC information to userspace
In some situations it is useful for userspace to
know some SoC-specific information. For example,
this may be used for deciding what kernel module to
use or how to better configure some settings etc.
This patch exports OMAP SoC information to userspace
using existing in Linux kernel SoC infrastructure.
This information can be read under
/sys/devices/socX directory
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
[t...@atomide.com: updated for multiplatform changes]
Signed-off-by: Tony Lindgren t...@atomide.com
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR_OR_NULL(soc_dev)) {
+ kfree(soc_dev_attr);
+ return;
+ }
+
+ parent = soc_device_to_device(soc_dev);
+ if (!IS_ERR_OR_NULL(parent))
+ device_create_file(parent, omap_soc_attr);
This is nonsense. For the first, IS_ERR() is sufficient. For the second,
tell me what error checking is required in the return value of this
function:
struct device *soc_device_to_device(struct soc_device *soc_dev)
{
return soc_dev-dev;
}
when you've already determined that the passed soc_dev is a valid pointer.
If you read the comments against the prototype:
/**
* soc_device_to_device - helper function to fetch struct device
* @soc: Previously registered SoC device container
*/
struct device *soc_device_to_device(struct soc_device *soc);
if soc is valid, it means the previously registered SoC device container
must have succeeded and that can only happen if the struct device has been
registered. Ergo, there will always be a valid struct device pointer for
any registered SoC device container. Therefore, if soc_device_register()
succeeds, then the return value from soc_device_to_device() will always be
valid and no error checking of it is required.
Simples. The rule as ever applies here: get to know the APIs your using
and don't fumble around in the dark hoping that you'll get this stuff
right.
--
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: omap3430 fails to boot
* Russell King - ARM Linux li...@arm.linux.org.uk [130509 01:54]: I've not looked into the reason why yet, so this is a heads-up. I notice this morning that the LDP3430 failed to boot last night, whereas it worked the previous night. However, SDP4430 looks fine. Nothing obvious in the diffstat between the two... but then the patch between the two kernels is almost 1.5MB. The arch/arm changes are quite small though: arch/arm/Kconfig |1 + arch/arm/boot/dts/Makefile |4 +- arch/arm/boot/dts/xenvm-4.2.dts| 13 + arch/arm/include/asm/xen/hypercall.h |1 + arch/arm/mach-msm/last_radio_log.c |2 +- arch/arm/mach-omap2/board-4430sdp.c|2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/timer.c|4 + arch/arm/mach-vexpress/v2m.c |1 - arch/arm/mach-virt/virt.c |1 + Since one boots and one won't, you're probably missing this one: 956e46ef mm/slab: Fix crash during slab init Looking at your diffstat you probably have this as otherwise nothing boots: 9affd6be arm: fix mismerge of arch/arm/mach-omap2/timer.c Let me know if you still have the issue after updating to 956e46ef. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arch/arm/mach-omap2/id.c - IS_ERR_OR_NULL()
* Russell King - ARM Linux li...@arm.linux.org.uk [130509 02:14]:
So, I eliminated all but a very few of these from arch/arm, and I notice
today that there's a new couple of instances introduced by:
Sorry I should have noticed that fnord, I had it in my muttrc but had
a an unnecessary \ in the expression so it did not work.
Here's a patch to fix the issue.
Hmm maybe we could redefine IS_ERR_OR_NULL as error in some ARM header
as long as drivers don't include it?
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Thu, 9 May 2013 08:27:25 -0700
Subject: [PATCH] ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c
Commit 6770b211 (ARM: OMAP2+: Export SoC information to userspace)
had some broken return value handling as noted by Russell King:
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR_OR_NULL(soc_dev)) {
+ kfree(soc_dev_attr);
+ return;
+ }
+
+ parent = soc_device_to_device(soc_dev);
+ if (!IS_ERR_OR_NULL(parent))
+ device_create_file(parent, omap_soc_attr);
This is nonsense. For the first, IS_ERR() is sufficient. For the second,
tell me what error checking is required in the return value of this
function:
struct device *soc_device_to_device(struct soc_device *soc_dev)
{
return soc_dev-dev;
}
when you've already determined that the passed soc_dev is a valid pointer.
If you read the comments against the prototype:
/**
* soc_device_to_device - helper function to fetch struct device
* @soc: Previously registered SoC device container
*/
struct device *soc_device_to_device(struct soc_device *soc);
if soc is valid, it means the previously registered SoC device container
must have succeeded and that can only happen if the struct device has been
registered. Ergo, there will always be a valid struct device pointer for
any registered SoC device container. Therefore, if soc_device_register()
succeeds, then the return value from soc_device_to_device() will always be
valid and no error checking of it is required.
Simples. The rule as ever applies here: get to know the APIs your using
and don't fumble around in the dark hoping that you'll get this stuff
right.
Fix it as noted by Russell.
Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9bc5a18..1272c41 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -648,13 +648,12 @@ void __init omap_soc_device_init(void)
soc_dev_attr-revision = soc_rev;
soc_dev = soc_device_register(soc_dev_attr);
- if (IS_ERR_OR_NULL(soc_dev)) {
+ if (IS_ERR(soc_dev)) {
kfree(soc_dev_attr);
return;
}
parent = soc_device_to_device(soc_dev);
- if (!IS_ERR_OR_NULL(parent))
- device_create_file(parent, omap_soc_attr);
+ device_create_file(parent, omap_soc_attr);
}
#endif /* CONFIG_SOC_BUS */
--
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 0/3] ARM: omap3: add Seagate Wireless Plus board
* Jason Cooper ja...@lakedaemon.net [130508 17:41]: On Wed, May 08, 2013 at 12:45:04PM -0700, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [130508 12:29]: Tony has been helping me out offline with this, and he suggested trying the gpmc against Linus' ToT. Which locks up before it even has a chance to get going. So this series is against v3.9. You may have better luck with today's mainline treeand the following fix: http://lkml.org/lkml/2013/5/8/374# Ok, I'm attempting to do that, but got this for 'make dtbs': ERROR (phandle_references): Reference to non-existent node or label usb2_phy ERROR: Input tree has errors, aborting (use -f to force output) make[1]: *** [arch/arm/boot/dts/omap3-wireless_plus.dtb] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [dtbs] Error 2 which was created by: ad871c10 ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards It assumes the board has twl4030 (and then includes it). Bootlogs from the vendor provided kernel don't show a single message from twl4030, so I've omitted it. Assuming I did the correct thing by omitting the twl4030, I think the correct answer is to declare the phy in the dts files, like so: Thanks, that is correct. We should not assume any PMIC with a processor as it can also be a custom chip. For example, Nokia n8x0 is using their retu + tahvo chips instead of tps chips. I'll apply your patch into omap-for-v3.10/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] ARM: omap3: add Seagate Wireless Plus board
* Tony Lindgren t...@atomide.com [130509 09:03]: * Jason Cooper ja...@lakedaemon.net [130508 17:41]: On Wed, May 08, 2013 at 12:45:04PM -0700, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [130508 12:29]: Tony has been helping me out offline with this, and he suggested trying the gpmc against Linus' ToT. Which locks up before it even has a chance to get going. So this series is against v3.9. You may have better luck with today's mainline treeand the following fix: http://lkml.org/lkml/2013/5/8/374# Ok, I'm attempting to do that, but got this for 'make dtbs': ERROR (phandle_references): Reference to non-existent node or label usb2_phy ERROR: Input tree has errors, aborting (use -f to force output) make[1]: *** [arch/arm/boot/dts/omap3-wireless_plus.dtb] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [dtbs] Error 2 which was created by: ad871c10 ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards It assumes the board has twl4030 (and then includes it). Bootlogs from the vendor provided kernel don't show a single message from twl4030, so I've omitted it. Assuming I did the correct thing by omitting the twl4030, I think the correct answer is to declare the phy in the dts files, like so: Thanks, that is correct. We should not assume any PMIC with a processor as it can also be a custom chip. For example, Nokia n8x0 is using their retu + tahvo chips instead of tps chips. I'll apply your patch into omap-for-v3.10/fixes. I mean omap-for-v3.10/dt-fixes instead of fixes since it's .dts changes. Regards, Tony ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
Tony
On 05/08/2013 06:47 PM, Tony Lindgren wrote:
* Dan Murphy dmur...@ti.com [130418 11:35]:
On 04/18/2013 04:30 AM, Vincent Stehlé wrote:
On 04/17/2013 10:16 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
(..)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..0c48f6b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
(..)
@@ -135,6 +136,25 @@
0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
;
};
+
+ led_gpio_pins: pinmux_leds_pins {
+ pinctrl-single,pins =
+ ;
+ };
+};
Hi,
FYI, there was a recent discussion precisely on this topic, where Tomy
suggested to remove the empty section:
http://marc.info/?l=linux-omapm=136546635409232w=2
Apart from that, I just tested your patch on top of Tomy's
omap-for-v3.10/dt branch and it is working fine for me on PandaBoards
EA3, A4 and ES.
Tested-by: Vincent Stehlé v-ste...@ti.com
Best regards,
V.
Thanks for testing Vincent
Is there a way to append the data to an already existing node?
I do not see a clean way.
If you have something in omap4-panda-common.dtsi and the same entry
in the omap4-panda-es.dts, the entries in omap4-panda-es.dts will
override and append the entries in omap4-panda-common.dtsi.
So I think you can avoid the empty entry that way.
Regards,
Tony
Thanks but the issue is the led entry would not appear in the common file so
there is nothing to override.
Can we cleanly append to omap4_pmx_core without overriding the whole node?
I don't want to recreate the pmx_core node in the es file.
Dan
--
--
Dan Murphy
--
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: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
* Dan Murphy dmur...@ti.com [130509 11:13]: Can we cleanly append to omap4_pmx_core without overriding the whole node? I don't want to recreate the pmx_core node in the es file. Yes that should work just fine. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 1/2] omap fixes for v3.10 merge window part2
The following changes since commit 956e46efb2478ebff7a871138458fa8124fd18dd: mm/slab: Fix crash during slab init (2013-05-08 15:02:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-for-merge-window-part2 for you to fetch changes up to b1dd11d60e5357c13d3f3decfb69bd07dde159bd: ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c (2013-05-09 09:06:27 -0700) Omap fixes for things that were discovered during the merge window: - Few GPMC fixes and binding doc updates noted after sending pull requests for the GPMC branch. - Board fixes for beagle usb host and rx51 spi probe order - SoC fixes dt earlyprintk, omap1 dma and omap2+ id.c error handling fixes Then few minor things that are not strictly fixes but are good to get out of the way: - Add missing legacy mux registers for am/dm73x gpio - Add detection for am33xx pg2.1 silicon - Enable twl4030 audio modules in defconfig Aaro Koskinen (1): ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices Christoph Fritz (1): omap: mux: add AM/DM37x gpios Javier Martinez Canillas (3): Documentation: dt: update TI GPMC ethernet binding properties ARM: OMAP2+: only search for GPMC DT child nodes on probe ARM: OMAP2+: only WARN if a GPMC child probe function fail Jon Hunter (1): Documentation: dt: update properties in TI GPMC NAND example Kevin Hilman (1): ARM: OMAP2+: omap_device: use late_initcall_sync Peter Ujfalusi (1): ARM: OMAP4+: omap2plus_defconfig: Enable audio via TWL6040 as module Roger Quadros (1): ARM: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx Tony Lindgren (2): Merge branch 'omap-gpmc-fixes-for-v3.10' of git://github.com/jonhunter/linux into fixes ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c Vaibhav Hiremath (1): ARM: OMAP2: AM33XX: id: Add support for new AM335x PG2.1 Si Wei Yongjun (1): ARM: OMAP1: DMA: fix error handling in omap1_system_dma_init() .../devicetree/bindings/mtd/gpmc-nand.txt | 28 +-- Documentation/devicetree/bindings/net/gpmc-eth.txt | 56 +++--- arch/arm/configs/omap2plus_defconfig | 2 + arch/arm/mach-omap1/dma.c | 8 ++-- arch/arm/mach-omap2/board-omap3beagle.c| 6 +-- arch/arm/mach-omap2/board-rx51-peripherals.c | 4 +- arch/arm/mach-omap2/gpmc.c | 38 +-- arch/arm/mach-omap2/id.c | 13 +++-- arch/arm/mach-omap2/mux34xx.h | 6 ++- arch/arm/mach-omap2/omap_device.c | 2 +- arch/arm/mach-omap2/soc.h | 2 + 11 files changed, 81 insertions(+), 84 deletions(-) -- 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: [GIT PULL 1/2] omap fixes for v3.10 merge window part2
On Thu, May 09, 2013 at 11:46:51AM -0700, Tony Lindgren wrote: The following changes since commit 956e46efb2478ebff7a871138458fa8124fd18dd: mm/slab: Fix crash during slab init (2013-05-08 15:02:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-for-merge-window-part2 for you to fetch changes up to b1dd11d60e5357c13d3f3decfb69bd07dde159bd: ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c (2013-05-09 09:06:27 -0700) Pulled, thanks. As Arnd mentioned on an ux500 pull request earlier, we usually don't like fixes branches on non-rc bases, but since this is targeting pre-rc1 but post-what-we-merged, there's not much else to do. -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: [GIT PULL 2/2] omap device tree fixes for v3.10 merge window
On Thu, May 09, 2013 at 11:46:51AM -0700, Tony Lindgren wrote: The following changes since commit bb9055b2744ada735a2fe555c4196ad39a83ef2a: Merge tag 'multiplatform-for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2013-05-07 11:28:42 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dt-fixes-for-merge-window for you to fetch changes up to 914dc329ee11d6b1ecbebef802962dc06e78b942: ARM: dts: don't assume boards are using twl4030 for omap3 (2013-05-09 09:06:57 -0700) Pulled, 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: [GIT PULL 1/2] omap fixes for v3.10 merge window part2
* Olof Johansson o...@lixom.net [130509 13:20]: On Thu, May 09, 2013 at 11:46:51AM -0700, Tony Lindgren wrote: The following changes since commit 956e46efb2478ebff7a871138458fa8124fd18dd: mm/slab: Fix crash during slab init (2013-05-08 15:02:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/fixes-for-merge-window-part2 for you to fetch changes up to b1dd11d60e5357c13d3f3decfb69bd07dde159bd: ARM: OMAP2+: Remove bogus IS_ERR_OR_NULL checking from id.c (2013-05-09 09:06:27 -0700) Pulled, thanks. As Arnd mentioned on an ux500 pull request earlier, we usually don't like fixes branches on non-rc bases, but since this is targeting pre-rc1 but post-what-we-merged, there's not much else to do. Yes, sorry I should have mentioned that the commit these were based on is the one that fixed boot issues for me. So not a random commit of the day, and some of these had dependencies to the patches already merged. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: set device dma_mask without reference to global data
On Wed, May 08, 2013 at 01:42:11AM +0200, Arnd Bergmann wrote:
On Wednesday 08 May 2013, Greg Kroah-Hartman wrote:
On Tue, May 07, 2013 at 04:53:52PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Suggested-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Stephen Warren swar...@nvidia.com
So this needs to go in for 3.10, right? Any older kernels as well? If
so, which ones?
The fix should definitely go into 3.10, but I'd suggest waiting with
the backport for a couple of -rc releases to avoid possible regressions.
We know that the current code is broken, but few people fully understand
what is going on with coherent_dma_mask, so it might cause new problems
in combination with some other unknown bug, and I don't see this as
urgent: none of the ARM defconfigs build this driver as a loadable
module and there is no bug in the built-in case. For some reason, only
the ARM back-end drivers are broken.
The first occurence was apparently in 3.3, but only in ehci-tegra.c,
while the other drivers subsequently copied the bug.
I've already suggested this approach:
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index dc662fc..51bb740 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -22,6 +22,7 @@ struct dev_archdata {
struct omap_device;
struct pdev_archdata {
+ u64 dma_mask;
#ifdef CONFIG_ARCH_OMAP
struct omap_device *od;
#endif
And then we can have dev-dma_mask pointed at that instead, which fully
eliminates any possible problems of things like dma_set_mask() interfering
with dma_set_coherent_mask().
Even better - because this is a common problem - would be to make 'dma_mask'
be a member of struct platform_device so that all arches can sort this
out once and for all (correction: generic code/drivers can in an arch-
independent way.) IOW:
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 9abf1db..121c74c 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -26,6 +26,7 @@ struct platform_device {
struct device dev;
u32 num_resources;
struct resource *resource;
+ u64 dma_mask;
const struct platform_device_id *id_entry;
--
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] USB: set device dma_mask without reference to global data
On Wed, May 08, 2013 at 10:54:48AM +0800, Peter Chen wrote: This probably could be initialized from some DT property. However, there's no such property defined right now, and considering that DT is supposed to be an ABI, we'd always need the code in this patch as a fallback for DTs that were created before any such property was defined. Equally, since the data is SoC-specific rather than board-specific, and is even fairly unlikely to vary between SoC versions since these values are all 0x anyway, I don't really see much point in putting it into DT, rather than just putting the static data into the driver. I mean there is already dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); at function of_platform_device_create, why can't add dev-dev.dma_mask = dev-dev.coherent_dma_mask after that? Because technically they're different things, and if we have a driver somewhere which uses the DMA API correctly by making use of dma_set_mask() and dma_set_coherent_mask(), the two will interfere with each other. These two masks have always been separate. -- 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] USB: set device dma_mask without reference to global data
On Wed, May 08, 2013 at 09:24:44AM +0200, Arnd Bergmann wrote: It probably should. The main thing is that the dma_mask setting in of_platform (and elsewhere) is a mess and that nobody so far had the guts to try to get it right for good. Setting a 32 bit DMA mask is /probably/ the right default on all ARM systems, but there are caveats: - Once you get to systems with larger than 32 bit addressing (powerpc64, arm64, arm32 with LPAE), it's not so obvious: you may have some devices that need a 32 bit mask and some that need a 64 bit mask. This is precisely why drivers should be using dma_set_mask() and the coherent version to provide the mask for which the driver knows about - iow, if the device itself is only capable of 32-bit DMA, then the device must use dma_set_mask(dev, DMA_BIT_MASK(32)). -- 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
