Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On 07/05/13 22:06, Aaro Koskinen wrote: On Tue, May 07, 2013 at 12:27:11PM -0600, Jason Gunthorpe wrote: On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote: But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. Well, I do not see much of this attempt actually. Do you have some link / evidene that shows someone who actually cares about compiling drivers for targets that they are not used for? On this specific driver, I actually have had exactly the opposite advice [1]. I am not convinced people actually want to do that. There was a discussion a bit ago, but I can't find a link.. The context was subsystem maintainers are being asked to look after more code with the DT transition moving things out of arch/arm and at least one complained they couldn't even compile test on x86... But again, I can't find a link and you are right, there are lots and lots of 'depends ARCH..' style things in kConfig already. Lets just call it something to think about. Tomi started a thread related to this recently: http://marc.info/?l=linux-kernelm=136731558332265w=2 I think there's some good reasons listed there, but I guess up to the subsystem maintainers to decide what they prefer. As Sam pointed out in that thread, there's no need to change the Kconfig language for this. I did some testing with fb drivers, by having a CONFIG_ALL_FB_DRIVERS option which removes the arch dependencies for some fb drivers. It does uglify the Kconfig files a bit: - depends on FB (SUPERH || ARCH_SHMOBILE) HAVE_CLK + depends on FB (SUPERH || ARCH_SHMOBILE || ALL_FB_DRIVERS) HAVE_CLK I'm still undecided if I want to pursue this with fb drivers, as it seems that quite many of them do really depend on the arch code, and I'm not interested in trying to fix them. But if other subsystems would benefit of this also, perhaps we could have a common CONFIG entry that would allow compiling a driver on any arch. I just can't think of a good name for the config entry =). Tomi signature.asc Description: OpenPGP digital signature
[PATCH] ARM: OMAP3+: am33xx id: Add new am33xx specific function to check dev_feature
Layout of DEV_FEATURE register (offset = 0x604) is different
between TI81xx and AM33xx device, so create separate function
which will check for features available on specific AM33xx SoC
and set the flags accordingly.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/control.h |5 +
arch/arm/mach-omap2/id.c | 13 +
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/soc.h |1 +
4 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..4acdfc5 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -358,6 +358,11 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 22)
+/* DEV Feature register to identify AM33XX features */
+#define AM33XX_DEV_FEATURE 0x604
+#define AM33XX_SGX_SHIFT 29
+#define AM33XX_SGX_MASK(1 AM33XX_SGX_SHIFT)
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9bc5a18..02feef7 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -302,6 +302,19 @@ void __init ti81xx_check_features(void)
omap3_cpuinfo();
}
+void __init am33xx_check_features(void)
+{
+ u32 status;
+
+ omap_features = OMAP3_HAS_NEON;
+
+ status = omap_ctrl_readl(AM33XX_DEV_FEATURE);
+ if (status AM33XX_SGX_MASK)
+ omap_features |= OMAP3_HAS_SGX;
+
+ omap3_cpuinfo();
+}
+
void __init omap3xxx_check_revision(void)
{
const char *cpu_rev;
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..06a8946 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -576,7 +576,7 @@ void __init am33xx_init_early(void)
omap2_set_globals_prm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE));
omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
- ti81xx_check_features();
+ am33xx_check_features();
am33xx_voltagedomains_init();
am33xx_powerdomains_init();
am33xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index ccef2dd..7d8722c 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -424,6 +424,7 @@ void omap4xxx_check_revision(void);
void omap5xxx_check_revision(void);
void omap3xxx_check_features(void);
void ti81xx_check_features(void);
+void am33xx_check_features(void);
void omap4xxx_check_features(void);
/*
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: set device dma_mask without reference to global data
On Wednesday 08 May 2013, 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? If DT core can do above things, can we delete dma_mask assignment at every driver? 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. - Some (very rare these days, thankfully) devices require a mask that is less than 32 bits. Since that knowledge is device specific, not platform specific, it should probably stay in the driver. - There are cases (I know them only on powerpc, but they probably exist on ARM and other places too) where the mapping from bus addresses to physical addresses is not linear. There is a device-tree binding for a dma-ranges property that can accurately describe the specific mapping. Actually using this on architecture independent code requires not only setting the dma_mask but also supporting the remapping in the dma_map_ops. - Things get more interesting in combination with an IOMMU. If we have an IOMMU, I think we should set the dma_mask pointer to the mask of the IOMMU and set the map_ops accordingly. - Whether we actually need coherent_dma_mask these days is another hard question to answer. I suspect that the only thing really needing it was some version of the Itanium based Altix machine for its PCI devices and we'd be better off finding a simpler solution for platform devices. For all practical purposes I think coherent_dma_mask must be the same as dma_mask. Arnd -- 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
Hi, For the ramips target, the MIPS folks suggested another approach: The soc code finds the platform_device generated by DT and adds the dma_mask: http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html For completeness: It seems this approach is not going to be used after all. The approach (not this particular patch) was conceived to get ehci support on ramips, but now that echi also sets a default mask and it turns out that the other setup needed is best done through a phy device, this approach is probably not needed anymore for ehci. For dwc2, I guess it should also set up a dma_mask like ehci does (at least until we sort out this thread) :-) Gr. Matthijs -- 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
Hi folks, I also bumped into the question of how to set the dma_mask when enabling the dwc2 driver on the ramips target and found there didn't seem to be any clear way to get a dma_mask. It seems to me that in the pre-DT era, a platform_device would get a dma_mask when it was defined in the board / soc code, which makes sense since that code knows if a dma_mask is required and what its value should be (it seems to me that a driver can only know it needs a dma_mask, but not what value it should have?). 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. It seems there has already been a patch to implement this. For reference, this seems to be the most recent version: https://lkml.org/lkml/2012/12/4/54 And here's the previous attempt, to which Rob Herring refers in a reply. https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html 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? Perhaps it would sense to set the 32-bit mask as a default, but allow to override this mask from the devicetree for boards that need another value? Or perhaps override it from the soc code instead? For the ramips target, the MIPS folks suggested another approach: The soc code finds the platform_device generated by DT and adds the dma_mask: http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html If DT core can do above things, can we delete dma_mask assignment at every driver? That would seem like a likeably goal to me :-) Gr. Matthijs -- 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 05/08/2013 02:11 AM, Matthijs Kooijman wrote: Hi folks, I also bumped into the question of how to set the dma_mask when enabling the dwc2 driver on the ramips target and found there didn't seem to be any clear way to get a dma_mask. It seems to me that in the pre-DT era, a platform_device would get a dma_mask when it was defined in the board / soc code, which makes sense since that code knows if a dma_mask is required and what its value should be (it seems to me that a driver can only know it needs a dma_mask, but not what value it should have?). 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. It seems there has already been a patch to implement this. For reference, this seems to be the most recent version: https://lkml.org/lkml/2012/12/4/54 And here's the previous attempt, to which Rob Herring refers in a reply. https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html I believe most of the issues have been around supporting ARM LPAE systems. There is a much more simple approach to address this by using the dma_addr_t size to set the coherent_dma_mask which I have queued for 3.11: https://patchwork-mail1.kernel.org/patch/2495861/ This does not set dma_mask though. There's always been some mystery around why there are separate masks. I think for most systems dma_mask can be set to coherent_dma_mask based on what Arnd found: http://pastebin.com/E7fFVJyq This can always be overridden by a platform with a bus notifier or by a driver if needed. Rob 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? Perhaps it would sense to set the 32-bit mask as a default, but allow to override this mask from the devicetree for boards that need another value? Or perhaps override it from the soc code instead? For the ramips target, the MIPS folks suggested another approach: The soc code finds the platform_device generated by DT and adds the dma_mask: http://www.linux-mips.org/archives/linux-mips/2013-04/msg00162.html If DT core can do above things, can we delete dma_mask assignment at every driver? That would seem like a likeably goal to me :-) Gr. Matthijs ___ 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: [PATCH] USB: set device dma_mask without reference to global data
On Wednesday 08 May 2013, Rob Herring wrote: On 05/08/2013 02:11 AM, Matthijs Kooijman wrote: https://lkml.org/lkml/2012/12/4/54 And here's the previous attempt, to which Rob Herring refers in a reply. https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-March/013180.html I believe most of the issues have been around supporting ARM LPAE systems. There is a much more simple approach to address this by using the dma_addr_t size to set the coherent_dma_mask which I have queued for 3.11: https://patchwork-mail1.kernel.org/patch/2495861/ Hmm, this approach seems wrong -- a lot of devices I expect cannot actually do DMA to addresses beyond 4GB. A better default would be to use a 32 bit mask for all devices and override the ones that actually matter for performance and are known to be 64-bit DMA capable. Laura, you obviously tried this code on an LPAE-enabled system. Have you had a look in the hardware manual which DMA masters in the system are actually 64-bit capable? Arnd -- 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, 8 May 2013, 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. An alternative solution -- perhaps not better but also not relying on coherent_dma_mask -- is to clear pdev-dev.dma_mask in the remove routine if it points to the static mask value. Alan Stern -- 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 Wednesday 08 May 2013, Alan Stern wrote: The first occurence was apparently in 3.3, but only in ehci-tegra.c, while the other drivers subsequently copied the bug. An alternative solution -- perhaps not better but also not relying on coherent_dma_mask -- is to clear pdev-dev.dma_mask in the remove routine if it points to the static mask value. Yes, I thought about that, but couldn't see any advantage one way or the other and this one seemed simpler. Arnd -- 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 V5 3/6] ARM: dts: OMAP4: add clock nodes for CPU
OMAP443x, OMAP446x and OMAP447x platforms use dpll_mpu clock.
Add same to common definition.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
no change in current revision.
Previous version: http://marc.info/?l=linux-kernelm=136580751024225w=2
arch/arm/boot/dts/omap4.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..1c6d969 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -31,6 +31,8 @@
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
+ clocks = dpll_mpu;
+ clock-names = cpu;
};
cpu@1 {
compatible = arm,cortex-a9;
@@ -106,6 +108,11 @@
ti,hwmods = counter_32k;
};
+ dpll_mpu: dpll_mpu {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
--
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 V5 2/6] ARM: dts: OMAP3: add clock nodes for CPU
OMAP34xx and OMAP36xx platforms use dpll1 clock. Add same to common
definition.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
no change in current revision.
Previous version: http://marc.info/?l=linux-kernelm=136580740024201w=2
arch/arm/boot/dts/omap3.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4ad03d9..4f445ca 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -23,6 +23,8 @@
cpus {
cpu@0 {
compatible = arm,cortex-a8;
+ clocks = dpll1;
+ clock-names = cpu;
};
};
@@ -73,6 +75,11 @@
ti,hwmods = counter_32k;
};
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
--
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 V5 4/6] ARM: dts: AM33XX: add clock nodes for CPU
AM33XX based platforms use dpll_mpu clock. Add same to common dtsi
and remove the dummy clock node entry as AM33XX platform supports
only device tree based boot.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Change in this revision from previous:
- rebase, no functional change.
Previous version: http://marc.info/?l=linux-kernelm=136580755324232w=2
arch/arm/boot/dts/am33xx.dtsi |7 +++
arch/arm/mach-omap2/cclock33xx_data.c |1 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d110110..27f6eb1 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -42,6 +42,8 @@
275000 1125000
;
voltage-tolerance = 2; /* 2 percentage */
+ clocks = dpll_mpu;
+ clock-names = cpu;
clock-latency = 30; /* From omap-cpufreq driver */
};
};
@@ -89,6 +91,11 @@
reg = 0x4820 0x1000;
};
+ dpll_mpu: dpll_mpu {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+
gpio0: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index 6ebc780..4e39171 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -860,7 +860,6 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck),
CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck),
CLK(NULL, dpll_mpu_ck, dpll_mpu_ck),
- CLK(cpu0, NULL, dpll_mpu_ck),
CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck),
CLK(NULL, dpll_ddr_ck, dpll_ddr_ck),
CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck),
--
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 V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are currently found via clock
aliases table. There are many possible approaches to this problem as
discussed in the following thread:
http://marc.info/?t=13637032569r=1w=2.
Highlights of the options:
a) device specific clk_add_alias:
cons: driver handling required
b) using an generic clk node and indexing to reach the clock required.
This is similar in approach taken by tegra and few other platforms.
Example usage: clock = clk 5;
cons: potential to have mismatches in indexed table and associated
dtb data. In addition, managing continued documentation in bindings
as clock indexing increases. Even though readability angle could be
improved by using preprocessing of DT using macros, indexed
approach is inherently risky from cases like the following:
clk indexes in kernel:
1 - mpu_dpll
2 - aux_clk1
3 - core_clk
DT entry for peripheral X uses clk 2 to reach aux_clk1. Now, let's
say kernel updates indices to:
1 - mpu_dpll
2 - per_dpll
3 - aux_clk1
4 - core_clk
using the old dtb(or dts missing an update), on new kernel which
has updated indices will result in per_dpll now controlled for
peripheral X without warning or any potential error detection.
Even though we could claim this is user error, such errors are hard
to track down and fix.
An alternate approach introduced here is to introduce device tree
bindings corresponding to the clock nodes required in DT definition
for SoC which automatically maps back to the definitions in
cclockXYZ_data.c.
The driver introduced here to do this mapping will eventually be the
place where the clock handling will migrate to. We need to consider
this angle as well so that the solution will be an valid transition
point for moving the clock data out of kernel image (into device tree
or firmware load etc..).
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
http://marc.info/?t=13658075851r=1w=2
.../devicetree/bindings/clock/omap-clock.txt | 40 +
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c | 91
4 files changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt
b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,omap-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in
arch/arm/mach-omap2/cclockSoC_data.c
+Since all clocks are described with _ck, the node name is optimized to drop the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+ CLK(NULL, dpll1_ck, dpll1_ck, CK_3XXX),
+Corresponding binding will be:
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = dpll1;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+ CLK(NULL, auxclk3_ck, auxclk3_ck,CK_443X),
+Corresponding binding will be:
+ auxclk3: auxclk3 {
+
[PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
The following version 5 of the series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the generic cpufreq-cpu0 driver to be used in device tree enabled boot while maintaining support of the legacy omap-cpufreq driver when used in non device tree enabled boot. However, in order to enable complete SoC entitlement for OMAP platforms, with this series, key features are still pending on device tree adaptation for OMAP: A) clock framework data transition to DT - this series provides an driver to allow device tree definition of clock node. B) On processors that use voltage controller, voltage processor (VC/VP hardware loop using I2C_SR path) - we have started work on transitioning them to regulator framework driven by DT. C) Adaptive Body Bias[2] and SmartReflex AVS conversion to DT. Note: Common Clock Framework(CCF) could also control regulators[3] and AVS to ensure proper sequencing required for full DVFS sequencing. Once these conversions are complete, there might be minimal cleanup work to switch to the new data structure changes. Key benefit of the series is to allow all relevant TI platforms now to use a single cpufreq driver and equivalent frameworks in addition be part of the transition to device tree. NOTE on this series: 1. omap-cpufreq will be used only in non device tree boot scenario. we should delete this driver once the 100% DT conversion is complete. 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario boot systems 3. clock data movement as approached by Tero in [4] is not the objective of this series 4. meant for post 3.10-rc1 tag Key changes in version 5 since version 4: - rebase with master for 3.10-rc1 intermediate - review comments incorporated version 4 of the series: http://marc.info/?l=linux-arm-kernelm=136580742724210w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v4 version 3 of the series: http://marc.info/?l=linux-pmm=136450759315742w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3 version 2 of the series: http://marc.info/?t=13637157023r=1w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2 version 1 of the series: http://marc.info/?t=13632948545r=1w=2 available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 [1] Original discussion thread which triggered this series: http://marc.info/?l=linux-pmm=136304313700602w=2 https://patchwork.kernel.org/patch/2251841/ https://patchwork.kernel.org/patch/2251851/ [2] ABB series: http://marc.info/?l=linux-omapm=136751559523901w=2 (ABB DTS merge pending) [3] CCF DVFS patches: https://patchwork.kernel.org/patch/2195431/ https://patchwork.kernel.org/patch/2195421/ https://patchwork.kernel.org/patch/2195451/ https://patchwork.kernel.org/patch/2195441/ https://patchwork.kernel.org/patch/2195461/ [4] http://marc.info/?t=13638874501r=1w=2 Version 5 is now based on master since all requisite for-next branches have been merged. master 5af43c2 Merge branch 'akpm' (incoming from Andrew) Version 4 is also available at: https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v5 git link: git://github.com/nmenon/linux-2.6-playground.git branch: cpufreq-cpu0-omap-all-v5 Test coverage: test script: http://pastebin.com/GsavxiDe (note - to allow testing, I followed the suggestion in https://lkml.org/lkml/2013/5/8/19 ) Platforms verified: beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/zANKsYBp beagleboard (rev C1D) - OMAP3430 compatible - DT enabled boot: http://pastebin.com/q4qZYVaK - No DT enabled boot: http://pastebin.com/c1CbQmV5 omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/ibUABcA0 SDP4430 -(OMAP4430 ES2.2) - http://pastebin.com/wYwUc3fU Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/FB2RiFp2 Nishanth Menon (6): clk: OMAP: introduce device tree binding to kernel clock data [Clk driver probably belongs to mike's tree?] ARM: dts: OMAP3: add clock nodes for CPU ARM: dts: OMAP4: add clock nodes for CPU ARM: dts: AM33XX: add clock nodes for CPU [The above probably belong to Benoit's tree] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot [The above probably belong to Kevin/Tony's tree] .../devicetree/bindings/clock/omap-clock.txt | 40 + arch/arm/boot/dts/am33xx.dtsi |7 ++ arch/arm/boot/dts/omap3.dtsi |7 ++ arch/arm/boot/dts/omap4.dtsi |7 ++
[PATCH V5 5/6] ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init
Call OMAP2+ generic lateinit hook from AM specific late init hook.
This allows the generic late initializations such as cpufreq hooks
to be active.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Change in this revision compared to previous revision:
- rebase, no functional change.
Previous version: http://marc.info/?l=linux-kernelm=136580760924258w=2
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/io.c|6 ++
3 files changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 88aa6b1..2c5c67c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -141,6 +141,7 @@ DT_MACHINE_START(AM33XX_DT, Generic AM33XX (Flattened
Device Tree))
.init_irq = omap_intc_of_init,
.handle_irq = omap3_intc_handle_irq,
.init_machine = omap_generic_init,
+ .init_late = am33xx_init_late,
.init_time = omap3_gptimer_timer_init,
.dt_compat = am33xx_boards_compat,
.restart= am33xx_restart,
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index d555cf2..e2d7ecf 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -107,6 +107,7 @@ void omap35xx_init_late(void);
void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
+void am33xx_init_late(void);
int omap2_common_pm_late_init(void);
#ifdef CONFIG_SOC_BUS
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..401e268 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -584,6 +584,12 @@ void __init am33xx_init_early(void)
omap_hwmod_init_postsetup();
omap_clk_init = am33xx_clk_init;
}
+
+void __init am33xx_init_late(void)
+{
+ omap2_common_pm_late_init();
+}
+
#endif
#ifdef CONFIG_ARCH_OMAP4
--
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 V5 6/6] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points and clock nodes defined, we can now use
the SoC generic cpufreq-cpu0 driver by registering appropriate device.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
no change in current revision.
Previous version: http://marc.info/?l=linux-omapm=136580759924239w=2
arch/arm/mach-omap2/pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e742118..11bd585 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -266,7 +266,12 @@ static void __init omap4_init_voltages(void)
static inline void omap_init_cpufreq(void)
{
- struct platform_device_info devinfo = { .name = omap-cpufreq, };
+ struct platform_device_info devinfo = { };
+
+ if (!of_have_populated_dt())
+ devinfo.name = omap-cpufreq;
+ else
+ devinfo.name = cpufreq-cpu0;
platform_device_register_full(devinfo);
}
@@ -300,9 +305,9 @@ int __init omap2_common_pm_late_init(void)
/* Smartreflex device init */
omap_devinit_smartreflex();
- /* cpufreq dummy device instantiation */
- omap_init_cpufreq();
}
+ /* cpufreq dummy device instantiation */
+ omap_init_cpufreq();
#ifdef CONFIG_SUSPEND
suspend_set_ops(omap_pm_ops);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/3] ARM: omap3: Seagate Wireless Plus board
Hynix include file copied from vendor supplied source code.
Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
arch/arm/mach-omap2/board-generic.c| 26 +++
arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h | 30 ++
2 files changed, 56 insertions(+)
create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index e54a480..10b567c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -21,6 +21,7 @@
#include common.h
#include common-board-devices.h
#include dss-common.h
+#include sdram-hynix-h8kds0un0mer-4em.h
#if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
#define intc_of_init NULL
@@ -51,6 +52,13 @@ static void __init omap_generic_init(void)
omap_4430sdp_display_init_of();
}
+static void __init seagate_wireless_plus_init(void)
+{
+ omap_sdrc_init(h8kds0un0mer4em_sdrc_params, NULL);
+
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
ti,omap2420,
@@ -90,6 +98,24 @@ MACHINE_END
#endif
#ifdef CONFIG_ARCH_OMAP3
+static const char *seagate_wireless_plus_compat[] __initdata = {
+ seagate,wireless-plus,
+ NULL,
+};
+
+DT_MACHINE_START(SEAGATE_WIRELESS_PLUS_DT, Seagate Wireless Plus (Flattened
Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3430_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = seagate_wireless_plus_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = seagate_wireless_plus_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
NULL,
diff --git a/arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h
b/arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h
new file mode 100644
index 000..82b58131
--- /dev/null
+++ b/arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h
@@ -0,0 +1,30 @@
+/*
+ * SDRC register values for the Hynix H8KDS0UN0MER-4EM
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8KDS0UN0MER4EM
+#define __ARCH_ARM_MACH_OMAP2_SDRAM_HYNIX_H8KDS0UN0MER4EM
+
+#include sdrc.h
+
+/* Hynix H8KDS0UN0MER-4EM */
+static struct omap_sdrc_params h8kds0un0mer4em_sdrc_params[] = {
+ [0] = {
+ .rate= 2,
+ .actim_ctrla = 0x92e1c4c6,
+ .actim_ctrlb = 0x0002111c,
+ .rfr_ctrl= 0x0004dc01,
+ .mr = 0x0032,
+ },
+ [1] = {
+ .rate= 0
+ },
+};
+
+#endif
--
1.8.2.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
[RFC PATCH 3/3] ARM: omap3: wireless plus gpmc wip
Need this in order to add the nand node and then the partitions.
in it's current state, crashes the system. :(
---
arch/arm/boot/dts/omap3-wireless_plus.dts | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-wireless_plus.dts
b/arch/arm/boot/dts/omap3-wireless_plus.dts
index 8a0acdf..6f33731 100644
--- a/arch/arm/boot/dts/omap3-wireless_plus.dts
+++ b/arch/arm/boot/dts/omap3-wireless_plus.dts
@@ -17,6 +17,23 @@
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
};
+
+ gpmc: gpmc@6800A000 {
+ compatible = ti,omap2430-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x6800A000 0x2000;
+ /* interrupts = 100; */
+ pinctrl-names = default;
+ pinctrl-0 = gpmc_pins;
+
+ gpmc,num-cs = 8;
+ gpmc,num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x1000;
+
+ /* child nodes go here */
+ };
};
omap3_pmx_core {
@@ -26,7 +43,7 @@
* itself during the boot (or just set them up in the bootloader)
*/
pinctrl-names = default;
- pinctrl-0 = sdrc_pins gpmc_pins hsusb1_pins;
+ pinctrl-0 = sdrc_pins hsusb1_pins;
/* AM3703CUS pins for this board */
sdrc_pins: pinmux_sdrc_pins {
--
1.8.2.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
[RFC PATCH 0/3] ARM: omap3: add Seagate Wireless Plus board
All, This is a work in progress. All mistakes are mine. Seriously. I've never touched omap before. It should be obvious. History: The Wireless Plus is a portable, 1TB HD with an ~ 4 hour battery, and a wifi hotspot. It's only external connection is the SATA port (GoFlex connector). The Wireless Plus is the successor to the GoFlex Wireless. Full source can be found here [1] (GoFlex Wireless). These appear to be exactly the same at the hardware level. The primary difference is drive capacity, and the Wireless Plus exposes uart1 to an unpopulated header in the corner of the board, so I chose to develop on it. :-) Technical: Both boards are using an AM3703 SoC and the tps6507x power regulator/battery charger. Both are using the Hynix h8kds0un0mer-4em RAM module. Status: The following patches are a work-in-progress and are based against v3.9. It basically boots (to rootfs panic) with patches 1 and 2. The gpmc patch oops out. I've included it in the hopes that someone can laugh at me and maybe give me a pointer. I need it to work in order to add the child node for the nand, and then the child nodes for the partitions. 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. The current state of the dts file has been to silence warnings/errors. I disabled a bunch of unused devices, and added the pinctrl nodes in order to remove the pins not found kind of errors. As for their correctness, I haven't been able to test yet. I've done a liberal amount of copying from the provided sources for u-boot and the kernel. If you're motivated, grepping those sources for 'satellite|vavni' locates most of the changes made by Seagate. Current Problem: There are several gaps in my understanding of how far along TI's conversion to DT is. Should I be doing a separate board file for initializing the legacy items? I was hoping to do it all with DT. Obviously, I don't expect anybody to run out and buy one of these, take it apart, and try to boot this code. But if the omap guys could take a look at this and give me a few pointers, I'd appreciate it. I'm kind of spinning my wheels at the moment. Primarily, I'd like to get nand and usb working, so that I can read/write, mount a rootfs and do better testing. thx, Jason. [1] http://www.seagate.com/support/downloads/item/satellite-gpl-fw-master-dl/ Jason Cooper (3): ARM: omap3: Seagate Wireless Plus board ARM: omap3: Seagate Wireless Plus DT entry ARM: omap3: wireless plus gpmc wip arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/omap3-wireless_plus.dts | 331 + arch/arm/mach-omap2/board-generic.c| 26 ++ arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h | 30 ++ 4 files changed, 388 insertions(+) create mode 100644 arch/arm/boot/dts/omap3-wireless_plus.dts create mode 100644 arch/arm/mach-omap2/sdram-hynix-h8kds0un0mer-4em.h -- 1.8.2.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
[RFC PATCH 2/3] ARM: omap3: Seagate Wireless Plus DT entry
Signed-off-by: Jason Cooper ja...@lakedaemon.net
---
NOTE: please see coverletter for details.
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/omap3-wireless_plus.dts | 314 ++
2 files changed, 315 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-wireless_plus.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9c62558..a022a42 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
+ omap3-wireless_plus.dtb \
omap4-panda.dtb \
omap4-panda-a4.dtb \
omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap3-wireless_plus.dts
b/arch/arm/boot/dts/omap3-wireless_plus.dts
new file mode 100644
index 000..8a0acdf
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-wireless_plus.dts
@@ -0,0 +1,314 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = Seagate Wireless Plus (AM3703);
+ compatible = seagate,wireless-plus, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+};
+
+omap3_pmx_core {
+
+ /*
+* map all board specific static pins enabled by the pinctrl driver
+* itself during the boot (or just set them up in the bootloader)
+*/
+ pinctrl-names = default;
+ pinctrl-0 = sdrc_pins gpmc_pins hsusb1_pins;
+
+ /* AM3703CUS pins for this board */
+ sdrc_pins: pinmux_sdrc_pins {
+ pinctrl-single,pins =
+ 0x 0x100 /* SDRC_D0 (IEN | PTD | DIS | M0) */
+ 0x0002 0x100 /* SDRC_D1 (IEN | PTD | DIS | M0) */
+ 0x0004 0x100 /* SDRC_D2 (IEN | PTD | DIS | M0) */
+ 0x0006 0x100 /* SDRC_D3 (IEN | PTD | DIS | M0) */
+ 0x0008 0x100 /* SDRC_D4 (IEN | PTD | DIS | M0) */
+ 0x000A 0x100 /* SDRC_D5 (IEN | PTD | DIS | M0) */
+ 0x000C 0x100 /* SDRC_D6 (IEN | PTD | DIS | M0) */
+ 0x000E 0x100 /* SDRC_D7 (IEN | PTD | DIS | M0) */
+ 0x0010 0x100 /* SDRC_D8 (IEN | PTD | DIS | M0) */
+ 0x0012 0x100 /* SDRC_D9 (IEN | PTD | DIS | M0) */
+ 0x0014 0x100 /* SDRC_D10 (IEN | PTD | DIS | M0) */
+ 0x0016 0x100 /* SDRC_D11 (IEN | PTD | DIS | M0) */
+ 0x0018 0x100 /* SDRC_D12 (IEN | PTD | DIS | M0) */
+ 0x001A 0x100 /* SDRC_D13 (IEN | PTD | DIS | M0) */
+ 0x001C 0x100 /* SDRC_D14 (IEN | PTD | DIS | M0) */
+ 0x001E 0x100 /* SDRC_D15 (IEN | PTD | DIS | M0) */
+ 0x0020 0x100 /* SDRC_D16 (IEN | PTD | DIS | M0) */
+ 0x0022 0x100 /* SDRC_D17 (IEN | PTD | DIS | M0) */
+ 0x0024 0x100 /* SDRC_D18 (IEN | PTD | DIS | M0) */
+ 0x0026 0x100 /* SDRC_D19 (IEN | PTD | DIS | M0) */
+ 0x0028 0x100 /* SDRC_D20 (IEN | PTD | DIS | M0) */
+ 0x002A 0x100 /* SDRC_D21 (IEN | PTD | DIS | M0) */
+ 0x002C 0x100 /* SDRC_D22 (IEN | PTD | DIS | M0) */
+ 0x002E 0x100 /* SDRC_D23 (IEN | PTD | DIS | M0) */
+ 0x0030 0x100 /* SDRC_D24 (IEN | PTD | DIS | M0) */
+ 0x0032 0x100 /* SDRC_D25 (IEN | PTD | DIS | M0) */
+ 0x0034 0x100 /* SDRC_D26 (IEN | PTD | DIS | M0) */
+ 0x0036 0x100 /* SDRC_D27 (IEN | PTD | DIS | M0) */
+ 0x0038 0x100 /* SDRC_D28 (IEN | PTD | DIS | M0) */
+ 0x003A 0x100 /* SDRC_D29 (IEN | PTD | DIS | M0) */
+ 0x003C 0x100 /* SDRC_D30 (IEN | PTD | DIS | M0) */
+ 0x003E 0x100 /* SDRC_D31 (IEN | PTD | DIS | M0) */
+ 0x0040 0x100 /* SDRC_CLK (IEN | PTD | DIS | M0) */
+ 0x0042 0x100 /* SDRC_DQS0 (IEN | PTD | DIS | M0) */
+ 0x0044 0x100 /* SDRC_DQS1 (IEN | PTD | DIS | M0) */
+ 0x0046 0x100 /* SDRC_DQS2 (IEN | PTD | DIS | M0) */
+ 0x0048 0x100 /* SDRC_DQS3 (IEN | PTD | DIS | M0) */
+ ;
+ };
+
+ gpmc_pins: pinmux_gpmc_pins {
+ pinctrl-single,pins =
+ 0x004A 0x018 /* GPMC_A1 (IDIS | PTU | EN | M0) */
+
OMAP baseline test results for v3.9-rc8
Here are some basic OMAP test results for Linux v3.9-rc8.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc8/20130422154921/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 1/11): am335xbone
Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
5912osk, cmt3517
PM ret, suspend:
FAIL ( 2/ 6): 2430sdp, 4430es2panda
Pass ( 4/ 6): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes
PM ret, dynamic idle:
FAIL ( 3/ 6): 2430sdp, 4430es2panda, 4460pandaes
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 37xxevm
PM off, suspend:
FAIL ( 2/ 5): 4430es2panda, 4460pandaes
Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm
PM off, dynamic idle:
FAIL ( 2/ 5): 4430es2panda, 4460pandaes
Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm
Failing tests: fixed by posted patches
--
Build:
* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
errors
- Discussion RFC patch:
http://www.spinics.net/lists/arm-kernel/msg230017.html
- Still needs revision of the patch
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
Boot warnings:
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
Failing tests: reported by others
-
- MUSB broken after v3.9-rc6
- due to commit 92702df3570e1ccfa050e135e50c450502251b79
- discussion here: http://marc.info/?l=linux-omapm=136544098331552w=2
- patch pending upstream:
http://marc.info/?l=linux-omapm=136562302329307w=2
vmlinux object size
(delta in bytes from test_v3.9-rc7
(41ef2d5678d83af030125550329b6ae8b74618fa)):
text data bsstotal kernel
+408 +80 +416 n800_multi_omap2xxx
+408 +80 +416 n800_only_a
+54 -80 +46 omap1_defconfig
+58 -80 +50 omap1_defconfig_1510innovator_only
+54 +240 +78 omap1_defconfig_5912osk_only
+252 +960 +348 omap2plus_defconfig
+4348 +720+4420 omap2plus_defconfig_cpupm
+388 +640 +452 omap2plus_defconfig_no_pm
+252 +720 +324 omap2plus_defconfig_omap2_4_only
+4236 +800+4316 omap2plus_defconfig_omap3_4_only
+168 +16 -40 +144 rmk_omap3430_ldp_allnoconfig
-4040 -80-4048 rmk_omap3430_ldp_oldconfig
+168 +16 -40 +144 rmk_omap4430_sdp_allnoconfig
+1920 +8 +200 rmk_omap4430_sdp_oldconfig
--
To unsubscribe from this list: send the line
OMAP baseline test results for v3.9
Here are some basic OMAP test results for Linux v3.9.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9/20130429104339/
Test summary
Build:
FAIL ( 2/16): am33xx_only, omap2plus_defconfig_2430sdp_only
Pass (14/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 1/11): am335xbone
Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
5912osk, cmt3517
PM ret, suspend:
FAIL ( 2/ 6): 2430sdp, 4430es2panda
Pass ( 4/ 6): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes
PM ret, dynamic idle:
FAIL ( 3/ 6): 2430sdp, 4430es2panda, 4460pandaes
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 37xxevm
PM off, suspend:
FAIL ( 2/ 5): 4430es2panda, 4460pandaes
Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm
PM off, dynamic idle:
FAIL ( 2/ 5): 4430es2panda, 4460pandaes
Pass ( 3/ 5): 3530es3beagle, 3730beaglexm, 37xxevm
Failing tests: fixed by posted patches
--
Build:
* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
errors
- Discussion RFC patch:
http://www.spinics.net/lists/arm-kernel/msg230017.html
- Still needs revision of the patch
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
Boot warnings:
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
vmlinux object size
(delta in bytes from test_v3.9-rc8
(60d509fa6a9c4653a86ad830e4c4b30360b23f0e)):
text data bsstotal kernel
+176 +80 +184 n800_multi_omap2xxx
+160 +80 +168 n800_only_a
+120 +80 +128 omap1_defconfig
+136 +80 +144 omap1_defconfig_1510innovator_only
+152 -240 +128 omap1_defconfig_5912osk_only
+20400 +204 omap2plus_defconfig
+20400 +204 omap2plus_defconfig_cpupm
+20400 +204 omap2plus_defconfig_no_pm
+20400 +204 omap2plus_defconfig_omap2_4_only
+20400 +204 omap2plus_defconfig_omap3_4_only
+13200 +132 rmk_omap3430_ldp_allnoconfig
+8000 +80 rmk_omap3430_ldp_oldconfig
+13200 +132 rmk_omap4430_sdp_allnoconfig
+9600 +96 rmk_omap4430_sdp_oldconfig
vmlinux object size
(delta in bytes from test_v3.8
(19f949f52599ba7c3f67a5897ac6be14bfcb1200)):
text data bsstotal kernel
-549808 +23520-9184 -535472 n800_multi_omap2xxx
-548359 +27432-9268 -530195 n800_only_a
+61909+5680 +392 +67981 omap1_defconfig
+62549+5664 +424 +68637 omap1_defconfig_1510innovator_only
+63725
Re: [RFC PATCH 0/3] ARM: omap3: add Seagate Wireless Plus board
* 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# 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
* Jason Cooper ja...@lakedaemon.net [130508 12:29]: Current Problem: There are several gaps in my understanding of how far along TI's conversion to DT is. Should I be doing a separate board file for initializing the legacy items? I was hoping to do it all with DT. Sorry forgot to reply to this.. No seprate board file should be needed, some devices may still need to be initialized with pdata based on the compatible flag. Obviously, I don't expect anybody to run out and buy one of these, take it apart, and try to boot this code. But if the omap guys could take a look at this and give me a few pointers, I'd appreciate it. I'm kind of spinning my wheels at the moment. Primarily, I'd like to get nand and usb working, so that I can read/write, mount a rootfs and do better testing. The USB should be doable with device tree. At least both echi and musb are working properly on pandaboard. I think people have been using NAND with the gpmc DT patches, but I don't know the current status for sure. Is the hard drive on the EHCI bus or how is it connected to omap? 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
On Wed, May 08, 2013 at 12:51:53PM -0700, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [130508 12:29]: Current Problem: There are several gaps in my understanding of how far along TI's conversion to DT is. Should I be doing a separate board file for initializing the legacy items? I was hoping to do it all with DT. Sorry forgot to reply to this.. No seprate board file should be needed, some devices may still need to be initialized with pdata based on the compatible flag. ti,hwmod, right? Obviously, I don't expect anybody to run out and buy one of these, take it apart, and try to boot this code. But if the omap guys could take a look at this and give me a few pointers, I'd appreciate it. I'm kind of spinning my wheels at the moment. Primarily, I'd like to get nand and usb working, so that I can read/write, mount a rootfs and do better testing. The USB should be doable with device tree. At least both echi and musb are working properly on pandaboard. I think people have been using NAND with the gpmc DT patches, but I don't know the current status for sure. I'll try your suggestion in your other email for ToT and see if I can get gpmc going. Is the hard drive on the EHCI bus or how is it connected to omap? via ehci. They brutalized the tps driver to detect if the goflex cable was attached or not. Once I get something stable, I'll probably write a separate driver for that code. Or, push it out to userspace. thx, Jason. -- 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: 4430sdp nfsroot broken with ff5c9059
* Jon Hunter jon-hun...@ti.com [130410 10:35]: Hi Tony, On 04/09/2013 04:23 PM, Tony Lindgren wrote: Hi Jon, Looks like at least 4430sdp nfsroot got broken with commit ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells property). Thanks for reporting. I am actually amazed that ethernet is working on any OMAP board (with device-tree) that requires a gpio as an interrupt because we have still not come to an agreement on [1]. Looking at the OMAP4 SDP I believe this is working by luck because there are other gpios in the same bank that are active and so the bank is enabled. If that were not the case then this would not work. Hence, I have not been testing ethernet when booting with device-tree because we need to fix [1] which has been really crippling my testing. So this needs to be resolved so ethernet can work consistently on all omap boards. Do we need to pass the GPIO edge/level info now? Yes and here is a patch. I have tested on my OMAP4 SDP this morning. Reviewing all the OMAP/AM dts(i) files I believe that only the SDP and OMAP4-VAR-SOM are impacted by this. I don't see any other boards currently using the gpio as an interrupt-controller. I'll apply this into omap-for-v3.10/dt-fixes. Benoit, I'll have only dt stuff in that branch so it should play along with whatever you'll be applying as well. Regards, Tony Cheers Jon [1] comments.gmane.org/gmane.linux.ports.arm.omap/92192 From ed3e66bcd4c0cb3df4cb70e75c45fa4462f70565 Mon Sep 17 00:00:00 2001 From: Jon Hunter jon-hun...@ti.com Date: Wed, 10 Apr 2013 11:44:44 -0500 Subject: [PATCH] ARM: dts: OMAP4: Fix ethernet IRQ for OMAP4 boards Commit ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-cells property) updated the number of interrupt cells required for configuring gpios as interrupts for other devices (such as ethernet controllers). This update allowed the interrupt type (edge, level, etc) to be configured via device-tree (as described in the Documentation/devicetree/bindings/gpio/gpio-omap.txt). This broke ethernet support on the OMAP4 SDP board that defines a gpio as the ethernet IRQ because the interrupt type (level, edge, etc) was not getting configured correctly. This board use the ks8851 ethernet chip which has an active low interrupt. Fix this by defining the gpio interrupt as active-low in the device-tree binding. Please note that the OMAP4-VAR-SOM also uses the same ethernet controller and it is expected it will have the same problem. So the same fix is also applied to this board. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/boot/dts/omap4-sdp.dts |2 +- arch/arm/boot/dts/omap4-var-som.dts |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts index c387bdc..25cbe43 100644 --- a/arch/arm/boot/dts/omap4-sdp.dts +++ b/arch/arm/boot/dts/omap4-sdp.dts @@ -363,7 +363,7 @@ spi-max-frequency = 2400; reg = 0; interrupt-parent = gpio2; - interrupts = 2; /* gpio line 34 */ + interrupts = 2 8; /* gpio line 34, low triggered */ vdd-supply = vdd_eth; }; }; diff --git a/arch/arm/boot/dts/omap4-var-som.dts b/arch/arm/boot/dts/omap4-var-som.dts index 222a413..7e04103 100644 --- a/arch/arm/boot/dts/omap4-var-som.dts +++ b/arch/arm/boot/dts/omap4-var-som.dts @@ -68,7 +68,7 @@ spi-max-frequency = 2400; reg = 0; interrupt-parent = gpio6; - interrupts = 11; /* gpio line 171 */ + interrupts = 11 8; /* gpio line 171, low triggered */ vdd-supply = vdd_eth; }; }; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4+: omap2plus_defconfig: Enable audio via TWL6040 as module
* Jyri Sarha o...@iki.fi [130412 05:19]: On Wed, 10 Apr 2013 11:08:00 +0200, Peter Ujfalusi peter.ujfal...@ti.com wrote: Boards supported upstream all use TWL6040 as audio codec, enable the common ASoC machine driver by default for them. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Jyri Sarha jsa...@ti.com Brings a working PCM for TWL6040 trough McPDM legacy port on top of 8.3-rc3 for my Blaze and Panda. Thanks applying into omap-for-v3.10/fixes. Regards, Tony --- arch/arm/configs/omap2plus_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index bd07864..eea501c 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -152,6 +152,7 @@ CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65910=y +CONFIG_TWL6040_CORE=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y @@ -194,6 +195,7 @@ CONFIG_SND_USB_AUDIO=m CONFIG_SND_SOC=m CONFIG_SND_OMAP_SOC=m CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m +CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_DEBUG=y -- 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: OMAP3: Beagle: Fix USB Host on beagle xM Ax/Bx
* Roger Quadros rog...@ti.com [130415 04:25]:
On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.
Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.
Signed-off-by: Roger Quadros rog...@ti.com
Thanks applying into omap-for-v3.10/fixes.
Regards,
Tony
---
arch/arm/mach-omap2/board-omap3beagle.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 5382215..21136b2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -112,13 +112,13 @@ static u8 omap3_beagle_version;
*/
static struct {
int mmc1_gpio_wp;
- int usb_pwr_level;
+ bool usb_pwr_level; /* 0 - Active Low, 1 - Active High */
int dvi_pd_gpio;
int usr_button_gpio;
int mmc_caps;
} beagle_config = {
.mmc1_gpio_wp = -EINVAL,
- .usb_pwr_level = GPIOF_OUT_INIT_LOW,
+ .usb_pwr_level = 0,
.dvi_pd_gpio = -EINVAL,
.usr_button_gpio = 4,
.mmc_caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
@@ -178,7 +178,7 @@ static void __init omap3_beagle_init_rev(void)
case 0:
printk(KERN_INFO OMAP3 Beagle Rev: xM Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
- beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ beagle_config.usb_pwr_level = 1;
beagle_config.mmc_caps = ~MMC_CAP_8_BIT_DATA;
break;
case 2:
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest build results - errors/warnings - lots of them
* NeilBrown ne...@suse.de [130505 19:45]:
On Thu, 2 May 2013 08:38:34 -0700 Tony Lindgren t...@atomide.com wrote:
drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of
'regulator_enable', declared with attribute warn_unused_result
Neil, care to provide a fix for this? It's from your commit ab37813
(twl4030_charger: Allow charger to control the regulator that feeds it).
This the sort of thing that might be appropriate?
Thanks looks good to me. Care to send it to the appropriate
mailing lists and maintainers for drivers/power?
Regards,
Tony
From: NeilBrown ne...@suse.de
Date: Mon, 6 May 2013 12:35:59 +1000
Subject: [PATCH] twl4030_charger: don't ignore regulator_enable()
regulator_enable() doesn't like being ignored. If it does fail there
is nothing we can do except not set usb_enabled (which is necessary
else a subsequent regulator_disable() will be unbalanced).
We cannot usefully return an error here as errors from
twl4030_charger_enable_usb() are ignored.
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index bed4581..8b0ec70 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -189,8 +189,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
/* Need to keep regulator on */
if (!bci-usb_enabled) {
- regulator_enable(bci-usb_reg);
- bci-usb_enabled = 1;
+ if (regulator_enable(bci-usb_reg) == 0)
+ bci-usb_enabled = 1;
}
/* forcing the field BCIAUTOUSB (BOOT_BCI[1]) to 1 */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices
* Aaro Koskinen aaro.koski...@iki.fi [130501 10:06]: Commit 9fdca9df (spi: omap2-mcspi: convert to module_platform_driver) broke the SPI display/panel driver probe on RX-51/N900. The exact cause is not fully understood, but it seems to be related to the probe order. SPI communication to the panel driver (spi1.2) fails unless the touchscreen (spi1.0) has been probed/initialized before. When the omap2-mcspi driver was converted to a platform driver, it resulted in that the devices are probed immediately after the board registers them in the order they are listed in the board file. Fix the issue by moving the touchscreen before the panel in the SPI device list. The patch fixes the following failure: [1.260955] acx565akm spi1.2: invalid display ID [1.265899] panel-acx565akm display0: acx_panel_probe panel detect error [1.273071] omapdss CORE error: driver probe failed: -19 Thanks for updating the description, applying 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: [PATCH] ARM: omap2: gpmc: fix compilation warning
* Vincent Stehlé v-ste...@ti.com [130506 04:24]:
Fix the following compilation warning:
arch/arm/mach-omap2/gpmc.c: In function 'gpmc_probe_generic_child':
arch/arm/mach-omap2/gpmc.c:1477:4: warning: format '%x' expects argument of
type 'unsigned int', but argument 4 has type 'resource_size_t' [-Wformat]
Signed-off-by: Vincent Stehlé v-ste...@ti.com
Cc: triv...@kernel.org
---
arch/arm/mach-omap2/gpmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ed946df..3cd7074 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1474,7 +1474,7 @@ static int gpmc_probe_generic_child(struct
platform_device *pdev,
ret = gpmc_cs_remap(cs, res.start);
if (ret 0) {
dev_err(pdev-dev, cannot remap GPMC CS %d to 0x%x\n,
- cs, res.start);
+ cs, (unsigned)res.start);
goto err;
}
You should just change the format for dev_err instead of the casting.
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
* Jason Cooper ja...@lakedaemon.net [130508 15:04]: On Wed, May 08, 2013 at 12:51:53PM -0700, Tony Lindgren wrote: * Jason Cooper ja...@lakedaemon.net [130508 12:29]: Current Problem: There are several gaps in my understanding of how far along TI's conversion to DT is. Should I be doing a separate board file for initializing the legacy items? I was hoping to do it all with DT. Sorry forgot to reply to this.. No seprate board file should be needed, some devices may still need to be initialized with pdata based on the compatible flag. ti,hwmod, right? Yes.. see mach-omap2/devices.c for the list that's still not initialized via DT. Obviously, I don't expect anybody to run out and buy one of these, take it apart, and try to boot this code. But if the omap guys could take a look at this and give me a few pointers, I'd appreciate it. I'm kind of spinning my wheels at the moment. Primarily, I'd like to get nand and usb working, so that I can read/write, mount a rootfs and do better testing. The USB should be doable with device tree. At least both echi and musb are working properly on pandaboard. I think people have been using NAND with the gpmc DT patches, but I don't know the current status for sure. I'll try your suggestion in your other email for ToT and see if I can get gpmc going. Is the hard drive on the EHCI bus or how is it connected to omap? via ehci. They brutalized the tps driver to detect if the goflex cable was attached or not. Once I get something stable, I'll probably write a separate driver for that code. Or, push it out to userspace. OK. I guess you need to disconnect the drive from EHCI if the goflex is attached to avoid disk corruption? 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] ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support
On Wed, Apr 17, 2013 at 6:32 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
The IGEPv2 board has an SMSC LAN9221i ethernet chip connected to
the OMAP3 processor though the General-Purpose Memory Controller.
This patch adds a device node for the ethernet chip as a GPMC child
and all its dependencies (regulators, GPIO and pin muxs).
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
arch/arm/boot/dts/omap3-igep.dtsi|6
arch/arm/boot/dts/omap3-igep0020.dts | 53
++
2 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index f8fe3b7..d5cd504 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -62,6 +62,12 @@
0x126 0x0100/* sdmmc1_dat7.sdmmc1_dat7 INPUT |
MODE 0 */
;
};
+
+ smsc911x_pins: pinmux_smsc911x_pins {
+ pinctrl-single,pins =
+0x1a2 0x0104/* mcspi1_cs2.gpio_176 INPUT | MODE4
*/
+ ;
+ };
};
i2c1 {
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index e2b9849..4bac32e 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -40,6 +40,18 @@
gpios = twl_gpio 19 1;
};
};
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
};
i2c3 {
@@ -54,3 +66,44 @@
reg = 0x50;
};
};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x100;
+ ethernet@5,0 {
+ pinctrl-names = default;
+ pinctrl-0 = smsc911x_pins;
+ compatible = smsc,lan9221, smsc,lan9115;
+ reg = 5 0 0xff;
+ bank-width = 2;
+
+ gpmc,mux-add-data;
+ gpmc,cs-on-ns = 0;
+ gpmc,cs-rd-off-ns = 186;
+ gpmc,cs-wr-off-ns = 186;
+ gpmc,adv-on-ns = 12;
+ gpmc,adv-rd-off-ns = 48;
+ gpmc,adv-wr-off-ns = 48;
+ gpmc,oe-on-ns = 54;
+ gpmc,oe-off-ns = 168;
+ gpmc,we-on-ns = 54;
+ gpmc,we-off-ns = 168;
+ gpmc,rd-cycle-ns = 186;
+ gpmc,wr-cycle-ns = 186;
+ gpmc,access-ns = 114;
+ gpmc,page-burst-access-ns = 6;
+ gpmc,bus-turnaround-ns = 12;
+ gpmc,cycle2cycle-delay-ns = 18;
+ gpmc,wr-data-mux-bus-ns = 90;
+ gpmc,wr-access-ns = 186;
+ gpmc,cycle2cycle-samecsen;
+ gpmc,cycle2cycle-diffcsen;
+
+ interrupt-parent = gpio6;
+ interrupts = 16 8;
+ vmmc-supply = vddvario;
+ vmmc_aux-supply = vdd33a;
+ reg-io-width = 4;
+
+ smsc,save-mac-address;
+ };
+};
--
1.7.7.6
--
Hi Benoit,
Any comments on this patch?
Thanks a lot and best regards,
Javier
--
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 05/07/2013 08:54 PM, 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? If DT core can do above things, can we delete dma_mask assignment at every driver? Perhaps. However, such a change has a much larger potential for regressions. I would suggest going with the current patch for 3.10 and any later backports in order to reduce risk. We can revisit better cleanup for later kernels. -- 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: OMAP1: DMA: fix error handling in omap1_system_dma_init()
* Wei Yongjun weiyj...@gmail.com [130426 01:36]:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing iounmap() before return from omap1_system_dma_init()
in the error handling case.
Also removed platform_device_del() on add resources error case which
cause dup device delete.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
no compile test.
Seems to work, applying into omap-for-v3.10/fixes thanks.
Tony
arch/arm/mach-omap1/dma.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 1a4e887..68ab858 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -301,7 +301,7 @@ static int __init omap1_system_dma_init(void)
if (ret) {
dev_err(pdev-dev, %s: Unable to add resources for %s%d\n,
__func__, pdev-name, pdev-id);
- goto exit_device_put;
+ goto exit_iounmap;
}
p = kzalloc(sizeof(struct omap_system_dma_plat_info), GFP_KERNEL);
@@ -309,7 +309,7 @@ static int __init omap1_system_dma_init(void)
dev_err(pdev-dev, %s: Unable to allocate 'p' for %s\n,
__func__, pdev-name);
ret = -ENOMEM;
- goto exit_device_del;
+ goto exit_iounmap;
}
d = kzalloc(sizeof(struct omap_dma_dev_attr), GFP_KERNEL);
@@ -402,8 +402,8 @@ exit_release_d:
kfree(d);
exit_release_p:
kfree(p);
-exit_device_del:
- platform_device_del(pdev);
+exit_iounmap:
+ iounmap(dma_base);
exit_device_put:
platform_device_put(pdev);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: OMAP36xx/OMAP4460 Fix CPU OPP voltages
* Nishanth Menon n...@ti.com [130426 10:44]: Hi, It seems that I have not been paying close attention to actual voltage value seen on scope to map it back to verify the validity of the voltage value. Even though I did verify[1] that voltage did scale to values in DT entries, the values in the case of 3630 and 4460 were lower than what the spec voltage was as per opp_data files. This series is based off Benoit's tree here: http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts Commit ID's in the patches to indicate regressions are from there as well. Would be good to have this fix merged to 3.10 dts entries. I have cross verified that OMAP3430,3630,4430 and 4460 entries now match that of corresponding opp*_data.c My sincere apologies on the oversight. Nishanth Menon (2): ARM: dts: OMAP36xx: Fix CPU OPP voltages ARM: dts: OMAP4460: Fix CPU OPP voltages arch/arm/boot/dts/omap36xx.dtsi |6 +++--- arch/arm/boot/dts/omap4460.dtsi |6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) [1] http://marc.info/?l=linux-arm-kernelm=136580742724210w=2 Thanks applying both into omap-for-v3.10/dt-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: [PATCH] ARM: OMAP2+: omap_device: use late_initcall_sync
* Kevin Hilman khil...@linaro.org [130507 14:44]: If DEBUG_LL and earlyprintk are enabled, and omap-serial.c is compiled as a module, the kernel boot hangs early as the clocks for serial port are cut while earlyprintk still uses the port. The problem is a race between the late_initcall for omap_device (which idles devices that have no drivers) and the late_initcall in kernel/printk.c which turns off the earlyconsole. Any printks that happen between this omap_device late initcall and the earlyconsole late initcall will crash when accessing the UART. The fix is to ensure the omap_device initcall happens after the earlyconsole initcall. Reported-by: Tony Lindgren t...@atomide.com Signed-off-by: Kevin Hilman khil...@linaro.org Thanks applying into omap-for-v3.10/fixes. Tony --- Based on v3.9-rc8 arch/arm/mach-omap2/omap_device.c | 2 +- arch/arm/mach-omap2/soc.h | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c index 381be7a..2d20d69 100644 --- a/arch/arm/mach-omap2/omap_device.c +++ b/arch/arm/mach-omap2/omap_device.c @@ -879,4 +879,4 @@ static int __init omap_device_late_init(void) bus_for_each_dev(platform_bus_type, NULL, NULL, omap_device_late_idle); return 0; } -omap_late_initcall(omap_device_late_init); +omap_late_initcall_sync(omap_device_late_init); diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index c62116b..de88611 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -494,6 +494,7 @@ level(__##fn); #define omap_subsys_initcall(fn) omap_initcall(subsys_initcall, fn) #define omap_device_initcall(fn) omap_initcall(device_initcall, fn) #define omap_late_initcall(fn) omap_initcall(late_initcall, fn) +#define omap_late_initcall_sync(fn) omap_initcall(late_initcall_sync, fn) #endif /* __ASSEMBLY__ */ -- 1.8.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] omap: mux: add AM/DM37x gpios
* Christoph Fritz chf.fr...@googlemail.com [130413 10:35]: This patch adds GPIO pins found on AM/DM37x. Thanks applying into omap-for-v3.10/fixes. Tony Signed-off-by: Christoph Fritz chf.fr...@googlemail.com --- arch/arm/mach-omap2/mux34xx.h |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/mux34xx.h b/arch/arm/mach-omap2/mux34xx.h index 6543ebf..3f26d29 100644 --- a/arch/arm/mach-omap2/mux34xx.h +++ b/arch/arm/mach-omap2/mux34xx.h @@ -393,6 +393,10 @@ #define OMAP3_CONTROL_PADCONF_SAD2D_SWAKEUP_OFFSET 0xa1c #define OMAP3_CONTROL_PADCONF_JTAG_RTCK_OFFSET 0xa1e #define OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET0xa20 +#define OMAP3_CONTROL_PADCONF_GPIO_127 0xa24 +#define OMAP3_CONTROL_PADCONF_GPIO_126 0xa26 +#define OMAP3_CONTROL_PADCONF_GPIO_128 0xa28 +#define OMAP3_CONTROL_PADCONF_GPIO_129 0xa2a #define OMAP3_CONTROL_PADCONF_MUX_SIZE \ - (OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET + 0x2) + (OMAP3_CONTROL_PADCONF_GPIO_129 + 0x2) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2: AM33XX: id: Add support for new AM335x PG2.1 Si
* Vaibhav Hiremath hvaib...@ti.com [130504 11:29]: Add support for chip id detection of AM335x PG2.1 Silicon. Currently omap3xxx_check_revision() detects PG1.0 and PG2.0 only, this patch extends it by adding PG2.1 Si support. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Thanks applying into omap-for-v3.10/fixes. Tony --- arch/arm/mach-omap2/id.c |8 ++-- arch/arm/mach-omap2/soc.h |1 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 0f4c18e..9bc5a18 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -419,11 +419,15 @@ void __init omap3xxx_check_revision(void) cpu_rev = 1.0; break; case 1: - /* FALLTHROUGH */ - default: omap_revision = AM335X_REV_ES2_0; cpu_rev = 2.0; break; + case 2: + /* FALLTHROUGH */ + default: + omap_revision = AM335X_REV_ES2_1; + cpu_rev = 2.1; + break; } break; case 0xb8f2: diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index 18fdeeb..ccef2dd 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -396,6 +396,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define AM335X_CLASS 0x33500033 #define AM335X_REV_ES1_0 AM335X_CLASS #define AM335X_REV_ES2_0 (AM335X_CLASS | (0x1 8)) +#define AM335X_REV_ES2_1 (AM335X_CLASS | (0x2 8)) #define OMAP443X_CLASS 0x44300044 #define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 8)) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] ARM:dts:omap4-panda:Update the LED support for the panda DTS
* 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
--
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: OMAP2+: omap-usb-host: clean up pin mux setup code
* Roger Quadros rog...@ti.com [130422 03:02]: The USB host pins are named quite differently between OMAP3 and OMAP4+ SoCs. To make this managable in code, we create a pin mapping table (pin_names) that maps pin function to pin name. This pin mapping table is populated at runtime based on a pin name template. Templates are provided for OMAP3 and 4 SoCs. The setup_io_mux() function uses the pin mapping table to setup the pin mux. The resulting code is a lot more clean, manageable and scalable. I'm planning to drop all the omap4 pdata soonish. Will post some patches after -rc1 to do that. Do you still need this patch considering that? 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: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
* Sekhar Nori nsek...@ti.com [130429 22:11]:
On 4/29/2013 1:25 PM, Gupta, Pekon wrote:
From: avinash philip avinashphi...@ti.com
NAND flash connected in am335x-evm on GPMC controller. This patch adds
device tree node in am3355-evm with GPMC contoller timing for NAND flash
interface, NAND partition table, ECC scheme, elm handle id.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Tested-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 98
+-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 0423298..1c2fd89 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,8 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0
+ nandflash_pins_s0;
Why add this to the board level fallback (called pinctrl hogs, I think)?
This can be part of nand node you added below so that the pinctrl will
take effect when nand gets probed instead of all the time.
Yes we should have all the pinctrl entries under the related drivers.
This makes it easy remux pins during runtime if needed, and also
allows unloading pinctrl-single.ko for development.
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: [GIT PULL] ARM: OMAP2+: GPMC fixes for v3.10
* Jon Hunter jon-hun...@ti.com [130430 06:59]: The following changes since commit aecb65a34a780cd07fbaa652cc5d640f13f3ed5f: Merge branch 'omap-gpmc-for-v3.10-take2' of git://github.com/jonhunter/linux into omap-for-v3.10/gpmc (2013-04-04 11:22:33 -0700) are available in the git repository at: git://github.com/jonhunter/linux.git omap-gpmc-fixes-for-v3.10 for you to fetch changes up to b327b3627bb428eb7d98f25224532425a673d89e: ARM: OMAP2+: only WARN if a GPMC child probe function fail (2013-04-30 08:43:05 -0500) GPMC fixes for v3.10. Main fix is to only search the GPMC node for GPMC child devices and not the entire device-tree (which was breaking ethernet support on some boards where the GPMC does not interface with the ethernet chip). This branch is based upon Tony's omap-for-v3.10/gpmc branch. Thanks pulling into omap-for-v3.10/fixes. Regards, Tony 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 .../devicetree/bindings/mtd/gpmc-nand.txt | 28 +- Documentation/devicetree/bindings/net/gpmc-eth.txt | 56 ++-- arch/arm/mach-omap2/gpmc.c | 38 + 3 files changed, 54 insertions(+), 68 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: [PATCH v3,2/3] ARM: dts: AM33XX: Add GPMC node
* Gupta, Pekon pe...@ti.com [130502 02:49]:
From: Philip, Avinash avinashphi...@ti.com
Add GPMC data node to AM33XX device tree file.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Acked-by: Peter Korsgaard jac...@sunsite.dk
Signed-off-by: Pekon Gupta pe...@ti.com
Thanks adding into omap-for-v3.10/dt-fixes.
Tony
---
Changes in v2:
- Change number of chip select to 7
arch/arm/boot/dts/am33xx.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 24fc835..1048795 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -407,5 +407,17 @@
ti,hwmods = elm;
status = disabled;
};
+
+ gpmc: gpmc@5000 {
+ compatible = ti,am3352-gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x2000;
+ interrupts = 100;
+ num-cs = 7;
+ num-waitpins = 2;
+ #address-cells = 2;
+ #size-cells = 1;
+ status = disabled;
+ };
};
};
--
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
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:
8-
commit c369d84600bd85b35d83807ce7ba893cea116fb4
Author: Jason Cooper ja...@lakedaemon.net
Date: Thu May 9 00:33:48 2013 +
ARM: omap3: dts: don't assume boards are using twl4030
If a board isn't using twl4030, then dtc will complain about the missing
phandle (which is in twl4030.dtsi). Move the phy declaration to the dts
files.
Signed-off-by: Jason Cooper ja...@lakedaemon.net
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 5a31964..3046d1f 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -122,6 +122,7 @@
usb_otg_hs {
interface-type = 0;
+ usb-phy = usb2_phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 05f51e1..96d1c20 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -68,6 +68,7 @@
usb_otg_hs {
interface-type = 0;
+ usb-phy = usb2_phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index d4a7280..a626c50 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -73,6 +73,7 @@
usb_otg_hs {
interface-type = 0;
+ usb-phy = usb2_phy;
mode = 3;
power = 50;
};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4ad03d9..82a404d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -519,7 +519,6 @@
interrupts = 0 92 0x4, 0 93 0x4;
interrupt-names = mc, dma;
ti,hwmods = usb_otg_hs;
- usb-phy = usb2_phy;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
--
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: fix error return code in omap_hsmmc_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return a negative error code in the init error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/mmc/host/omap_hsmmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6e44025..32d3659 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1948,7 +1948,8 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
}
if (pdata-init != NULL) {
- if (pdata-init(pdev-dev) != 0) {
+ ret = pdata-init(pdev-dev);
+ if (ret != 0) {
dev_err(mmc_dev(host-mmc),
Unable to configure MMC IRQs\n);
goto err_irq_cd_init;
--
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: [v2, 3/3] ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0
+ nandflash_pins_s0;
Why add this to the board level fallback (called pinctrl hogs, I think)?
This can be part of nand node you added below so that the pinctrl will
take effect when nand gets probed instead of all the time.
Yes we should have all the pinctrl entries under the related drivers.
This makes it easy remux pins during runtime if needed, and also
allows unloading pinctrl-single.ko for development.
Yes, accepted. This has been already fixed in v3 of this patch set.
If all fine, then please pull this for next merge..
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046712.html
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046814.html (already
pulled)
http://lists.infradead.org/pipermail/linux-mtd/2013-May/046710.html
with regards, pekon
--
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
