[PATCH] usb: dwc3: add glue layer dependencies
Glue layers for the DWC3 driver only make sense on specific platforms. Add dependencies so that they are not built where they aren't needed. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: WingMan Kwok w-kw...@ti.com --- drivers/usb/dwc3/Kconfig |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- linux-3.15-rc0.orig/drivers/usb/dwc3/Kconfig2014-03-31 05:40:15.0 +0200 +++ linux-3.15-rc0/drivers/usb/dwc3/Kconfig 2014-04-08 10:36:19.218960761 +0200 @@ -44,7 +44,7 @@ comment Platform Glue Driver Support config USB_DWC3_OMAP tristate Texas Instruments OMAP5 and similar Platforms - depends on EXTCON + depends on EXTCON (ARCH_OMAP2PLUS || COMPILE_TEST) default USB_DWC3 help Some platforms from Texas Instruments like OMAP5, DRA7xxx and @@ -54,6 +54,7 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate Samsung Exynos Platform + depends on ARCH_EXYNOS || COMPILE_TEST default USB_DWC3 help Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside, @@ -72,6 +73,7 @@ config USB_DWC3_PCI config USB_DWC3_KEYSTONE tristate Texas Instruments Keystone2 Platforms + depends on ARCH_KEYSTONE || COMPILE_TEST default USB_DWC3 help Support of USB2/3 functionality in TI Keystone2 platforms. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: OMAP2+: remove uses of obsolete gpmc,device-nand
Remove all remaining uses of gpmc,device-nand that have been added since the property was removed by commit f40739faba8e (ARM: dts: OMAP2+: Simplify NAND support). Signed-off-by: Johan Hovold jhov...@gmail.com --- arch/arm/boot/dts/am335x-igep0033.dtsi | 1 - arch/arm/boot/dts/omap3-devkit8000.dts | 1 - arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 1 - 3 files changed, 3 deletions(-) diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi b/arch/arm/boot/dts/am335x-igep0033.dtsi index 7063311a58d9..06c822a48b71 100644 --- a/arch/arm/boot/dts/am335x-igep0033.dtsi +++ b/arch/arm/boot/dts/am335x-igep0033.dtsi @@ -118,7 +118,6 @@ reg = 0 0 0; /* CS0, offset 0 */ nand-bus-width = 8; ti,nand-ecc-opt = bch8; - gpmc,device-nand = true; gpmc,device-width = 1; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts b/arch/arm/boot/dts/omap3-devkit8000.dts index bf5a515a3247..da402f0fdab4 100644 --- a/arch/arm/boot/dts/omap3-devkit8000.dts +++ b/arch/arm/boot/dts/omap3-devkit8000.dts @@ -112,7 +112,6 @@ reg = 0 0 0; /* CS0, offset 0 */ nand-bus-width = 16; - gpmc,device-nand; gpmc,sync-clk-ps = 0; gpmc,cs-on-ns = 0; gpmc,cs-rd-off-ns = 44; diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi index 6369d9f43ca2..cc1dce6978f5 100644 --- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi +++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi @@ -368,7 +368,6 @@ /* no elm on omap3 */ gpmc,mux-add-data = 0; - gpmc,device-nand; gpmc,device-width = 2; gpmc,wait-pin = 0; gpmc,wait-monitoring-ns = 0; -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 5/6] ARM: am4372.dtsi: add omapdss information
On 24/03/14 13:01, Sathya Prakash M R wrote:
Add DT data for the display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
rfbi - MIPI DBI encoder
dss subsystem of am43x is re use from omap3.
Signed-off-by: Sathya Prakash M R sath...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ea55a4e..58fb78b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -684,6 +684,41 @@
num-cs = 4;
status = disabled;
};
+
+ dss: dss@4832A000 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4832A000 0x200;
+ status = disabled;
+ ti,hwmods = dss_core;
+ clocks = disp_clk;
+ clock-names = fck;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832A400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832A400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = disp_clk;
+ clock-names = fck;
+ };
+
+ dpi: encoder@0 {
+ compatible = ti,omap3-dpi;
+ };
+
+ rfbi: rfbi@4832A800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832A800 0x100;
+ ti,hwmods = dss_rfbi;
+ clocks = disp_clk;
+ clock-names = fck;
+ };
+
+ };
+
This needs to be updated for the latest DSS DT version. It's not merged
to linus' master branch.
At least the simple-bus and the dpi-node has to be removed.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH V3 1/6] OMAPDSS: Add DSS features for AM43xx
On 24/03/14 13:01, Sathya Prakash M R wrote: Add DSS features for AM43xx. Signed-off-by: Sathya Prakash M R sath...@ti.com I can pick this up for 3.16 dss changes. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V3 2/6] ARM: AM43xx: fix dpll init in bypass mode
Hi Paul, On 24/03/14 13:01, Sathya Prakash M R wrote: From: Tomi Valkeinen tomi.valkei...@ti.com On AM43xx, if a PLL is in bypass at kernel init, the code in omap2_get_dpll_rate() will not realize this and will try to calculate the clock rate using the multiplier and the divider, resulting in errors. omap2_init_dpll_parent() has similar issue. Add the missing soc_is_am43xx() check to make the code work on AM43xx. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Sathya Prakash M R sath...@ti.com --- arch/arm/mach-omap2/clkt_dpll.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Can you queue this for 3.15 fixes? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Joerg, On Friday 04 April 2014 12:18:11 Joerg Roedel wrote: On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. These two levels exist in the form of the DMA-API and the IOMMU-API. In fact, the IOMMU-API was created to provide a way to drivers to specifiy the IOVA-PHYS mappings on its own. I agree with you, the two levels are already present, but there's still rough edges that we need to soften. The ARM DMA API implementation requires someone to create the VA space mapping by calling arm_iommu_create_mapping() and attach devices to mappings by calling arm_iommu_attach_device(). This must only be performed for devices that use the DMA API, devices that manage their IOMMU directly will call to the IOMMU API directly. One obvious possibility is to call those functions in the IOMMU bus masters device drivers. This is pretty easy, but makes the drivers IOMMU-aware (which I'd like to avoid) and doesn't allow multiple bus masters to share a VA space mapping. Another possibility is to place the calls in the IOMMU drivers. This has the advantage of removing any IOMMU knowledge from bus masters device drivers and allowing multiple bus masters per IOMMU, but makes IOMMU management by the DMA API unconditional. Has anyone given this problem a though ? The IOMMU core or the IOMMU driver will need to know whether the driver expects to control the IOMMU directly or to have it managed transparently. As this is a software configuration I don't think the information belongs to DT. The question is, how should this information be conveyed ? The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Are drivers supposed to reimplement the DMA API internally in that case ? -- Regards, Laurent Pinchart -- 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/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Marek, On Friday 04 April 2014 14:23:57 Marek Szyprowski wrote: Hello, I'm sorry for a delay, I've got back from my holidays and I'm still busy trying to get thought all the emails. No worries. On 2014-03-17 23:44, Laurent Pinchart wrote: On Monday 17 March 2014 14:58:24 Suman Anna wrote: On 03/16/2014 04:54 PM, Sakari Ailus wrote: On Fri, Mar 14, 2014 at 12:00:16PM +0100, Laurent Pinchart wrote: Hi Suman, (CC'ing Joerg Roedel and Marek Szyprowski for the core IOMMU discussion) On Thursday 13 March 2014 21:33:37 Suman Anna wrote: On 03/07/2014 06:46 PM, Laurent Pinchart wrote: Hello, This patch set fixes miscellaneous issues with the OMAP IOMMU driver, found when trying to port the OMAP3 ISP away from omap- iovmm to the ARM DMA API. The biggest issue is fixed by patch 5/5, while the other patches fix smaller problems that I've noticed when reading the code, without experiencing them at runtime. I'd like to take this as an opportunity to discuss OMAP IOMMU integration with the ARM DMA mapping implementation. The idea is to hide the IOMMU completely behind the DMA mapping API, making it completely transparent to drivers. Thanks for starting the discussion. A drivers will only need to allocate memory with dma_alloc_*, and behind the scene the ARM DMA mapping implementation will find out that the device is behind an IOMMU and will map the buffers through the IOMMU, returning an I/O VA address to the driver. No direct call to the OMAP IOMMU driver or to the IOMMU core should be necessary anymore. To use the IOMMU the ARM DMA implementation requires a VA mapping to be created with a call to arm_iommu_create_mapping() and to then be attached to the device with arm_iommu_attach_device(). This is currently not performed by the OMAP IOMMU driver, I have thus added that code to the OMAP3 ISP driver for now. I believe this to still be an improvement compared to the current situation, as it allows getting rid of custom memory allocation code in the OMAP3 ISP driver and custom I/O VA space management in omap-iovmm. However, that code should ideally be removed from the driver. The question is, where should it be moved to ? One possible solution would be to add the code to the OMAP IOMMU driver. However, this would require all OMAP IOMMU users to be converted to the ARM DMA API. I assume there would be issues that I don't foresee though. Yeah, I think this will pose some problems for the other main user of IOMMUs - the remoteproc devices (DSP, Dual-Cortex M3/M4 processors in OMAP4 and beyond). A remoteproc device also needs to map memory at specific addresses for its code and data sections, and not rely on a I/O VA address being given to it. The firmware sections are already linked at specific addresses, and so remoteproc needs to allocate memory, load the firmware and map into appropriate device addresses. We are doing this currently usage a combination of CMA memory to get contiguous memory (there are some restrictions for certain sections) and iommu_map/unmap API to program the MMU with these pages. This usage is different from what is expected from exchanging buffers, which can be allocated from a predefined mapping range. Even that one is tricky if we need to support different cache properties/attributes as the cache configuration is in general local to these processors. Right, we indeed need two levels of API, one for drivers such as remoteproc that need direct control of the IOMMU, and one for drivers that only need to map buffers without any additional requirement. In the second case the drivers should ideally use the DMA mapping API not even be aware that an IOMMU is present. This would require moving the ARM mapping allocation out of the client driver. Actually, I think there is one another use case, even with remoteprocs which is to runtime map buffers. This is different from the firmware management. The memory for buffers could have been allocated from other subsystems, but remoteproc would need just to manage the VA space and map. Right, although you might not always have to manage the VA space in that case. Anyway, if your driver needs to manage the VA space for the firmware, it should be able to manage the VA space for the buffers using the same IOMMU API. I've already seen some use cases which require to give a client device limited access to DMA mapping IOMMU related structures. If we agree on API, I see no problems to add such calls to dma-mapping. However in the most common case I would like to hide the presence of IOMMU from the client device at all. I agree with you. I'd like to hide the IOMMU completely by default, but some drivers will need fine-grained control over
[PATCH 0/2] ARM: dts: sbc-t54: add support for sbc-t54 with cm-t54
Add support for CompuLab CM-T54 CoM and SBC-T54 board: http://compulab.co.il/products/computer-on-modules/cm-t54/ http://compulab.co.il/products/sbcs/sbc-t54/ SBC-T54 is a single board computer based on OMAP5432 CPU. It is implemented with a CM-T54 CoM providing most of the functions, and SB-T54 carrier board providing connectors and several additional functions. Dmitry Lifshitz (2): ARM: dts: sbc-t54: add support for sbc-t54 with cm-t54 ARM: dts: cm-t54: add WiFi/BT support arch/arm/boot/dts/Makefile |2 + arch/arm/boot/dts/omap5-cm-t54.dts | 390 +++ arch/arm/boot/dts/omap5-sbc-t54.dts | 33 +++ arch/arm/mach-omap2/pdata-quirks.c | 10 + 4 files changed, 435 insertions(+), 0 deletions(-) create mode 100644 arch/arm/boot/dts/omap5-cm-t54.dts create mode 100644 arch/arm/boot/dts/omap5-sbc-t54.dts -- 1.7.5.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
[PATCH 2/2] ARM: dts: cm-t54: add WiFi/BT support
Add support of AW-NH387 (mwifiex) WiFi/BT chip connected to MMC3.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/omap5-cm-t54.dts | 27 +++
arch/arm/mach-omap2/pdata-quirks.c | 10 ++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
index c87401f..27f5b7f 100644
--- a/arch/arm/boot/dts/omap5-cm-t54.dts
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -51,6 +51,7 @@
pinctrl-0 =
led_gpio_pins
usbhost_pins
+ wlan_reset_pins
;
led_gpio_pins: pinmux_led_gpio_pins {
@@ -92,6 +93,24 @@
;
};
+ mmc3_pins: pinmux_mmc3_pins {
+ pinctrl-single,pins =
+ 0x164 (PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_clk */
+ 0x166 (PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_cmd */
+ 0x168 (PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data0 */
+ 0x16a (PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data1 */
+ 0x16c (PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data2 */
+ 0x16e (PIN_INPUT_PULLUP | MUX_MODE0) /* wlsdio_data3 */
+ ;
+ };
+
+ wlan_reset_pins: pinmux_wlan_reset_pins {
+ pinctrl-single,pins =
+ 0x15c (PIN_OUTPUT | MUX_MODE6) /*
abemcpdm_ul_data.gpio4_109 - WLAN_nPD */
+ 0x15e (PIN_OUTPUT | MUX_MODE6) /*
abemcpdm_dl_data.gpio4_110 - WLAN_nRESET */
+ ;
+ };
+
usbhost_pins: pinmux_usbhost_pins {
pinctrl-single,pins =
0x084 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
@@ -121,6 +140,14 @@
ti,non-removable;
};
+mmc3 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc3_pins;
+ vmmc-supply = ldo2_reg;
+ bus-width = 4;
+ ti,non-removable;
+};
+
mmc4 {
status = disabled;
};
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index a114806..554ab37 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -205,6 +205,15 @@ static void __init omap5_uevm_legacy_init(void)
{
legacy_init_ehci_clk(auxclk1_ck);
}
+
+static void __init omap5_cm_t54_legacy_init(void)
+{
+ gpio_request_one(109, GPIOF_OUT_INIT_HIGH, wlan_pdn);
+ gpio_export(109, 0);
+
+ gpio_request_one(110, GPIOF_OUT_INIT_HIGH, wlan_rst);
+ gpio_export(110, 0);
+}
#endif
static struct pcs_pdata pcs_pdata;
@@ -286,6 +295,7 @@ static struct pdata_init pdata_quirks[] __initdata = {
#endif
#ifdef CONFIG_SOC_OMAP5
{ ti,omap5-uevm, omap5_uevm_legacy_init, },
+ { compulab,omap5-cm-t54, omap5_cm_t54_legacy_init, },
#endif
{ /* sentinel */ },
};
--
1.7.5.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
[PATCH 1/2] ARM: dts: sbc-t54: add support for sbc-t54 with cm-t54
Add support for CM-T54 CoM and SBC-T54 board:
http://compulab.co.il/products/computer-on-modules/cm-t54/
http://compulab.co.il/products/sbcs/sbc-t54/
SBC-T54 is a single board computer based on OMAP5432 CPU.
It is implemented with a CM-T54 CoM providing most of the functions,
and SB-T54 carrier board providing connectors and several additional
functions.
Added basic support for:
* PMIC
* LED
* MMC/SD
* eMMC
* USB
* I2C1/4
* SB-T54 and CM-T54 EEPROMs
* RTC
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
---
arch/arm/boot/dts/Makefile |2 +
arch/arm/boot/dts/omap5-cm-t54.dts | 363 +++
arch/arm/boot/dts/omap5-sbc-t54.dts | 33
3 files changed, 398 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap5-cm-t54.dts
create mode 100644 arch/arm/boot/dts/omap5-sbc-t54.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 84d90fc..e362b1c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -221,6 +221,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap4-var-som.dtb \
omap4-sdp.dtb \
omap4-sdp-es23plus.dtb \
+ omap5-cm-t54.dtb \
+ omap5-sbc-t54.dtb \
omap5-uevm.dtb \
omap5-pyra.dtb \
am335x-evm.dtb \
diff --git a/arch/arm/boot/dts/omap5-cm-t54.dts
b/arch/arm/boot/dts/omap5-cm-t54.dts
new file mode 100644
index 000..c87401f
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-cm-t54.dts
@@ -0,0 +1,363 @@
+/*
+ * Support for CompuLab CM-T54
+ */
+/dts-v1/;
+
+#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+/ {
+ model = CompuLab CM-T54;
+ compatible = compulab,omap5-cm-t54, ti,omap5;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x7F00; /* 2048 MB */
+ };
+
+ vmmcsd_fixed: fixed-regulator-mmcsd {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio3 12 GPIO_ACTIVE_LOW; /* gpio3_76
HUB_RESET */
+ };
+
+ /* HS USB Host PHY on PORT 3 */
+ hsusb3_phy: hsusb3_phy {
+ compatible = usb-nop-xceiv;
+ reset-gpios = gpio3 19 GPIO_ACTIVE_LOW; /* gpio3_83
ETH_RESET */
+ };
+
+ leds {
+ compatible = gpio-leds;
+ led@1 {
+ label = Heartbeat;
+ gpios = gpio3 16 GPIO_ACTIVE_HIGH; /* gpio3_80
ACT_LED */
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
+};
+
+omap5_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_gpio_pins
+ usbhost_pins
+ ;
+
+ led_gpio_pins: pinmux_led_gpio_pins {
+ pinctrl-single,pins =
+ 0x070 (PIN_OUTPUT | MUX_MODE6) /* hsi2_caflag.gpio3_80
*/
+ ;
+ };
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x1b2 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_pmic_scl */
+ 0x1b4 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c1_pmic_sda */
+ ;
+ };
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x1a2 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_clk */
+ 0x1a4 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_cmd */
+ 0x1a6 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_data2 */
+ 0x1a8 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_data3 */
+ 0x1aa (PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_data0 */
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE0) /* sdcard_data1 */
+ ;
+ };
+
+ mmc2_pins: pinmux_mmc2_pins {
+ pinctrl-single,pins =
+ 0x000 (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_clk */
+ 0x002 (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_cmd */
+ 0x004 (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data0 */
+ 0x006 (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data1 */
+ 0x008 (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data2 */
+ 0x00a (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data3 */
+ 0x00c (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data4 */
+ 0x00e (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data5 */
+ 0x010 (PIN_INPUT_PULLUP | MUX_MODE0) /* emmc_data6 */
+ 0x012 (PIN_INPUT_PULLUP | MUX_MODE0) /*
Re: [PATCH 0/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Laurent, On Tue, Apr 08, 2014 at 02:50:38PM +0200, Laurent Pinchart wrote: I agree with you, the two levels are already present, but there's still rough edges that we need to soften. The ARM DMA API implementation requires someone to create the VA space mapping by calling arm_iommu_create_mapping() and attach devices to mappings by calling arm_iommu_attach_device(). Who is someone in this case? This must only be performed for devices that use the DMA API, devices that manage their IOMMU directly will call to the IOMMU API directly. One obvious possibility is to call those functions in the IOMMU bus masters device drivers. This is pretty easy, but makes the drivers IOMMU-aware (which I'd like to avoid) and doesn't allow multiple bus masters to share a VA space mapping. Another possibility is to place the calls in the IOMMU drivers. This has the advantage of removing any IOMMU knowledge from bus masters device drivers and allowing multiple bus masters per IOMMU, but makes IOMMU management by the DMA API unconditional. Why does that make IOMMU management by the DMA API unconditional? On x86 it works this way: The IOMMU drivers create DMA-API mappings for the devices by default. So any driver can use the DMA-API just out-of-the-box without being aware of an IOMMU. If the driver wants to deal with the IOMMU directly, it creates its own iommu-domain and attaches the device to it. The device uses the drivers domain then and not the DMA-API domain setup by the IOMMU driver. On iommu-detach the device is assigned back to its DMA-API domain. The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA-API anymore then). Are drivers supposed to reimplement the DMA API internally in that case? Usually not, but possible. Device drivers use the IOMMU-API when they want to control the io-addresses themselves. This is the case for VFIO for example, where a given range from a process address space is mapped into a device address space. In those cases the device driver usally does not need to implement its own address allocator. Regards, Joerg -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
It would be good to documenting the difference between this and OMAP4,
and why you have chosen different values.
There are two main differences:
1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
not needed even in OMAP4 with latest kernel, but I am not sure if I can
do this safely without breaking any usecase currently working with OMAP4.
2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
searched through the commit history of L2 cache support on OMAP4 but
there is no mention of why this was needed on OMAP4. I am checking
internally on the history behind this.
3) OMAP4 sets cache replacement policy to RR which is not a big deal
since thats the default anyway. We can probably drop this setting even
from OMAP4.
Thanks,
Sekhar
--
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/5] OMAP IOMMU fixes and IOMMU architecture questions
Hi Joerg, On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote: On Tue, Apr 08, 2014 at 02:50:38PM +0200, Laurent Pinchart wrote: I agree with you, the two levels are already present, but there's still rough edges that we need to soften. The ARM DMA API implementation requires someone to create the VA space mapping by calling arm_iommu_create_mapping() and attach devices to mappings by calling arm_iommu_attach_device(). Who is someone in this case? That's exactly the problem :-) The ARM DMA API implementation doesn't care who that someone is. Existing implementations call those functions either from the bus masters device drivers (in which case the drivers need to be IOMMU- aware, even if they use the DMA API and don't need to handle the IOMMU directly) or from the IOMMU drivers (in which case the bus masters device drivers don't have to care about the IOMMU, but without a way for drivers to handle the IOMMU directly when they need to). Possible other candidates are core IOMMU code or bus code. This must only be performed for devices that use the DMA API, devices that manage their IOMMU directly will call to the IOMMU API directly. One obvious possibility is to call those functions in the IOMMU bus masters device drivers. This is pretty easy, but makes the drivers IOMMU- aware (which I'd like to avoid) and doesn't allow multiple bus masters to share a VA space mapping. Another possibility is to place the calls in the IOMMU drivers. This has the advantage of removing any IOMMU knowledge from bus masters device drivers and allowing multiple bus masters per IOMMU, but makes IOMMU management by the DMA API unconditional. Why does that make IOMMU management by the DMA API unconditional? On x86 it works this way: The IOMMU drivers create DMA-API mappings for the devices by default. So any driver can use the DMA-API just out-of-the-box without being aware of an IOMMU. If the driver wants to deal with the IOMMU directly, it creates its own iommu-domain and attaches the device to it. The device uses the drivers domain then and not the DMA-API domain setup by the IOMMU driver. On iommu-detach the device is assigned back to its DMA-API domain. If we call arm_iommu_attach_device() from the IOMMU driver to get default transparent IOMMU handling, the function will then attach the device to the default domain with a call to iommu_attach_device(). If a driver needs to handle the IOMMU directly, should it start by detaching the device from the ARM IOMMU domain ? We would need to be very careful with the assumptions made by the different layers, as they might not support a driver attaching a new domain to a device that already has a domain attached. I'd feel more comfortable with avoiding to attach the default domain to the device in the first place, but that might not be easily doable. The way this works on x86 is that a device driver can use the DMA-API per default. If it wants to use the IOMMU-API it has to allocate a domain and add the device it handles to this domain (it can't use DMA- API anymore then). Are drivers supposed to reimplement the DMA API internally in that case? Usually not, but possible. Device drivers use the IOMMU-API when they want to control the io-addresses themselves. This is the case for VFIO for example, where a given range from a process address space is mapped into a device address space. In those cases the device driver usally does not need to implement its own address allocator. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP2+: AM43x: L2 cache support
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index f8b8dac..6b2a056 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -224,6 +224,14 @@ int __init omap4_l2_cache_init(void)
return omap_l2_cache_init(aux_ctrl, 0xc19f);
}
+
+int __init am43xx_l2_cache_init(void)
+{
+ u32 aux_ctrl = L310_AUX_CTRL_DATA_PREFETCH |
+ L310_AUX_CTRL_INSTR_PREFETCH;
It would be good to documenting the difference between this and OMAP4,
and why you have chosen different values.
There are two main differences:
1) OMAP4 sets Shared attribute override enable bit. TBH, I think this is
not needed even in OMAP4 with latest kernel, but I am not sure if I can
do this safely without breaking any usecase currently working with OMAP4.
Wrong. Shared bit is mandatory for the OMAP4. Its a SMP system
which needs that.
2) OMAP4 sets NS lockdown and NS interrupt access control bits. I
searched through the commit history of L2 cache support on OMAP4 but
there is no mention of why this was needed on OMAP4. I am checking
internally on the history behind this.
These have also come from the aligned settings with hardware folks.
3) OMAP4 sets cache replacement policy to RR which is not a big deal
since thats the default anyway. We can probably drop this setting even
from OMAP4.
Don't change anything on OMAP4 since these settings have come up from
multiple alignments.
In my view, Aegis can use exact same setting as OMAP4. Things like
shared bit etc would not make much difference because of UP config,
keeping that doesn't hurt either.
Why don't you just re-use that as is ? Sorry if I have missed any
other discussion on the thread.
Regards,
Santosh
--
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: [PATCHv3 19/41] OMAPDSS: panel-dpi: Add DT support
* Tomi Valkeinen tomi.valkei...@ti.com [140407 22:42]: On 08/04/14 03:13, Tony Lindgren wrote: Tomi, * Tomi Valkeinen tomi.valkei...@ti.com [140121 03:01]: Add DT support for panel-dpi. Looks like this patch did not get merged or am I missing something? Yes, I dropped it. None of the boards that I converted used panel-dpi. There was so much discussions about the display bindings, so I thought it's better to leave out all but the needed patches. OK As you probably are aware, we have at least these boards needing it before we can remove the omap3 legacy support: board-am3517evm.c board-cm-t35.c board-devkit8000.c board-ldp.c board-overo.c We could probably set the display timings based on the compatible flag in the driver if that's an issue? The timings shouldn't be an issue. But there's the backlight GPIO, currently handled by panel-dpi, which should be removed from the panel. We should use gpio-backlight for that one. Using gpio-backlight makes sense for sure. FYI, in the case of the LDP there are four GPIOs to configure to get things going: gpio55 LCD RESET panel-dpi? gpio56 LCD QVGApanel-dpi? twl gpio7 LCD power panel-dpi twl gpio15 LCD backlight gpio-backlight And then board-omap3pandora.c also needs support for panel_tpo_td043mtea1_platform_data. Yep, there's still much to do for DSS DT support. Hopefully it will be easier now that the core support is there. I'll continue working on the remaining boards and panels. However, I don't have any of the remaining boards, so help is of course appreciated. Yeah I can test at least the LDP 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
[RFC PATCH 5/5] gpio: switch to use struct struct gpio_chip_ops
All GPIO controller drivers have been migrated to use the struct
gpio_chip_ops virtual function table so the embeddeded function
pointers in struct gpio_chip can now be removed.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpiolib.c | 83 +
include/linux/gpio/driver.h | 40 +++---
2 files changed, 36 insertions(+), 87 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index f0cc93a..2808076 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -214,8 +214,8 @@ static int gpio_ensure_requested(struct gpio_desc *desc)
return -EIO;
}
desc_set_label(desc, [auto]);
- /* caller must chip-request() w/o spinlock */
- if (chip-request)
+ /* caller must chip-ops-request() w/o spinlock */
+ if (chip-ops-request)
return 1;
}
return 0;
@@ -272,10 +272,10 @@ int gpiod_get_direction(const struct gpio_desc *desc)
chip = gpiod_to_chip(desc);
offset = gpio_chip_hwgpio(desc);
- if (!chip-get_direction)
+ if (!chip-ops-get_direction)
return status;
- status = chip-get_direction(chip, offset);
+ status = chip-ops-get_direction(chip, offset);
if (status 0) {
/* GPIOF_DIR_IN, or other positive */
status = 1;
@@ -837,7 +837,7 @@ int gpiod_export(struct gpio_desc *desc, bool
direction_may_change)
goto fail_unlock;
}
- if (!desc-chip-direction_input || !desc-chip-direction_output)
+ if (!desc-chip-ops-direction_input ||
!desc-chip-ops-direction_output)
direction_may_change = false;
spin_unlock_irqrestore(gpio_lock, flags);
@@ -1188,25 +1188,6 @@ int gpiochip_add(struct gpio_chip *chip)
goto fail;
}
- /*
-* REVISIT: this is a workaround to not break git bisectability by
-* allowing GPIO controller drivers to set either either the function
-* pointers embedded in struct gpio_chip or by using a gpio_chip_ops.
-*
-* Should be removed once all drivers are converted to set chip-ops.
-*/
- if (chip-ops) {
- chip-request = chip-ops-request;
- chip-free = chip-ops-free;
- chip-get_direction= chip-ops-get_direction;
- chip-direction_input = chip-ops-direction_input;
- chip-direction_output = chip-ops-direction_output;
- chip-get = chip-ops-get;
- chip-set = chip-ops-set;
- chip-set_debounce = chip-ops-set_debounce;
- chip-dbg_show = chip-ops-dbg_show;
- }
-
spin_lock_irqsave(gpio_lock, flags);
if (base 0) {
@@ -1231,10 +1212,10 @@ int gpiochip_add(struct gpio_chip *chip)
* inputs (often with pullups enabled) so power
* usage is minimized. Linux code should set the
* gpio direction first thing; but until it does,
-* and in case chip-get_direction is not set,
+* and in case chip-ops-get_direction is not set,
* we may expose the wrong direction in sysfs.
*/
- desc-flags = !chip-direction_input
+ desc-flags = !chip-ops-direction_input
? (1 FLAG_IS_OUT)
: 0;
}
@@ -1711,10 +1692,10 @@ static int __gpiod_request(struct gpio_desc *desc,
const char *label)
goto done;
}
- if (chip-request) {
- /* chip-request may sleep */
+ if (chip-ops-request) {
+ /* chip-ops-request may sleep */
spin_unlock_irqrestore(gpio_lock, flags);
- status = chip-request(chip, gpio_chip_hwgpio(desc));
+ status = chip-ops-request(chip, gpio_chip_hwgpio(desc));
spin_lock_irqsave(gpio_lock, flags);
if (status 0) {
@@ -1723,8 +1704,8 @@ static int __gpiod_request(struct gpio_desc *desc, const
char *label)
goto done;
}
}
- if (chip-get_direction) {
- /* chip-get_direction may sleep */
+ if (chip-ops-get_direction) {
+ /* chip-ops-get_direction may sleep */
spin_unlock_irqrestore(gpio_lock, flags);
gpiod_get_direction(desc);
spin_lock_irqsave(gpio_lock, flags);
@@ -1781,10 +1762,10 @@ static bool __gpiod_free(struct gpio_desc *desc)
chip = desc-chip;
if (chip test_bit(FLAG_REQUESTED, desc-flags)) {
- if (chip-free) {
+
[RFC PATCH 0/5] add gpio_chip_ops to hold GPIO operations
In the kernel there are basically two patterns to implement object oriented code in C. You can either embedded a set of function pointers in a struct along with other members or have a separate virtual function table (vtable) structure that hold all the functions and only store a pointer to that vtable on our particular object. The struct gpio_chip uses the former approach, but I don't know if that is a design decision or is just that this code predates the fact that the separate structure pattern is now so popular. Since the having a the operations on a different structure has a number of benefits: - A clean separation between state (fields) and operations (functions). - Size reduction of struct gpio_chip since will only hold one pointer. - These functions are not supposed to change at runtime so the const qualifier can be used to prevent pointers modification during execution. - Similar drivers for a chip family can reuse their function vtable. There is a drawback though which is that now two memory accesses are needed to execute a GPIO operation since an additional level of indirection is introduced but that should be minimized due temporal and spatial memory locality. So this is an RFC patch-set to add a virtual table to be used by GPIO chip controllers and consist of the following patches: Javier Martinez Canillas (5): gpio: add a vtable to abstract GPIO controller operations gpiolib: set gpio_chip operations on add using a gpio_chip_ops gpio: omap: convert driver to use gpio_chip_ops gpio: twl4030: convert driver to use gpio_chip_ops gpio: switch to use struct struct gpio_chip_ops drivers/gpio/gpio-omap.c| 19 - drivers/gpio/gpio-twl4030.c | 10 +-- drivers/gpio/gpiolib.c | 64 - include/linux/gpio/driver.h | 69 +++-- 4 files changed, 93 insertions(+), 69 deletions(-) The patch-set is not a complete one though since only the GPIO OMAP and GPIO TWL4030 drivers have been converted so I could test it on my platform (DM3730 OMAP IGEPv2 board). But I preferred to send an early RFC than changing every single driver before discussing if doing the split is worth it or not. To not break git bisect-ability, I added some patches that are transitional changes. If you have a better suggestion on how to handle that please let me know. Thanks a lot and best regards, Javier -- 1.9.0 -- 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/5] gpiolib: set gpio_chip operations on add using a gpio_chip_ops
This is a transitional change to avoid breaking git bisect-ability
while converting GPIO controller drivers to set their operations by
using the newly introduced struct gpio_chip_ops virtual function table.
It should be removed once all GPIO chip drivers have been converted.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpiolib.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 761013f..f0cc93a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1188,6 +1188,25 @@ int gpiochip_add(struct gpio_chip *chip)
goto fail;
}
+ /*
+* REVISIT: this is a workaround to not break git bisectability by
+* allowing GPIO controller drivers to set either either the function
+* pointers embedded in struct gpio_chip or by using a gpio_chip_ops.
+*
+* Should be removed once all drivers are converted to set chip-ops.
+*/
+ if (chip-ops) {
+ chip-request = chip-ops-request;
+ chip-free = chip-ops-free;
+ chip-get_direction= chip-ops-get_direction;
+ chip-direction_input = chip-ops-direction_input;
+ chip-direction_output = chip-ops-direction_output;
+ chip-get = chip-ops-get;
+ chip-set = chip-ops-set;
+ chip-set_debounce = chip-ops-set_debounce;
+ chip-dbg_show = chip-ops-dbg_show;
+ }
+
spin_lock_irqsave(gpio_lock, flags);
if (base 0) {
--
1.9.0
--
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/5] gpio: add a vtable to abstract GPIO controller operations
A common pattern to implement object oriented code in the kernel is
to use a separate structure to hold all the methods for a particular
kind of object and just have a pointer to this table rather than a
separate pointer for each method.
The alternate approach is to directly embedded function pointers in
the object but there are some advantages on using the former approach.
This patch adds a struct gpio_chip_ops to be set by GPIO chip controllers.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
include/linux/gpio/driver.h | 47 +
1 file changed, 47 insertions(+)
diff --git a/include/linux/gpio/driver.h b/include/linux/gpio/driver.h
index 1827b43..824cd32 100644
--- a/include/linux/gpio/driver.h
+++ b/include/linux/gpio/driver.h
@@ -16,6 +16,51 @@ struct seq_file;
#ifdef CONFIG_GPIOLIB
/**
+ * struct gpio_chip_ops - virtual function table for GPIO controller operations
+ * @request: optional hook for chip-specific activation, such as
+ * enabling module power and clock; may sleep
+ * @free: optional hook for chip-specific deactivation, such as
+ * disabling module power and clock; may sleep
+ * @get_direction: returns direction for signal offset, 0=out, 1=in,
+ * (same as GPIOF_DIR_XXX), or negative error
+ * @direction_input: configures signal offset as input, or returns error
+ * @direction_output: configures signal offset as output, or returns error
+ * @get: returns value for signal offset; for output signals this
+ * returns either the value actually sensed, or zero
+ * @set: assigns output value for signal offset
+ * @set_debounce: optional hook for setting debounce time for specified gpio in
+ * interrupt triggered gpio chips
+ * @dbg_show: optional routine to show contents in debugfs; default code
+ * will be used when this is omitted, but custom code can show extra
+ * state (such as pullup/pulldown configuration).
+ *
+ * A gpio_chip_ops is used as a virtual function table for gpio_chip so GPIO
+ * drivers can define their custom methods as needed by its the GPIO
controller.
+ */
+struct gpio_chip_ops {
+ int (*request)(struct gpio_chip *chip,
+ unsigned offset);
+ void(*free)(struct gpio_chip *chip,
+ unsigned offset);
+ int (*get_direction)(struct gpio_chip *chip,
+ unsigned offset);
+ int (*direction_input)(struct gpio_chip *chip,
+ unsigned offset);
+ int (*direction_output)(struct gpio_chip *chip,
+ unsigned offset, int value);
+ int (*get)(struct gpio_chip *chip,
+ unsigned offset);
+ void(*set)(struct gpio_chip *chip,
+ unsigned offset, int value);
+ int (*set_debounce)(struct gpio_chip *chip,
+ unsigned offset,
+ unsigned debounce);
+
+ void(*dbg_show)(struct seq_file *s,
+ struct gpio_chip *chip);
+};
+
+/**
* struct gpio_chip - abstract a GPIO controller
* @label: for diagnostics
* @dev: optional device providing the GPIOs
@@ -44,6 +89,7 @@ struct seq_file;
* @ngpio: the number of GPIOs handled by this controller; the last GPIO
* handled is (base + ngpio - 1).
* @desc: array of ngpio descriptors. Private.
+ * @ops: virtual table with GPIO controller operations.
* @names: if set, must be an array of strings to use as alternative
* names for the GPIOs in this chip. Any entry in the array
* may be NULL if there is no alias for the GPIO, however the
@@ -97,6 +143,7 @@ struct gpio_chip {
u16 ngpio;
struct gpio_desc*desc;
const char *const *names;
+ const struct gpio_chip_ops*ops;
boolcan_sleep;
boolexported;
--
1.9.0
--
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 4/5] gpio: twl4030: convert driver to use gpio_chip_ops
The GPIO controller operations has been split to be stored
on a separate struct gpio_chip_ops virtual function table.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-twl4030.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 3ebb1a5..0d40bc0 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -386,15 +386,19 @@ static int twl_to_irq(struct gpio_chip *chip, unsigned
offset)
: -EINVAL;
}
-static struct gpio_chip template_chip = {
- .label = twl4030,
- .owner = THIS_MODULE,
+const struct gpio_chip_ops ops = {
.request= twl_request,
.free = twl_free,
.direction_input= twl_direction_in,
.get= twl_get,
.direction_output = twl_direction_out,
.set= twl_set,
+};
+
+static struct gpio_chip template_chip = {
+ .label = twl4030,
+ .owner = THIS_MODULE,
+ .ops= ops,
.to_irq = twl_to_irq,
.can_sleep = true,
};
--
1.9.0
--
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/5] gpio: omap: convert driver to use gpio_chip_ops
The GPIO controller operations has been split to be stored
on a separate struct gpio_chip_ops virtual function table.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/gpio-omap.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 8cc9e91..50f0938 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1072,6 +1072,16 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned int
irq_start,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
+const struct gpio_chip_ops omap_gpio_ops = {
+ .request = omap_gpio_request,
+ .free = omap_gpio_free,
+ .direction_input = gpio_input,
+ .get = gpio_get,
+ .direction_output = gpio_output,
+ .set_debounce = gpio_debounce,
+ .set = gpio_set
+};
+
static int omap_gpio_chip_init(struct gpio_bank *bank)
{
int j;
@@ -1083,13 +1093,8 @@ static int omap_gpio_chip_init(struct gpio_bank *bank)
* REVISIT eventually switch from OMAP-specific gpio structs
* over to the generic ones
*/
- bank-chip.request = omap_gpio_request;
- bank-chip.free = omap_gpio_free;
- bank-chip.direction_input = gpio_input;
- bank-chip.get = gpio_get;
- bank-chip.direction_output = gpio_output;
- bank-chip.set_debounce = gpio_debounce;
- bank-chip.set = gpio_set;
+ bank-chip.ops = omap_gpio_ops;
+
if (bank-is_mpuio) {
bank-chip.label = mpuio;
if (bank-regs-wkup_en)
--
1.9.0
--
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: OMAP2+: N900: remove omapdss init for DT boot
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,
This patch should be added to 3.15-rc to make display initialization via DT
possible. Sorry for not noticing earlier, that this was missing in Tomi's
patchset.
-- Sebastian
---
arch/arm/mach-omap2/board-rx51-video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 43a90c8..9cfebc5 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -48,7 +48,7 @@ static struct omap_dss_board_info rx51_dss_board_info = {
static int __init rx51_video_init(void)
{
- if (!machine_is_nokia_rx51()
!of_machine_is_compatible(nokia,omap3-n900))
+ if (!machine_is_nokia_rx51())
return 0;
if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
--
1.9.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: OMAP2+: N900: remove omapdss init for DT boot
Hi,
On Tue, Apr 08, 2014 at 10:51:18PM +0200, Sebastian Reichel wrote:
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,
This patch should be added to 3.15-rc to make display initialization via DT
possible. Sorry for not noticing earlier, that this was missing in Tomi's
patchset.
-- Sebastian
---
arch/arm/mach-omap2/board-rx51-video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 43a90c8..9cfebc5 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -48,7 +48,7 @@ static struct omap_dss_board_info rx51_dss_board_info = {
static int __init rx51_video_init(void)
{
- if (!machine_is_nokia_rx51()
!of_machine_is_compatible(nokia,omap3-n900))
+ if (!machine_is_nokia_rx51())
return 0;
Shouldn't we delete the whole file, since non-DT boot is
not anymore supported?
A.
--
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+: N900: remove omapdss init for DT boot
* Aaro Koskinen aaro.koski...@iki.fi [140408 14:48]:
Hi,
On Tue, Apr 08, 2014 at 10:51:18PM +0200, Sebastian Reichel wrote:
Do not try to initialize display for DT boot, since omapdss
is now initialized via Device Tree. Without this patch the
display subsystem does not properly come up.
Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,
This patch should be added to 3.15-rc to make display initialization via DT
possible. Sorry for not noticing earlier, that this was missing in Tomi's
patchset.
-- Sebastian
---
arch/arm/mach-omap2/board-rx51-video.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-rx51-video.c
b/arch/arm/mach-omap2/board-rx51-video.c
index 43a90c8..9cfebc5 100644
--- a/arch/arm/mach-omap2/board-rx51-video.c
+++ b/arch/arm/mach-omap2/board-rx51-video.c
@@ -48,7 +48,7 @@ static struct omap_dss_board_info rx51_dss_board_info = {
static int __init rx51_video_init(void)
{
- if (!machine_is_nokia_rx51()
!of_machine_is_compatible(nokia,omap3-n900))
+ if (!machine_is_nokia_rx51())
return 0;
Shouldn't we delete the whole file, since non-DT boot is
not anymore supported?
Legacy support is still there for omap3 until the DSS displays are
converted.
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+: N900: remove omapdss init for DT boot
On Tue, Apr 08, 2014 at 03:23:55PM -0700, Tony Lindgren wrote: * Aaro Koskinen aaro.koski...@iki.fi [140408 14:48]: Shouldn't we delete the whole file, since non-DT boot is not anymore supported? Legacy support is still there for omap3 until the DSS displays are converted. Sorry, I was confused. It seems on omap2 (N800 etc.) the legacy boot is not supported anymore, and I thought it's the same for omap3. Sorry for the noise. A. -- 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: AM33xx: hwmod: Add INIT_NO_IDLE flag for debugss hwmod
During boot, when hwmod tries to cut clocks for debugss it always
gets stuck in transition state and throws the following warning:
[0.139581] omap_hwmod: debugss: _wait_target_disable failed
As per the information provided by folks, clocks to debugss cannot be cut.
So adding HWMOD_INIT_NO_IDLE flag to debugss hwmod.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
Tested on BeagleBone Black.
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 6b406ca..ec18ce0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -222,6 +222,7 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
.name = debugss,
.class = am33xx_debugss_hwmod_class,
.clkdm_name = l3_aon_clkdm,
+ .flags = HWMOD_INIT_NO_IDLE,
.main_clk = trace_clk_div_ck,
.prcm = {
.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
