Re: [PATCH 25/28] ASoC: omap: drop owner assignment from platform_drivers
On Sun, Dec 21, 2014 at 10:14:46PM +0100, Wolfram Sang wrote: This platform_driver does not need to set an owner, it will be populated by the driver core. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 2/2] phy: ti-pipe3: Fix SATA across suspend/resume
Hi Roger,
On Friday 19 December 2014 05:35 PM, Roger Quadros wrote:
Failed test case: Boot without SATA drive connected. Suspend/resume
the board and then connect SATA drive. It fails to enumerate.
Due to Errata i783 SATA Lockup After SATA DPLL Unlock/Relock
we can't allow SATA DPLL to be in the unlocked state.
The SATA refclk (sata_ref_clk) is the source of the SATA_DPLL.
Till now this clock was controlled by the AHCI SATA driver and was being
shut off during system suspend (if the SATA drive was not already attached)
causing the SATA DPLL to be unlocked and so causing errata i783.
To prevent sata_ref_clk from being disabled, we move the control of
this clock from the SATA AHCI driver to the SATA PHY driver and prevent
it from being disabled.
This also fixes the issue of SATA not working on OMAP5/DRA7 when
AHCI platform driver is built as a module.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
arch/arm/boot/dts/omap5.dtsi | 4 ++--
drivers/phy/phy-ti-pipe3.c | 53
+++-
3 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 63bf99b..8c35b84 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1090,8 +1090,8 @@
0x4A096800 0x40; /* pll_ctrl */
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_sata;
- clocks = sys_clkin1;
- clock-names = sysclk;
+ clocks = sys_clkin1, sata_ref_clk;
+ clock-names = sysclk, refclk;
#phy-cells = 0;
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b321fdf..bb498e7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -929,8 +929,8 @@
0x4A096800 0x40; /* pll_ctrl */
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_sata;
- clocks = sys_clkin;
- clock-names = sysclk;
+ clocks = sys_clkin, sata_ref_clk;
+ clock-names = sysclk, refclk;
#phy-cells = 0;
};
};
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index e60ff14..e08edd9 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -85,6 +85,7 @@ struct ti_pipe3 {
struct pipe3_dpll_map *dpll_map;
u8 id;
bool enabled;
+ bool refclk_enabled;/* this flag is needed specifically for SATA */
spinlock_t lock;/* serialize clock enable/disable */
};
@@ -333,21 +334,20 @@ static int ti_pipe3_probe(struct platform_device *pdev)
}
}
+ phy-refclk = devm_clk_get(phy-dev, refclk);
+ if (IS_ERR(phy-refclk)) {
+ dev_err(pdev-dev, unable to get refclk\n);
+ return PTR_ERR(phy-refclk);
+ }
This will break older dtbs. AFAIK, newer kernels should be compatible with
older dtbs too. cc'ed devicet...@vger.kernel.org for clarification.
Thanks
Kishon
--
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 00/11] Exynos7: Adding USB 3.0 support
Hi Vivek, On 25/11/14 12:48, Vivek Gautam wrote: On Sat, Nov 22, 2014 at 8:42 PM, Kukjin Kim kg...@kernel.org wrote: On 11/22/14 17:40, Kishon Vijay Abraham I wrote: On Friday 21 November 2014 08:41 PM, Felipe Balbi wrote: ... I took dwc3 driver patches. I took the phy patches. I'll take DT changes once exynos7 is landing into samsung tree :) You too may want to pick the sole clock driver patch in this series for 3.19 ? :-) clk: exynos7: Add required clock tree for USB Please let me know if the merge window is still open on your side so that you can pick this patch. My apologies, it seems I have missed this patch. :/ Feel free to ping me off the list in future if there is no response for more than week. I queued this patch now for 3.20. I'm putting all the exynos7 clk patches on a separate branch which could then be pulled into samsung arm tree for the dependant dts changes. -- Thanks, Sylwester -- 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 2a/3] mmc: core: Allow host driver to provide isr for card-detect interrupts.
On 20 December 2014 at 00:07, NeilBrown ne...@suse.de wrote:
One of the reasons omap_hsmmc doesn't use the slot-gpio library
is that it has some non-standard functionality in the card-detect
interrupt service routine.
To make it possible for omap_hsmmc (and maybe others) to be converted
to use slot-gpio, add 'mmc_gpio_request_cd_isr' which provide an
alternate isr to be register by the slot-gpio code.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/mmc/core/slot-gpio.c | 24 +++-
include/linux/mmc/slot-gpio.h |2 ++
2 files changed, 25 insertions(+), 1 deletion(-)
This and following are the result of splitting the previous
'2/3' into to patches: core and omap_hsmmc as requested.
NeilBrown
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 69bbf2adb329..f56323f5a996 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -23,6 +23,7 @@ struct mmc_gpio {
struct gpio_desc *cd_gpio;
bool override_ro_active_level;
bool override_cd_active_level;
+ irqreturn_t (*cd_gpio_isr)(int irq, void *dev_id);
char *ro_label;
char cd_label[0];
};
@@ -156,8 +157,10 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
irq = -EINVAL;
if (irq = 0) {
+ if (ctx-cd_gpio_isr == NULL)
Please change to:
if (!ctx-cd_gpio_isr)
+ ctx-cd_gpio_isr = mmc_gpio_cd_irqt;
ret = devm_request_threaded_irq(host-class_dev, irq,
- NULL, mmc_gpio_cd_irqt,
+ NULL, ctx-cd_gpio_isr,
IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
ctx-cd_label, host);
if (ret 0)
@@ -171,6 +174,25 @@ void mmc_gpiod_request_cd_irq(struct mmc_host *host)
}
EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
+/* Register an alternate interrupt service routine for
+ * the card-detect GPIO.
+ */
+int mmc_gpio_request_cd_isr(struct mmc_host *host,
+ irqreturn_t (*isr)(int irq, void *dev_id))
+{
+ struct mmc_gpio *ctx;
+ int ret;
+
+ ret = mmc_gpio_alloc(host);
+ if (ret 0)
+ return ret;
+ ctx = host-slot.handler_priv;
+ if (ctx-cd_gpio_isr)
+ return -EBUSY;
+ ctx-cd_gpio_isr = isr;
+ return 0;
+}
I decided to queue those patchsets I recently posted which simplifies
the slot-gpio API. Please re-base this patch on top of my next branch.
Moreover, I actually wonder whether we need to add this API at all.
After my changes, all you need to do from your host driver -probe(),
is to assign your isr routine to ctx-cd_gpio_isr.
+
/**
* mmc_gpio_request_cd - request a gpio for card-detection
* @host: mmc host
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index e56fa24c9322..9e55db60deb0 100644
--- a/include/linux/mmc/slot-gpio.h
+++ b/include/linux/mmc/slot-gpio.h
@@ -28,6 +28,8 @@ int mmc_gpiod_request_cd(struct mmc_host *host, const char
*con_id,
int mmc_gpiod_request_ro(struct mmc_host *host, const char *con_id,
unsigned int idx, bool override_active_level,
unsigned int debounce, bool *gpio_invert);
+int mmc_gpio_request_cd_isr(struct mmc_host *host,
+ irqreturn_t (*isr)(int irq, void *dev_id));
void mmc_gpiod_free_cd(struct mmc_host *host);
void mmc_gpiod_request_cd_irq(struct mmc_host *host);
Kind regards
Uffe
--
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 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
On Tue, Dec 16, 2014 at 10:10:28AM +0800, Sneeker Yeh wrote: Synopsis DesignWare USB3 IP Core integrated with a config-free phy needs special handling during device disconnection to avoid the host controller dying. This quirk makes sure PORT_CSC is cleared after the disable slot command when usb device is disconnected from internal root hub, otherwise, Synopsis core would fall into a state that cannot use any endpoint command. Consequently, device disconnection procedure might not be finished because sometimes endpoint need to be stop by endpoint stop command issuing. Symptom usually happens when disconnected device is keyboard, mouse, and hub. you need to point us to the synopsys STARS ticket number. That's the only way to reference this specific quirk. Add it to a comment somewhere. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer
Hi,
On Tue, Dec 16, 2014 at 10:10:27AM +0800, Sneeker Yeh wrote:
This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
.../devicetree/bindings/usb/fujitsu-dwc3.txt | 25 +++
drivers/usb/dwc3/Kconfig | 11 ++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-mb86s70.c| 194
4 files changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c
diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
new file mode 100644
index 000..df77f91
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
@@ -0,0 +1,25 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x DWC3 GLUE
+ - compatible : Should be fujitsu,mb86s70-dwc3
+ - clocks: from common clock binding, handle to usb clock.
+ - clock-names: from common clock binding.
+ - #address-cells, #size-cells : Must be present if the device has sub-nodes
+ - ranges: the child address space are mapped 1:1 onto the parent address
space
+ - #stream-id-cells : handle to use arm,mmu-400 ARM IOMMU driver
+
+Sub-nodes:
+The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+usb3host: mb86s70_usb3host {
+ compatible = fujitsu,mb86s70-dwc3;
+ clocks = clk_alw_1_1;
+ clock-names = bus_clk;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ #stream-id-cells = 0;
+};
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 58b5b2c..3390d42 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
say 'Y' or 'M' if you have one such device.
+config USB_DWC3_MB86S70
+ tristate MB86S70 Designware USB3 Platform code
+ default USB_DWC3
+ help
+ MB86S7X SOC ship with DesignWare Core USB3 IP inside,
+ this implementation also integrated Fujitsu USB PHY inside
+ this Core USB3 IP.
+
+ say 'Y' or 'M' if you have one such device.
+
+
config USB_DWC3_PCI
tristate PCIe-based Platforms
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..05d1de2 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE) += dwc3-keystone.o
obj-$(CONFIG_USB_DWC3_QCOM) += dwc3-qcom.o
obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
+obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c b/drivers/usb/dwc3/dwc3-mb86s70.c
new file mode 100644
index 000..241c5bd
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-mb86s70.c
@@ -0,0 +1,194 @@
+/**
+ * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * Author: Alice Chan alice.c...@tw.fujitsu.com
+ * based on dwc3-exynos.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#include linux/interrupt.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+#include linux/clk.h
+
+struct dwc3_mb86s70 {
+ struct device *dev;
+ struct clk **clk_table;
please align these.
+};
+
+/* return 0 means successful */
this comment is unnecessary :-)
+static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
+{
+ int ret, i;
+ struct clk *clk;
+
+ if (!on)
+ goto clock_off;
+
+ for (i = 0;; i++) {
+ clk = of_clk_get(dev-of_node, i);
you could count the number of properties first, then allocate clk_table
to the exact size.
+ if (IS_ERR(clk))
+ break;
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(dev, failed to enable clock[%d]\n, i);
+ goto clock_off;
+ }
+ }
+
+ return 0;
+
+clock_off:
+ for (i = 0;; i++) {
+ clk = of_clk_get(dev-of_node, i);
+ if (IS_ERR(clk))
+
Re: [PATCH 1/4] usb: dwc3: gadget: Fix TRB preparation during SG
On Fri, Dec 19, 2014 at 12:40:15PM +0530, Amit Virdi wrote:
When scatter gather is used, multiple TRBs are prepared from one DWC3 request.
Hence, we must set the 'last' flag when the SG is last as well as the TRB is
last. The current implementation uses list_is_last to check if the
dwc3_request
is the last request in the request_list.
This doesn't work when SG is used. This is because, when it is the last
request,
the first TRB preparation (in dwc3_prepare_one_trb) modifies the dwc3_request
list's next and prev pointers while moving the URB to req_queued.
Hence, list_is_last always return false no matter what. The correct way is not
to access the modified pointers of dwc3_request but to use list_empty macro
instead.
Fixes: e5ba5ec833aa4a76980b512d6a6779643516b850 (usb: dwc3: gadget: fix
scatter
gather implementation
Signed-off-by: Amit Virdi amit.vi...@st.com
you need to Cc stable here and make sure you point out which kernel
versions this should be backported to. Looks like this sould be:
Cc: sta...@vger.kernel.org # v3.9+
Also, how have you tested this ? I need a test case to make sure it
fails here and this patch really fixes the problem.
---
drivers/usb/dwc3/gadget.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f03b136ecfce..0eec2e917994 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -882,8 +882,7 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
if (i == (request-num_mapped_sgs - 1) ||
sg_is_last(s)) {
- if (list_is_last(req-list,
- dep-request_list))
+ if (list_empty(dep-request_list))
last_one = true;
chain = false;
}
--
1.8.0
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
On Fri, Dec 19, 2014 at 12:40:16PM +0530, Amit Virdi wrote:
When SG is used, there are two loops iterating to prepare TRBs:
- Outer loop over the request_list
- Inner loop over the SG list
The driver must stop preparing TRBs when the max TRBs have been prepared. The
code was missing break to get out of the outer loop.
Signed-off-by: Amit Virdi amit.vi...@st.com
which bug is this fixing ? Which kernels are affected ? This need to be
backported to which kernel ? Which commit introduced this bug ? How can
I validate this to be a valid fix ?
---
drivers/usb/dwc3/gadget.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0eec2e917994..8f65ab3a3b92 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -900,6 +900,9 @@ static void dwc3_prepare_trbs(struct dwc3_ep *dep, bool
starting)
if (last_one)
break;
}
+
+ if (last_one)
+ break;
} else {
dma = req-request.dma;
length = req-request.length;
--
1.8.0
--
balbi
signature.asc
Description: Digital signature
[PATCH 3.19-rc1 v14 5/8] arm: omap1: Migrate debug_ll macros to use 8250.S
The omap1's debug-macro.S is similar to the generic 8250 code. Compared to the 8520 code the omap1 macro automatically determines what UART to use based on breadcrumbs left by the bootloader and automatically copes with the eccentric register layout on OMAP7XX. This patch drops both these features and relies instead on the generic 8250 macros: 1. Dropping support for the bootloader breadcrumbs is identical to the way the migration was handled for OMAP2 (see 808b7e07464d...). 2. Support for OMAP7XX still exists but it must be configured by hand (DEBUG_OMAP7XXUART1/2/3) rather than handled at runtime. Signed-off-by: Daniel Thompson daniel.thomp...@linaro.org Cc: Russell King li...@arm.linux.org.uk Cc: Arnd Bergmann arnd.bergm...@linaro.org Cc: linux-omap@vger.kernel.org Tested-by: Aaro Koskinen aaro.koski...@iki.fi Acked-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig.debug | 57 +- arch/arm/mach-omap1/include/mach/debug-macro.S | 101 - 2 files changed, 56 insertions(+), 102 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/debug-macro.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index eba36e35bad2..ec25d746b4dd 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -527,6 +527,30 @@ choice Say Y here if you want kernel low-level debugging support on TI-NSPIRE CX models. + config DEBUG_OMAP1UART1 + bool Kernel low-level debugging via OMAP1 UART1 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART1. + + config DEBUG_OMAP1UART2 + bool Kernel low-level debugging via OMAP1 UART2 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART2. + + config DEBUG_OMAP1UART3 + bool Kernel low-level debugging via OMAP1 UART3 + depends on ARCH_OMAP1 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP1 based platforms (except OMAP730) on the UART3. + config DEBUG_OMAP2UART1 bool OMAP2/3/4 UART1 (omap2/3 sdp boards and some omap3 boards) depends on ARCH_OMAP2PLUS @@ -569,6 +593,30 @@ choice depends on ARCH_OMAP2PLUS select DEBUG_OMAP2PLUS_UART + config DEBUG_OMAP7XXUART1 + bool Kernel low-level debugging via OMAP730 UART1 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART1. + + config DEBUG_OMAP7XXUART2 + bool Kernel low-level debugging via OMAP730 UART2 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART2. + + config DEBUG_OMAP7XXUART3 + bool Kernel low-level debugging via OMAP730 UART3 + depends on ARCH_OMAP730 + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on OMAP730 based platforms on the UART3. + config DEBUG_TI81XXUART1 bool Kernel low-level debugging messages via TI81XX UART1 (ti8148evm) depends on ARCH_OMAP2PLUS @@ -1308,6 +1356,9 @@ config DEBUG_UART_PHYS default 0xffe4 if DEBUG_RCAR_GEN1_SCIF0 default 0xffe42000 if DEBUG_RCAR_GEN1_SCIF2 default 0xfff36000 if DEBUG_HIGHBANK_UART + default 0xfffb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfffb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfffb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfffe8600 if DEBUG_UART_BCM63XX default 0xf700 if ARCH_IOP33X depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ @@ -1390,6 +1441,9 @@ config DEBUG_UART_VIRT default 0xfef0 if ARCH_IXP4XX !CPU_BIG_ENDIAN default 0xfef3 if ARCH_IXP4XX CPU_BIG_ENDIAN default 0xfef36000 if DEBUG_HIGHBANK_UART + default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1 + default 0xfefb0800 if DEBUG_OMAP1UART2 || DEBUG_OMAP7XXUART2 + default 0xfefb9800 if DEBUG_OMAP1UART3 || DEBUG_OMAP7XXUART3 default 0xfefff700 if ARCH_IOP33X default 0xff003000 if
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote: On 2014-12-11 10:29, Russell King - ARM Linux wrote: On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: I assume that now it won't be possible to get l2c patches back to -next, so I will resend them (again...) with the omap related fix. What, you mean you don't know the fundamental rules of kernel development? No one should ever dump any new code into linux-next during a merge window which is not a fix for a regression or a bug fix, period. Linus has in the past taken a snapshot of linux-next at the beginning of a merge window, and then threatened to refuse to merge anything that wasn't in his local snapshot, or which doesn't qualify as the above. So no, it won't be possible, because I play by the community rules when it comes to what gets merged and at what time in the cycle. I know the rules. It was just my whining, that it is yet another release cycle that got missed. It is really disappointing, that those patches have been floating for months and noone found issues related to different order of initialization. It took way to long to get them scheduled for testing in -next. Right, so - we're now at -rc1, and we should see about queuing this up sooner rather than later - in its fixed form. From what I can see, there's been little progress on the OMAP problem. Nishanth - can we push OMAP over to using the generic DT L2C initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ? From what I can see, in the DT case, the only thing which is used there is the ioremap() to provide omap4_get_l2cache_base() with something to return. Everything else - the initialisation of the l2c_write_sec pointer, and the aux mask and values - can be specified via the machine_desc struct. That only leaves the non-DT stuff to worry about this, and from what I understand, that's going to be removed soon. If we're going to keep the non-DT stuff, we should implement a new machine_desc hook for it instead of hijacking one of the existing callbacks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
* Russell King - ARM Linux li...@arm.linux.org.uk [141222 09:06]: On Thu, Dec 11, 2014 at 11:42:48AM +0100, Marek Szyprowski wrote: On 2014-12-11 10:29, Russell King - ARM Linux wrote: On Wed, Dec 10, 2014 at 10:42:33AM +0100, Marek Szyprowski wrote: I assume that now it won't be possible to get l2c patches back to -next, so I will resend them (again...) with the omap related fix. What, you mean you don't know the fundamental rules of kernel development? No one should ever dump any new code into linux-next during a merge window which is not a fix for a regression or a bug fix, period. Linus has in the past taken a snapshot of linux-next at the beginning of a merge window, and then threatened to refuse to merge anything that wasn't in his local snapshot, or which doesn't qualify as the above. So no, it won't be possible, because I play by the community rules when it comes to what gets merged and at what time in the cycle. I know the rules. It was just my whining, that it is yet another release cycle that got missed. It is really disappointing, that those patches have been floating for months and noone found issues related to different order of initialization. It took way to long to get them scheduled for testing in -next. Right, so - we're now at -rc1, and we should see about queuing this up sooner rather than later - in its fixed form. From what I can see, there's been little progress on the OMAP problem. Nishanth - can we push OMAP over to using the generic DT L2C initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ? From what I can see, in the DT case, the only thing which is used there is the ioremap() to provide omap4_get_l2cache_base() with something to return. Everything else - the initialisation of the l2c_write_sec pointer, and the aux mask and values - can be specified via the machine_desc struct. That only leaves the non-DT stuff to worry about this, and from what I understand, that's going to be removed soon. If we're going to keep the non-DT stuff, we should implement a new machine_desc hook for it instead of hijacking one of the existing callbacks. For omap4 and later we've been DT only for about 1.5 years now so that should not be an issue here. 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: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On Mon, Dec 22, 2014 at 11:04 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Nishanth - can we push OMAP over to using the generic DT L2C initialisation (the one from init_IRQ in arch/arm/kernel/irq.c) and kill the SoC specific stuff in arch/arm/mach-omap2/omap4-common.c ? From what I can see, in the DT case, the only thing which is used there is the ioremap() to provide omap4_get_l2cache_base() with something to return. Everything else - the initialisation of the l2c_write_sec pointer, and the aux mask and values - can be specified via the machine_desc struct. I think this is what Marek proposed. I had requested for patches to be reposted with linux-omap in CC so that we can test and provide feedback. That only leaves the non-DT stuff to worry about this, and from what I understand, that's going to be removed soon. If we're going to keep the non-DT stuff, we should implement a new machine_desc hook for it instead of hijacking one of the existing callbacks. none of the PL310 support requires non-DT. PL310 is needed for OMAP4 and AM437x both of which are DT only. -- --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: OMAP4 (next-20141204) (bisect to: ARM: 8208/1: l2c: Refactor the driver to use commit-like)
On Mon, Dec 22, 2014 at 11:12:42AM -0600, Nishanth Menon wrote: On Mon, Dec 22, 2014 at 11:04 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: That only leaves the non-DT stuff to worry about this, and from what I understand, that's going to be removed soon. If we're going to keep the non-DT stuff, we should implement a new machine_desc hook for it instead of hijacking one of the existing callbacks. none of the PL310 support requires non-DT. PL310 is needed for OMAP4 and AM437x both of which are DT only. Right, so the simple answer for the time being is to kill most of omap_l2_cache_init(), leaving just the ioremap() behind. Everything else can go into the machine_desc structures, and OMAP4 and AM437x can both benefit from initialising the L2 cache at exactly the same point as most other platforms. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
By converting a few drivers to modules because they won't be needed during boot anyways, we can shave off about 700KiB of text. Note that while at that, and after discussions with Tony Lindgren, a few extra drivers were either removed because they weren't needed, or added because they're useful for debugging/testing. Below is output of size for pre and post vmlinux binaries: textdata bss dec hex filename 8342992 757876 8411840 1751270810b3904 vmlinux-post-patch 9069110 800316 8419072 182884981170f72 vmlinux-pre-patch Signed-off-by: Felipe Balbi ba...@ti.com --- arch/arm/configs/omap2plus_defconfig | 121 ++- 1 file changed, 75 insertions(+), 46 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c2c3a85..a1dc3ed 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -13,7 +13,6 @@ CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_CGROUP_CPUACCT=y -CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_KMEM=y @@ -68,7 +67,6 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y -CONFIG_GENERIC_CPUFREQ_CPU0=y # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set CONFIG_CPU_IDLE=y CONFIG_BINFMT_MISC=y @@ -103,7 +101,7 @@ CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_DMA_CMA=y CONFIG_OMAP_OCP2SCP=y -CONFIG_CONNECTOR=y +CONFIG_CONNECTOR=m CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y @@ -122,14 +120,13 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SENSORS_TSL2550=m CONFIG_BMP085_I2C=m -CONFIG_SENSORS_LIS3_I2C=m CONFIG_SRAM=y +CONFIG_SENSORS_LIS3_I2C=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_SCAN_ASYNC=y -CONFIG_ATA=y -CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_MD=y +CONFIG_ATA=m +CONFIG_SATA_AHCI_PLATFORM=m CONFIG_NETDEVICES=y # CONFIG_NET_VENDOR_ARC is not set # CONFIG_NET_CADENCE is not set @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y # CONFIG_NET_VENDOR_WIZNET is not set CONFIG_AT803X_PHY=y CONFIG_SMSC_PHY=y -CONFIG_USB_USBNET=y -CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_USBNET=m +CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y @@ -172,18 +169,22 @@ CONFIG_WLCORE_SDIO=m CONFIG_MWIFIEX=m CONFIG_MWIFIEX_SDIO=m CONFIG_MWIFIEX_USB=m -CONFIG_INPUT_JOYDEV=y -CONFIG_INPUT_EVDEV=y -CONFIG_KEYBOARD_GPIO=y +CONFIG_INPUT_JOYDEV=m +CONFIG_INPUT_EVDEV=m +CONFIG_KEYBOARD_ATKBD=m +CONFIG_KEYBOARD_GPIO=m CONFIG_KEYBOARD_MATRIX=m -CONFIG_KEYBOARD_TWL4030=y +CONFIG_KEYBOARD_OMAP4=m +CONFIG_KEYBOARD_TWL4030=m +# CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=m CONFIG_TOUCHSCREEN_EDT_FT5X06=m CONFIG_TOUCHSCREEN_TSC2005=m CONFIG_TOUCHSCREEN_TSC2007=m CONFIG_INPUT_MISC=y -CONFIG_INPUT_TWL4030_PWRBUTTON=y +CONFIG_INPUT_TWL4030_PWRBUTTON=m +CONFIG_SERIO=m # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y @@ -196,15 +197,16 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y -CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y +CONFIG_SPI_TI_QSPI=m CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y -CONFIG_GPIO_TWL4030=y -CONFIG_W1=y +CONFIG_GPIO_TWL4030=m +CONFIG_W1=m +CONFIG_HDQ_MASTER_OMAP=m CONFIG_BATTERY_BQ27x00=m CONFIG_CHARGER_ISP1704=m CONFIG_CHARGER_TWL4030=m @@ -213,20 +215,21 @@ CONFIG_CHARGER_BQ24190=m CONFIG_CHARGER_BQ24735=m CONFIG_POWER_RESET=y CONFIG_POWER_AVS=y +CONFIG_HWMON=m CONFIG_SENSORS_LM75=m -CONFIG_THERMAL=y +CONFIG_SENSORS_TMP102=m +CONFIG_THERMAL=m CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_USER_SPACE=y CONFIG_CPU_THERMAL=y -CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_SOC_THERMAL=m CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y CONFIG_WATCHDOG=y -CONFIG_OMAP_WATCHDOG=y -CONFIG_TWL4030_WATCHDOG=y -CONFIG_MFD_SYSCON=y +CONFIG_OMAP_WATCHDOG=m +CONFIG_TWL4030_WATCHDOG=m CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65218=y @@ -289,51 +292,77 @@ 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_HID_GENERIC=m +CONFIG_USB_HIDDEV=y +CONFIG_USB_KBD=m +CONFIG_USB_MOUSE=m +CONFIG_USB=m CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_MON=y +CONFIG_USB_MON=m CONFIG_USB_XHCI_HCD=m -CONFIG_USB_WDM=y -CONFIG_USB_STORAGE=y +CONFIG_USB_WDM=m +CONFIG_USB_STORAGE=m +CONFIG_USB_MUSB_HDRC=m +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_USB_MUSB_AM35X=m +CONFIG_USB_MUSB_DSPS=m CONFIG_USB_DWC3=m -CONFIG_USB_TEST=y +CONFIG_USB_TEST=m CONFIG_AM335X_PHY_USB=y -CONFIG_USB_GADGET=y +CONFIG_USB_GADGET=m CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y CONFIG_USB_GADGET_DEBUG_FS=y +CONFIG_USB_CONFIGFS=m
Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
On Mon, Dec 22, 2014 at 12:05:35PM -0600, Felipe Balbi wrote: By converting a few drivers to modules because they won't be needed during boot anyways, we can shave off about 700KiB of text. Note that while at that, and after discussions with Tony Lindgren, a few extra drivers were either removed because they weren't needed, or added because they're useful for debugging/testing. Below is output of size for pre and post vmlinux binaries: textdata bss dec hex filename 8342992 757876 8411840 1751270810b3904 vmlinux-post-patch 9069110 800316 8419072 182884981170f72 vmlinux-pre-patch Signed-off-by: Felipe Balbi ba...@ti.com oh yeah, still boots fine with AM437x SK, Beagle Bone Black. Also boots with Beagle X15, but that still needs a pending CPSW patch [1] for NFS root. [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/121183 --- arch/arm/configs/omap2plus_defconfig | 121 ++- 1 file changed, 75 insertions(+), 46 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index c2c3a85..a1dc3ed 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -13,7 +13,6 @@ CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_CGROUP_CPUACCT=y -CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_KMEM=y @@ -68,7 +67,6 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y -CONFIG_GENERIC_CPUFREQ_CPU0=y # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set CONFIG_CPU_IDLE=y CONFIG_BINFMT_MISC=y @@ -103,7 +101,7 @@ CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_DMA_CMA=y CONFIG_OMAP_OCP2SCP=y -CONFIG_CONNECTOR=y +CONFIG_CONNECTOR=m CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_BLOCK=y @@ -122,14 +120,13 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_SENSORS_TSL2550=m CONFIG_BMP085_I2C=m -CONFIG_SENSORS_LIS3_I2C=m CONFIG_SRAM=y +CONFIG_SENSORS_LIS3_I2C=m CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SCSI_SCAN_ASYNC=y -CONFIG_ATA=y -CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_MD=y +CONFIG_ATA=m +CONFIG_SATA_AHCI_PLATFORM=m CONFIG_NETDEVICES=y # CONFIG_NET_VENDOR_ARC is not set # CONFIG_NET_CADENCE is not set @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y # CONFIG_NET_VENDOR_WIZNET is not set CONFIG_AT803X_PHY=y CONFIG_SMSC_PHY=y -CONFIG_USB_USBNET=y -CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_USBNET=m +CONFIG_USB_NET_SMSC95XX=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y @@ -172,18 +169,22 @@ CONFIG_WLCORE_SDIO=m CONFIG_MWIFIEX=m CONFIG_MWIFIEX_SDIO=m CONFIG_MWIFIEX_USB=m -CONFIG_INPUT_JOYDEV=y -CONFIG_INPUT_EVDEV=y -CONFIG_KEYBOARD_GPIO=y +CONFIG_INPUT_JOYDEV=m +CONFIG_INPUT_EVDEV=m +CONFIG_KEYBOARD_ATKBD=m +CONFIG_KEYBOARD_GPIO=m CONFIG_KEYBOARD_MATRIX=m -CONFIG_KEYBOARD_TWL4030=y +CONFIG_KEYBOARD_OMAP4=m +CONFIG_KEYBOARD_TWL4030=m +# CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=m CONFIG_TOUCHSCREEN_EDT_FT5X06=m CONFIG_TOUCHSCREEN_TSC2005=m CONFIG_TOUCHSCREEN_TSC2007=m CONFIG_INPUT_MISC=y -CONFIG_INPUT_TWL4030_PWRBUTTON=y +CONFIG_INPUT_TWL4030_PWRBUTTON=m +CONFIG_SERIO=m # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y @@ -196,15 +197,16 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y -CONFIG_HW_RANDOM=y CONFIG_I2C_CHARDEV=y CONFIG_SPI=y CONFIG_SPI_OMAP24XX=y +CONFIG_SPI_TI_QSPI=m CONFIG_PINCTRL_SINGLE=y CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y -CONFIG_GPIO_TWL4030=y -CONFIG_W1=y +CONFIG_GPIO_TWL4030=m +CONFIG_W1=m +CONFIG_HDQ_MASTER_OMAP=m CONFIG_BATTERY_BQ27x00=m CONFIG_CHARGER_ISP1704=m CONFIG_CHARGER_TWL4030=m @@ -213,20 +215,21 @@ CONFIG_CHARGER_BQ24190=m CONFIG_CHARGER_BQ24735=m CONFIG_POWER_RESET=y CONFIG_POWER_AVS=y +CONFIG_HWMON=m CONFIG_SENSORS_LM75=m -CONFIG_THERMAL=y +CONFIG_SENSORS_TMP102=m +CONFIG_THERMAL=m CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_USER_SPACE=y CONFIG_CPU_THERMAL=y -CONFIG_TI_SOC_THERMAL=y +CONFIG_TI_SOC_THERMAL=m CONFIG_TI_THERMAL=y CONFIG_OMAP4_THERMAL=y CONFIG_OMAP5_THERMAL=y CONFIG_DRA752_THERMAL=y CONFIG_WATCHDOG=y -CONFIG_OMAP_WATCHDOG=y -CONFIG_TWL4030_WATCHDOG=y -CONFIG_MFD_SYSCON=y +CONFIG_OMAP_WATCHDOG=m +CONFIG_TWL4030_WATCHDOG=m CONFIG_MFD_PALMAS=y CONFIG_MFD_TPS65217=y CONFIG_MFD_TPS65218=y @@ -289,51 +292,77 @@ 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_HID_GENERIC=m +CONFIG_USB_HIDDEV=y +CONFIG_USB_KBD=m +CONFIG_USB_MOUSE=m +CONFIG_USB=m CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_MON=y
Re: [PATCH] ARM: dts: am437x-sk-evm: Hook dcdc2 as the cpu0-supply
On Thu, Dec 04, 2014 at 09:24:39AM -0600, Felipe Balbi wrote:
From: Dave Gerlach d-gerl...@ti.com
Hook dcdc2 as the cpu0-supply.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
btw, before sending this, I tested on my AM437x Starter Kit, so
Tested-by: Felipe Balbi ba...@ti.com
---
arch/arm/boot/dts/am437x-sk-evm.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 87aa4f3..f7f77a7 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -611,3 +611,7 @@
wdt {
status = okay;
};
+
+cpu {
+ cpu0-supply = dcdc2;
+};
--
2.1.0.GIT
--
balbi
signature.asc
Description: Digital signature
[PATCH] arm: boot: dts: add support for AM437x IDK
The AM437x Industrial Development Kit (IDK) is
an application development platform targeted at
industrial communication and control applications.
It comes with a 3-phase motor driver, PROFINET,
PROFIBUS and a few other industrial communication
interfaces.
The board has 1GiB of DDR3 RAM, QSPI NOR flash,
a 100% discrete power design (no PMIC) and an
on-board 2MP camera (not supported with Linux
as of this writing).
Signed-off-by: Felipe Balbi ba...@ti.com
---
boot log: http://hastebin.com/oxinotuzur
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am437x-idk-evm.dts | 381 +++
2 files changed, 382 insertions(+)
create mode 100644 arch/arm/boot/dts/am437x-idk-evm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..1b2c7de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -366,6 +366,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-var-stk-om44.dtb
dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
am437x-sk-evm.dtb \
+ am437x-idk-evm.dtb \
am437x-gp-evm.dtb
dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts
b/arch/arm/boot/dts/am437x-idk-evm.dts
new file mode 100644
index 000..b52dd0a
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -0,0 +1,381 @@
+/*
+ * Copyright (C) 2014 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 am4372.dtsi
+#include dt-bindings/pinctrl/am43xx.h
+#include dt-bindings/pwm/pwm.h
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
+
+/ {
+ model = TI AM437x Industrial Development Kit;
+ compatible = ti,am437x-idk-evm,ti,am4372,ti,am43;
+
+ v24_0d: fixed-regulator-v24_0d {
+ compatible = regulator-fixed;
+ regulator-name = V24_0D;
+ regulator-min-microvolt = 2400;
+ regulator-max-microvolt = 2400;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ v3_3d: fixed-regulator-v3_3d {
+ compatible = regulator-fixed;
+ regulator-name = V3_3D;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = v24_0d;
+ };
+
+ vdd_corereg: fixed-regulator-vdd_corereg {
+ compatible = regulator-fixed;
+ regulator-name = VDD_COREREG;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = v24_0d;
+ };
+
+ vdd_core: fixed-regulator-vdd_core {
+ compatible = regulator-fixed;
+ regulator-name = VDD_CORE;
+ regulator-min-microvolt = 110;
+ regulator-max-microvolt = 110;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = vdd_corereg;
+ };
+
+ v1_8dreg: fixed-regulator-v1_8dreg{
+ compatible = regulator-fixed;
+ regulator-name = V1_8DREG;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = v24_0d;
+ };
+
+ v1_8d: fixed-regulator-v1_8d{
+ compatible = regulator-fixed;
+ regulator-name = V1_8D;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = v1_8dreg;
+ };
+
+ v1_5dreg: fixed-regulator-v1_5dreg{
+ compatible = regulator-fixed;
+ regulator-name = V1_5DREG;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = v24_0d;
+ };
+
+ v1_5d: fixed-regulator-v1_5d{
+ compatible = regulator-fixed;
+ regulator-name = V1_5D;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = v1_5dreg;
+ };
+};
+
+am43xx_pinmux {
+ i2c0_pins_default: i2c0_pins_default {
+ pinctrl-single,pins =
+ 0x188 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE0) /*
Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
Hi Felipe, On 12/22/14 20:05, Felipe Balbi wrote: [...] CONFIG_SCSI_SCAN_ASYNC=y -CONFIG_ATA=y -CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_MD=y +CONFIG_ATA=m +CONFIG_SATA_AHCI_PLATFORM=m Isn't this needed for the rootfs on SATA devices? CONFIG_NETDEVICES=y # CONFIG_NET_VENDOR_ARC is not set # CONFIG_NET_CADENCE is not set @@ -154,8 +151,8 @@ CONFIG_TI_CPSW=y # CONFIG_NET_VENDOR_WIZNET is not set CONFIG_AT803X_PHY=y CONFIG_SMSC_PHY=y -CONFIG_USB_USBNET=y -CONFIG_USB_NET_SMSC95XX=y +CONFIG_USB_USBNET=m +CONFIG_USB_NET_SMSC95XX=m What about the NFS root for boards with only USB eth? [...] CONFIG_DEBUG_GPIO=y CONFIG_GPIO_SYSFS=y -CONFIG_GPIO_TWL4030=y -CONFIG_W1=y +CONFIG_GPIO_TWL4030=m w/o this devices wired to twl gpios will not come up and likely will miss the enumeration... -CONFIG_USB=y +CONFIG_HID_GENERIC=m +CONFIG_USB_HIDDEV=y +CONFIG_USB_KBD=m +CONFIG_USB_MOUSE=m +CONFIG_USB=m So, you don't consider USB a valid rootfs storage option? CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_MON=y +CONFIG_USB_MON=m CONFIG_USB_XHCI_HCD=m -CONFIG_USB_WDM=y -CONFIG_USB_STORAGE=y +CONFIG_USB_WDM=m +CONFIG_USB_STORAGE=m +CONFIG_USB_MUSB_HDRC=m +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_USB_MUSB_AM35X=m +CONFIG_USB_MUSB_DSPS=m [...] -- Regards, Igor. -- 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
